Thanks, Wendy'

<scribe> scribenick: vgb

<wseltzer> open pull requests

<wseltzer> https://github.com/w3c/webauthn/pulls

nadalin: look at PRs

<wseltzer> https://github.com/w3c/webauthn/pull/154

nadalin: how about 154?
... no objections, let's merge it

<wseltzer> https://github.com/w3c/webauthn/pull/157

nadalin: #157?

gmandyam: addressed feedback from JC

jcj_moz: okay with it now

alexei-goog: still going with strategy of putting things in main spec but still optional?

nadalin: yes

alexei-goog: Google likely won't implement it, just to set expectations

gmandyam: ok, Snapdragon web engine will likely implement

selfissued: clarifying that registry != specification of extension

nadalin: any objections to #157?

jcj_moz: Mozilla agrees with Google that likely won't implement at first, though this is specified okay

rbarnes: Reminding folks that we will need two independent implementations

JeffH: even of optional parts?

<wseltzer> https://github.com/w3c/webauthn/pull/162

rbarnes: Let's discuss more when we get there, but obviously more implementations is better

nadalin: #162?
... not enough bake time on this yet?

selfissued: this one is concerning - more options hurts interop

rbarnes: this improves security though

jcj_moz: like this change from a web dev perspective
... eTLD+1 matching does not feel normal

JeffH: normal for cookies though
... default there
... okay with allowing both though

rbarnes: why choose cookies and not other DOM storage things which are per-origin?

dirk: can we use domain lowering instead of Boolean?
... allow caller to pass in domain of applicability, and check that it is permissible by domain lowering rules

nadalin: maybe we need more time to think about this one and discuss
... #161?

<JeffH> vgb & rolf are having off-list discusion wrt PR#161, tho both have been on PTO, but expect to send update to the mailing list later this week...

<JeffH> ...trying to figure out a "meet in the middle" approach... eg have a single attstn format, and the RP can get details from the metadata service (MDS)

thanks for scribing that JeffH

<JeffH> giri: wrt attstn registry, if u propose a new attstn fmt, then you just spec the rawData, and then it all works; and one'd have a ptr in the registry to the spec

gmandyam: can just point to external specs for attestation rawdata formats?

alexei-goog: maybe strive for progress not perfection - just define 1-2 formats?

JeffH: we have that already, this is orthogonal

<JeffH> vgb: this is more about normalizing the claims attstn formats can make

<JeffH> ...make it so that each attstn format can claim the same things, but the 'trustworthyness' might be different, eg whether it was done in hardware or software...

gmandyam: can we do this later as part of reviewing new formats

<JeffH> giri: hm, maybe we can't really make decisions wrt "trustworthyness"

<JeffH> vgb: the currently defined tpm attstn format is broken. we're not taking on responsibty for "trustworthiness", we can't express presently the characteristics of say a TPM-based authnr

gmandyam: what else is important other than key storage?

vgb: user verification.
... will update this week on progrerss with Rolf

nadalin: #164?

selfissued: Andrei put into the spec that TB apps should treat the ID as opaque

jcj_moz: Is DOMString right?

vgb: Remember this has to be serialized to make clientDataHash

dirk: had promised to think about this, forgot. let me sync up with Andrei
... Feel that apps treating this as a pub key is better.

JeffH: will also bring it up on unbearable list to ask why it is a key anyways instead of an ID

selfissued: Expect that more or different things may go into ID as TB evolves, don't want to break apps when that happens

alexei-goog: Does that mean you need a canonical serialization format?

selfissued, JeffH: that's already true

<selfissued> I have to step away for a few minutes because a repairman has arrived at my house. Jeff can speak to my PR #187, which is strictly editorial cleanups.

alexei-goog: Agree with Dirk, but maybe it's okay for WebAuthn to treat this as opaque

samsrinivas: How final is TB decision on this?

JeffH: Fairly so

dirk: Believe the same

nadalin: wait for Dirk to confirm before merging
... #169? Rolf is not on call.

Rahul_Ghosh: This is independent from UVI now.
... As Rolf had wanted.
... this has been discussed and seems to be agreeable to everyone.

nadalin: Any objections to merging?

JeffH: Go for it.

alexei-goog: for transparency, Google likely wouldn't implement this either
... in the first implementation

<wseltzer> https://github.com/w3c/webauthn/pull/169

nadalin: #185?

<wseltzer> https://github.com/w3c/webauthn/pull/185

JeffH: low-hanging editorial fruit
... fits just fine with #187

