See also: IRC log
<weiler> present=
<Nadalin> +present
<weiler> present?
<weiler> present=
<wseltzer> present=
<Nadalin> figures
thx: )
<weiler> scribenick: apowers
I am honored to be scribe today
tony: please read Wendy's note
wseltzer: patent disclosure, please don't discuss patents on the list
thx
Nadalin: note sent to mailing
list for review, appreciate people looking at those
... discuss open pull requsts
gmandyam: happy to discuss my pull request, looking for decision that it's ready to be incorporated
Nadalin: my understanding was that you and Rahul were going to create pull requests
gmandyam: created several weeks ago
vijay: merge 154?
<wseltzer> https://github.com/w3c/webauthn/pull/154
JeffH: I was in the process of reviewing... but... cool
vijay: please take a gander, and I can merge it in later today
[is Vijay on IRC?]
<vgb> i'm here
thx
vgb: would like to go through issues to address gmandyam's comments
alexei-goog: Giri, were you asking if the PayPal app and the PayPal website would have access to the same key material
vgb: yes, determined by eTLD+1 for web and different for platform with access determined by RPID
JeffH: no concern with changing facet to origin
rbarnes: would need to change that in the dictionary
JeffH: okay with merging
vgb: Alexei -- okay with merging? need to review?
alexei-goog: not all the way
through yet
... if others have looked, I'm fine
... don't want to hold it up
vgb: just merge it when you're
done reviewing
... today or tomorrow?
alexei-goog: yes
jcj_moz: looked at it, no issues... haven't reviewed most recent changes, but wouldn't change my mind
vgb: mostly editorial
Nadalin: any other PRs that people have questions on?
vgb: core spec, what to do with credential object (143, 158)
<wseltzer> https://github.com/w3c/webauthn/pull/143
<wseltzer> https://github.com/w3c/webauthn/pull/158
vgb: both in the same direction
of getting rid of type in cred object
... follow up on these? close them out? more thinking?
rbarnes: seem to be moving away
from creds being objects
... opaque blobs of data
vgb: in favor of 158?
rbarnes: don't need an object / interface, just cred IDs
vgb: only other thing in the
object is type
... stands for algorithm type, formatting signature, authnr
data, method of signature generation
... what would future implementations do without a type
rbarnes: specific version with a specific ID
JeffH: type != version
rbarnes: set an option?
vgb: close out these PRs with no
action = Cred ID is always paired with type
... almost like a namespace
... moving type to somewhere else divorces type from ID, may
mean that IDs are unique across all types
rbarnes: can't assume that there is a binding to ID anyway
vgb: type provides a few things,
e.g. - RPID hash is a SHA256 hash of RPID; different browser /
cred type, uses ROT13 for RPID hash
... RPIDs hashes don't match, problems ensue
rbarnes: things don't blow up
until they hit the authenticator
... just put the type in when you're talking to the
authenticator
vgb: true, but how
... currently a list of creds
... put in options would mean you'd have to say "I'm okay with
ID-A of Type-A, ID-B of Type-B..."
rbarnes: that makes sense for pairing them
JeffH: would want to keep them together as is at this point
*** tumbleweeds ***
vgb: happy to abandon this PR
JeffH: 143 and 158?
jcj_moz: fine with closing 143
rbarnes: okay with this, maybe minor clean-ups
Nadalin: both, 143 and 158
vgb: two more things
... 1) Andre, TokenID
PR 164
https://github.com/w3c/webauthn/pull/164
alexei-goog: internal version structure?
JeffH: identifier,
effectively
... string of bytes
alexei-goog: spec that says how
one arrives at the string of bytes, should we indicate which of
the two methods is being used?
... being handled at the other layer?
JeffH: correct
dirkbalfanz: token binding spec
indicates RSA, EC, followed by key
... if a future version puts the key first, we wouldn't be able
to know
JeffH: doesn't matter to WebAuthn, just checking for a match
alexei-goog: attacker, same
string of bytes
... different versions
vgb: putting that in our spec
doesn't fix that problem
... could have other information in key for
disambiguation
... separate problem for token binding people to look at,
versioning
JeffH: andere's assertion is that you just do a byte-by-byte compare, and that's all you care about for this spec
vgb: if the two sides don't match, you already have a problem that will be caught at the token binding level
dirkbalfanz: object strongly, could mean different things, could cause problems
vgb: goal here is to be more
aligned with token binding draft
... up to the token binding people to make sure that there's no
way to derive the same token in two different ways, introduces
MITM attack against token binding
gmandyam: client isn't going to be interpreting token binding, just server
vgb: good question
dirkbalfanz: seems a little adventurous to do it that way
JeffH: maybe feedback to token binding spec
thx, I couldn't figure out which of you it was
<wseltzer> https://github.com/w3c/webauthn/pull/162
gmandyam: would have to implement authnr to accept either
vgb: authnr doesn't know
... just uses RPID hash
... if caller specifics strict matching, no matching across
multiple origins
alexei-goog: seems like this
works on a call-by-call basis
... request strict or not
... might get RPs into trouble? forget to add strict sometimes
and end up with a non-match?
selfissued: more choices = more developer problems, just pick one
vgb: alexei arguing that we should have that option?
alexei-goog: what's the benefit?
rbarnes: be more
conservative
... eTLD+1 shouldn't be the only option
dirkbalfanz: more of a privacy concern
gmandyam: get more explicit / concrete examples in text
vgb: point of PR was to show
concretely what the change would look like
... disagree with the change in principle?
rbarnes: not concerned about adding one flag
vgb: two different cred types (strict vs loose)?
JeffH: adding to the already long list of attributes
dirkbalfanz: didn't think this would be boolean, eTLD+n
JeffH: term is "domain lowering" (?)
vgb: why don't we just reuse that
mechanism?
... infer it from the context
rbarnes: not going to like the implications of that, then everything in JS gets scoped to that
vgb: how do we make progress?
christiaan: sharing between app and website, e.g. - Android
rbarnes: option is still there with relaxed mode
christiaan: e.g. - bank would use strict rather than relaxed because it sounds better, would take away some of the usability
rbarnes: how does it work on Android?
alexei-goog: how is app "foo"
related to TLD of "bar"
... specified by app developers
... not clear how strict would be handled in that situation
JeffH: eTLD+1 should be default,
current deployed practice
... making strict the default would hinder deployment
selfissued: agreed
alexei-goog: not sure how we describe to developers how to do it right
vgb: other remaining issue is attestation, will summarize next time where we landed
Nadalin: do we want to discuss any extensions?
<Rolf> have to leave now.
alexei-goog: I will come back with a more strongly informed opinion on strict next time
Nadalin: for 162?
alexei-goog: yes
Nadalin: next week?
alexei-goog: we can try
Nadalin: leaves us with PR 169,
157
... extension discussions
gmandyam: I've got something that
can be incorporated
... CBOR mappings
... examples of formatting of lat / long
jcj_moz: I'm good with it when complete, just wouldn't know how to implement right now
Nadalin: adjourn
<wseltzer> trackbot, end meeting
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/weiler/wseltzer/ Succeeded: s/alexei-goog (?)/dirkbalfanz/g Succeeded: s/principal/principle/ Found ScribeNick: apowers Inferring Scribes: apowers WARNING: No "Topic:" lines found. Default Present: nadalin, wseltzer, weiler, gmandyam, ketan, jcj_moz, rbarnes, Christiaan, apowers, Rahul, vgb, JeffH, Rolf, alexei-goog WARNING: Replacing previous Present list. (Old list: present, nadalin) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ nadalin Present: nadalin wseltzer weiler gmandyam ketan jcj_moz rbarnes Christiaan apowers Rahul vgb JeffH Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0080.html Found Date: 17 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/17-webauthn-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]