See also: IRC log
<JeffH> craft beer in hong kong: http://gohongkong.about.com/od/hongkongbarsandclubs/ss/Best-craft-beer-bars-and-ale-pubs-in-Hong-Kong.htm
<weiler> scribenick: gmandyam
nadalin: Thanks to all who helped in publication of RD 02
<weiler> scribenick: JeffH
gmandyam: thinks that attstn formats that are vendor-proprietary and do not have "complete" specifications need to have their attstn format identifier prefixed with a vendor-specific ID
... asserts that safetynet is an example of this -- there's opaque fields that are not documented -- is just a vendorspecific attstn
... when they (RP) read the spec, they can verify the packed attstn by just reading the attstn spec -- for safetynet that's not the case -- the RP needs to contact the vendor in order to figure out how to validate the attstn
alexei: this sounds like you are arguing against safetynet specifically -- you don't know about lots of items under the hood wrt attestn, such as who's code is performing the hashes/sigs....
gmandyam: notes that goog does supply a online svc to validate safetynet but it is a single point of failure...
alexei: so it seems you are arguing to designate the attstn format as sort of a 2nd class citizen...
gmandyam: thinks we should have two levels of review of attestation formats -- one is for interoperable indep impls ones -- other for vendor-specific single-source ones
... thinks for packed / tpm=based there will be more than one impl
<weiler> scribenick: weiler
gmandyam: thinks there are different vision re: registry doc. proposes a separate registry doc, as an issue.
... rather than have it buried in a pull request.
<JeffH> https://github.com/w3c/webauthn/issues/221
alexei: not sure 221 has merit.
vgb: richard thinks acct into is not or the UA. want to discuss further with him. vgb thinks this is good future-proofing
alexei: for a large class of authenticators, it will get discarded by the UA. could be useless work by RP for a large class of authenticators.
vgb: for this class of authenticators, allows smart things in UA
... on machine where you create credential, store identifier....
... doesn't really hurt.
gmandyam: we don't want current state, where this is mandatory.
... is it safe to say that this should not be mandatory in makecred?
vgb: no. I think it should be mandatory. even those some don't use it.
alexei: confusion induced by not providing it is worse than extra work on RPs in cases where it is not used. and I buy that argument.
gmandyam: increasing testing burden on UA vendor.
vgb: I think it reduces the testing burden. one code path.
gmandyam: if UA doesn't want to pass info, it has that option, right?
vgb: yes, but it violates the spec.
gmandyam: authenticator won't use this, so why would it pass it on?
vgb: from the developers perspective, if you call API in legal way, don't want surprising results.
... if we do this, developer has know that @@
... allow list must contain only one credential from that authenticator
... this is very balanced and nuanced.
... easier to say "slap the user's name in there"
gmandyam: ... could choose not to make any of these available. developer won't now about this in advance. could be legit reasons for this.
... if those authenticators don't accept info, developer won't benefit, since not known in advance.
vgb: but at least developer knows the best thing to do.
... want to avoid situation where developer doesn't know best thing to do.
... i can't summarize to developer, if we make acct info optional, what the right thing to do is.
... if have creds made w/o act info @@... this makes my head hurt
alexei: agree w/ vgb
... undue burden on RPs
vgb: need t convince rbarnes, who isn't here
jcj: I can help with that. can't speak for rbarnes, but 2nd point re: tunnel scenario makes sense to me and should make sense to him.
... we had misunderstanding re: how this field will be used.
... should point out in non-normative that even if this isn't USED, it's USEFUL. and it's future-proofing.
... I'll talk to rbarnes.
jeffh: jcj has also responded in issue 221.
... and alexei.
alexei: may I abandon 220?
jc: yes, but don't close 219 yet.
... close 221.
jeffh: talk to rbarnes first?
nadalin: concurs with path.
vgb: rolf and girl pointed out different ways to do this. rolf: 3-level to 2level. girl: keep 3 level and...
... later this week, I'll send out a couple of PRs on this.
nadalin: sounds good
nadalin: have people looked at 216 (alexei's proposal)
alexei: I should make a PR. that will be easier to discuss.
vgb: had, in principle, agreement in room. just need to implement.
giri: this is the only hangup I had on mapping u2f... use of apped v. RPid. if we can compromise on that, ....
alexei: glad to hear you're on board.
nadalin: cxl next week because of fido plenary.
weiler: do we need a blog post for new WD? I'm assuming not
... [silence] ok, done.