See also: IRC log
<weiler> scribenick: vgb
<scribe> scribenick:vgb
Tony: No meeting on May 10 due to
the FIDO plenary.
... trying to close on WD-05, let's look at the PRs
jeffh: the open PRs are not enough to declare WD-05. There are many places where the spec is broken as stands, and we should fix those.
angelo: Want to get to WD-05 because we have implementers working on this and stuff seems to be working.
jeffh: In that case the ambiguities must have been resolved in the implementations, we should at least document the choices.
angelo: ok. of course there will be other WDs, we just want to mark a point in time snapshot that is close enough.
alexei-goog: Google is also developing, and we shouldn't take shortcuts purely for expediency. We may have to redo some work and that's ok.
jeffh: Tony: seems like we're all in rough agreement
jyasskin: Agree with jeffh. Implementers need to file issues on ambiguities and document choices. Also want to caution that WDs change so we should not get too tied to WD-05.
Tony: Yes, but implementations have their momentum too.
alexei-goog: want to talk about
PR #409
... it was merged last week, let's put it on the agenda
Tony: ok, on to #378
angelo: believe the text is
there. consider this a bugfix. don't think of this so much as
authenticator selection as a thing to make getAssertion more
reliable for RPs.
... could also create a dictionary to capture the dimensions of
filtering requested
alexei-goog: btw this flag seems
like it wants something that "takes resident keys and has room
for one more"
... for the use case where RP will call getAssertion without a
credential ID on the allowList
... what should happen if no such authenticator exists? Should
it be NotFoundError?
angelo: possibly, open to ideas.
alexei-goog: so this seems very
similar to platform vs. roaming authenticator. So should
organize it better as jeffh suggests.
... How were you planning on giving the user feedback about
this, e.g. in the case the authenticator is out of space?
... and how would the user remediate?
angelo: Were mainly thinking of highly capable devices such as phones which can store lots of keys, and U2F style devices.
alexei-goog: But what about the middle case, with limited slots. How does the management UX work?
angelo: Makes sense. So either the RP says get another authenticator or create a non-resident key. Imagine that this is the way the RP gracefully degrades the UI in this case.
alexei-goog: May be other solutions, but should think this through before merging the PR.
angelo: this PR recognizes the possibility of resident keys. Can we separate that from fleshing out the full story?
jyasskin: Maybe we should discuss
this on the PR
... call is less efficient way of doing this
... Want to see a uniform treatment of authenticator
selection.
... Should get to consensus on that in PR.
angelo: Let's talk about
authenticator selection. Could either let RP choose in
isPlatformAuthenticatorReady, or in makeCredential.
... use cases for both.
... Could do a dictionary with all the criteria. Not sure if
there is another idea? Guessing we don't want to do an
extension.
<jeffh> jyasskin: I will submit such apres call
<jeffh> :)
jeffh: Maybe look at how UAF does
this.
... Has arrays of bit flags denoting properties, RP specifies
these at makeCredential time.
... UA uses platform-specific methods to honor this.
... Let's move on to other PRs and not rathole.
... The current approach is ad hoc, in that it adds language to
the spec every time an authenticator selection criterion is
added. We should make it a real extension point to be
systematic.
<selfissued> I agree that we should discuss the other priority:Implementation PRs
Tony: ok, now take it to the
list.
... now #350
<weiler> https://github.com/w3c/webauthn/pull/350
angelo: This is not a focus for me right now.
selfissued: Why don't we just accept jeffh's comments and merge it so we can close out the simple issues?
jeffh: happy to do this if angelo gives permissions to his clone
Tony: #423
selfissued: Fixing an omission in
a previous merge. Should be easy to fix.
... Can jeffh review and we can revise and merge?
jeffh: Naming ok with everyone? If so yes we can take care of this.
Tony: #425
selfissued: finishing up the
fixups on the extension sections. Thanks to jyasskin for noting
the issues and for all the help.
... Extensions don't work if we don't do this, can we address
the outstanding comments and merge?
... More reviews welcome of course.
... The basic issue is that at some point the flow of extension
info to the RP and authenticator was lost. This fixes that.
dirk: so this is not about transparently passign all extensions through?
selfissued: no, this is much more
basic for extensions to work at all.
... this fixes an embarrassing omission, we should just fix
it
Tony: #427
jeffh: made some technical fixups
in response to jyasskin's issue. Would appreciate
reviews.
... this is another that should be fixed.
Tony: ok, address if no
complaints by Monday.
... ok, now #409
alexei-goog: This is something
that was merged last week. Adds a bit to authenticatorData that
says the credential requires user verification (i.e. more than
a TUP).
... Issue is that we have so few flag bits left that we should
be more careful about using them up. This seems like something
that could be in the attestation.
... which could also give more detail about this.
... (i.e. could say what type of user verification is done)
jeffh: #409 postulates the RP doesn't know exactly what the authenticator can do, so authnr tells it after the fact. Other notion is that the RP just knows (out of band, maybe from attestation) what an authnr does after makeCredential.
dirk: Believe the overall
philosophy of the API is the latter.
... so unless there is a very good reason we should do
that.
jeffh+dirk+alexei-goog: there may be use cases where an authenticator sometimes does user verification and sometimes not (e.g. PIN, or cached verification)
jeffh: we may need both: better authenticator selection and feedback on user verification per assertion
dirk: can't imagine that makeCredential asked for a user verifyign credential and the authenticator decided at getAssertion time not to bother.
jeffh: ok by me
alexei-goog: gotta run. can angelo continue the discussion in email or PR?
jeffh: object to the curretn state.
all: call ended
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: weiler selfissued jcj_moz mkwst jeffh nadalin jyasskin angelo jfontana vgb alexei-goog dirk apowers Found ScribeNick: vgb Found ScribeNick: vgb Inferring Scribes: vgb WARNING: No "Topic:" lines found. Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0385.html Found Date: 26 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/26-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]