See also: IRC log
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[End of scribe.perl diagnostic output]