See also: IRC log
<weiler> scribenick: JeffH
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....
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
jcj: ok, fine with merging
... where "this" is pr#159
vgg: pr#154 -- processing rules
... 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
... 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
<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
<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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/.../vj (prior to above).../ FAILED: s/pr#151/pr#161/ Found ScribeNick: JeffH Found ScribeNick: nadalin Inferring Scribes: JeffH, nadalin Scribes: JeffH, nadalin ScribeNicks: JeffH, nadalin Default Present: jcj_moz, Rolf, vgb, weiler, nadalin, rbarnes, JeffH, apowers, dirkbalfanz, JohnFontana, KetanMehta, RahulGhosh Present: jcj_moz Rolf vgb weiler nadalin rbarnes JeffH apowers dirkbalfanz JohnFontana KetanMehta RahulGhosh Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0053.html Found Date: 10 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/10-webauthn-minutes.html People with action items:[End of scribe.perl diagnostic output]