vgb: will go through #185-187 later and merge them as I go if that's okay

<selfissued> Sounds good

JeffH: #186 - this is change from Respec style to Bikeshed style
... Bikeshed already produces a consolidated IDL At the end.

<wseltzer> https://github.com/w3c/webauthn/pull/186

nadalin: that concludes review of PRs

vgb: will do 185-187 late today/early tomorrow

nadalin: that leaves eTLD+1 and attestation

dirk: left a comment on the eTLD+1 request

nadalin: trying to get to a point where we can update the public WD

JeffH: believes no additional process to do that
... so why not publish early and often?

nadalin: prefer to be in more solid state

JeffH: this is separate from whether we can rev the WD

wseltzer: Yes and it's a good idea to do so whenever we have a cohesive doc

JeffH: propose we merge these PRs and rev the WD
... "these" meaning even just the editorial ones, and can do another for the contentious ones

nadalin: Objections?

alexei-goog: agree we should do another WD soon

gmandyam: Thinks we should wait for the attestation change
... but also okay with doing a new WD now and another after that change

JeffH: won't kill anybody if we do another WD in a week

nadalin: consensus ? objections?
... no objections, so let's do a new WD after #185-187 are merged

wseltzer: will work with weiler and vgb to do that

nadalin: so likely no CR at TPAC, but hopefully soon after

vgb: Bunch of issues around treatment of RP ID string (type, casing, etc.)

JeffH: this should be done with pointers into HTML spec
... as Anne suggests in #178
... learned about this this week as part of reviewing other specs

vgb: okay, will look at that this week, please paste in pointers to the issues if you have any

JeffH: was reviewing issues this week, and added milestones to them (defaulted to CR)
... could also go through and review ones tagged as WD-01
... nad maybe create a WD-02 and so on

nadalin: there are 16 WD-01, should we go through those?

<JeffH> https://github.com/w3c/webauthn/milestone/4

vgb: Giri, are you okay closing #98?

gmandyam: yes, though do think we have issue with UVI which feels opaque
... should talk to Rolf
... but will put in this comment and close the issue

nadalin: let's review WD-01 issues. #6?

alexei-goog: can we put that in ScopedCredentialInfo?

vgb: is this instead a job for metadata service?
... there is now an AAGUID everywhere

alexei-goog: will think

JeffH: how about we move things to WD-02 unless we have a compelling reason to keep in WD-01?

nadalin: #60?

alexei-goog: thinks we decided to not align because of the difference in cloning behavior

JeffH: so this is about cleaning up names now mostly
... also we should punt to CR (the backstop milestone) if we don't think we will do something imminently in a WD
... #86?
... might want to do this as part of attestation

gmandyam: thinks that #103 does not belong in the spec
... proprietary formats don't belong in the spec

nadalin: can we close #108?

<scribe> ... done with no objections

<scribe> .... new WD by next meeting then, if no new problems emerge

JeffH: will add WD-01 tag to the PRs we're targeting

gmandyam: want to talk about attestation registry
... thinks we need to put JeffH's doc in Github
... happy to help if needed
... we need to be clear about what can be done to clientData for example

vgb: agree, something like this is in my PR

<JeffH> vgb: tends to agree w/gmandyam

<JeffH> ....authnr extensions should not modify clientData -- rather should put addtn'l data in authnrData

gmandyam: feel that SafetyNet is problematic and should be marked proprietary, to be treated differently than say TPM which is developed by a standards body

JeffH: would you please write that down so I can process?

gmandyam: already did, proposed prefixing the name
... feel that the format is underspecified, and no way to fix the Google site which is the only spec
... will file an issue about this asking to remove SafetyNet format

nadalin: AOB?

<gmandyam> *Thanks to the scribe!

<wseltzer> https://www.w3.org/2016/09/TPAC/

nadalin: Hearing none. Remember to register for TPAC!

wseltzer: Come to TPAC! It's great fun! Lisbon!

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)

Found ScribeNick: vgb
Inferring Scribes: vgb

WARNING: No "Topic:" lines found.

Default Present: weiler, wseltzer, rbarnes, ketan, JeffH, jcj_moz, Rahul_Ghosh, vgb, selfissued, nadalin, gmandyam, alexeigoog, dirkbalfanz, jfontana, samsrinivas
Present: weiler wseltzer rbarnes ketan JeffH jcj_moz Rahul_Ghosh vgb selfissued nadalin gmandyam alexeigoog dirkbalfanz jfontana samsrinivas
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0151.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 31 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/31-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