Web Authentication Working Group Teleconference -- 10 Aug 2016

<weiler> present=

<weiler> scribenick: JeffH

eTLD+1 discussion:

rbarnes: not totally sure how to bring to closure. default shud be web origin, all web apis are per origin other than cookies, can someone pls recap....?

dirk: it is overall same origiin (see dirk's msg on the list)
... we are constructing per-origin, the part that's not same-origin is the "scoping of the key pair"

<vgb> audio - down for everyone or just me?

<nadalin> it works for me

<vgb> thx, reconnecting

<dirkbalfanz> oh did we just drop off the call?

rbarnes: notes that client data does not seem to contain the full origin, rather has just RP ID? if actual origin is folded in per Dirk then that should be clarified in the spec

vijay(vj): notes that clientdata does contain full origin....

scribe: renames facet to origin to be more clear, is queued in PR

<vgb> dirk, looks like you dropped off too

<dirkbalfanz> ok I'm back

rbarnes: ...still wondering about use cases for the eTLD scoping of key pairs...

vj: there were expressed use cases [ relates some of them... ]

<vgb> JeffH: wanted to make sure there is no more cross-origin sharing than with cookies. don't want to tread into federation territory

vj (prior to above)...from practical perspective, it does not increase tracability beyond what exists now and meshes with current practice

rbarnes: proposes ... ?

notes that vgb == vj

<vgb> Boolean in options dictionary that tells the client to compute rpId = origin, or rpId = eTLD+1

scribe: == vijay

<rbarnes> proposal: add an option that an RP can use to switch between (RPID == origin) and (RPID == eTLD+1)

dirk: thinks this might "work", but am curious as to what the problem is that you are trying to solve here...

rbarnes: notes that even though is useful to scope to etld+1, would be useful if it is possible to scope more tightly if the deployer desires
... would be the same reason you'd use the domain-scoped cookie
... ok we're good on this for now....

Set timeline for review and agree on a approach for handling the Credential object

vgb: wrt cred object
... for whitelist caller would have to create cred objects
... the idl is a bit incorrect
... PR#159 addresses just this, cleans up the technicalities for how the IDL is written...
... another question that has come up is "what if we removed credential type?"
... pr#158 answers that
... have sketched out a couple ways/options for how to do this

<nadalin> JeffH: wants to adopt one of the 2 branches

no. pr#159 i think is likely OK. pr#158 and the other cred experiment branch require more discussion imho

vgb: can just merge in pr#159 cuz is just a bugfix

jeffH; ok

jcj: ok, fine with merging this
... where "this" is pr#159

vgg: pr#154 -- processing rules exposition
... cleans up stuff in the authnr model section eg clientDataHash is what is sent to authnr

<nadalin> JeffH; review 154 by next Wed

vgb & jeffh: discussed pr#154 -- it raises issue of the authnr model being just a model and whether the spec ought to define a hard&fast authnr API -- ie what if an underlying authnr transport prot emerges a la implied by U2F BLE & NFC transports

vgb: wrt PR#151 -- attestation cleanup proposal
... no matter what the attstn format is, it produces an AAGUID
... cleaned up some wording and such
... this also cleans up prior issue - we had not rigorously defined what an attstn format consists of
... this does so
... also streamlines how attstn verification works
... please review and raise discussion on list
... this is the next-to-last technical issues -- would be good to resolve them and then get a WD-01 out door

<nadalin> vjb: merge in 159 as it is

<nadalin> JC will have 151 reviewed by next call

s/pr#151/pr#161/

<jcj_moz> q ack

rolf: if tpm does attstn, it produces struct which is diff than what we spec
... so addtnl goal of attstn is to have ability to plug in diff to-be-signed formats
... we created packed attstn as the thing we prefer...

vgb: in trying to create actual authnr, we found that there's a boundry for authnr, and boundry of crypto mod
... authnr is a box that contains various things.... the prior structures had no way to feed into tpm things that were in boundary of authnr but not crypto mod
... so tried to address this in the pr#161
... it is 400 lines

rolf's 1st comment was: attestationStatement was a JSON structure producing a unified view on attestation objects

vgb: so this refactor allows the TPM to sign the packed rawData

rolf: if you look at android N as an example, which would fit in the prior attstn, how would you use this refactored spec to handle it?

vgb: android N takes in a nonce input, and produces PoPossession, yes?
... my authnr consists of android N crypto subsystem and logic above, it would take the inputs, hash them together to produce nonce, give to crypto layer to sign, RP gets the same overall result, there might be addtional validation steps....

rolf: there is sever risk in this model -- app provides nonce, is impt to not look like unified system because it is not
... RPs may not do adequate verification

<dirkbalfanz> Sorry have to drop off

<nadalin> yes

<weiler> scribenick: nadalin

vjb will talk to Rolf and post back to list

No one on call to UVM Rahul is missing to discuss

vgb: should we separate extensions form core?
... is the set of extensions we have now enough ?

rolf: challenge to get support for extentions if they are not in core

can we agree on the 2 extensions we have now ?

lets get the current ext (UVM/UVI/Location) PRs created and pulled into core

- DRAFT -

Web Authentication Working Group Teleconference

10 Aug 2016

Attendees

Contents

Set timeline for review and agree on a approach for handling the Credential object

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output