<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