<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