Web Authentication Working Group Teleconference -- 06 Jun 2018

<weiler> scribenick: jfontana

<weiler> reporting on a todo item from last time: Yuriy has joined the WG as an invited expert.

tony: start with PR.

https://github.com/w3c/webauthn/pull/842

jeffH: I have something pending

https://github.com/w3c/webauthn/pull/884

elundberg: waiting for some response

JeffH: I have a review in process

akshay: should we do a separate PR or drop it?

selfissue: I don't think we need to wait.

akshay: I wold like to see more detail

elundberg: OK
... do we add anything to this one or is it a future PR

jeffH: in other words this is a good start and we can improve on it.

selfissue: this improves this spec, I don't think we need to wait

https://github.com/w3c/webauthn/pull/888

elundberg: we need to resolve the IPR issue

selfissue: this can be merged.

tony: our outside expert was approved

wseltzer: I will click "revalidate"

elundberg: I will go ahead with merge

https://github.com/w3c/webauthn/pull/899

tony: should be ready to go

JeffH: I want to look at it.

https://github.com/w3c/webauthn/pull/900

tony: we have 4 approvals. ready to go?

elundberg: I will merge

https://github.com/w3c/webauthn/pull/904

tony: adam can you resolve conflicts

agl: yes. and I will merge

elundberg: there is another PR into this one. it's linked in the comments.

agl: I will bring that pull request into 904 and do the lot together

https://github.com/w3c/webauthn/pull/906

akshay: I want to review

https://github.com/w3c/webauthn/pull/914

tony: any issues. think everyone has signed off

elundberg: may need some changes to align with #901
... I can do a pass and followup

selfissue: this can be merged once the conflicts are resolved.

https://github.com/w3c/webauthn/pull/914

check that

https://github.com/w3c/webauthn/pull/934

tony: will you look at it . this is new.

selfissue: yes

https://github.com/w3c/webauthn/pull/935

selfissue: I though we already had an issue around this

akshay: we have an issue I opened

selfissue: is the other issue linked from here. yes. OK. I will review

https://github.com/w3c/webauthn/issues/873

JeffH: in progress

https://github.com/w3c/webauthn/issues/905

tony: I thnk we decided that this would get added to the PR milestone.

akshay: yes.
... think we should do that

https://github.com/w3c/webauthn/issues/929

akshay: let me look at it.

tony: let us know what you do with this
... I will leave it unclassified for nwo

https://github.com/w3c/webauthn/issues/930

tony: any one look?

jeffH: not yet

selfissue: is the request here to say we are doing same as in CTAP

ag: two things, can be data URL should browsers always download the data and give it to the icon

agl

akshay: what we are saying is that there are two versions of this
... this URL can be a data URL

elundberg: I agree with that

agl: IN small authenticator you have less storage. others want the resolved data which is much bigger

elundberg: you could have some field to see what the authenticator wants, but that could be a breaking change

akshay: client can decide what it wants.

tony: a lot of bytes could be added here. blows up message size

elundberg: think now that the URL can be a data URL and punt on if the client should resolve

selfissue: I agree
... can you point out it can be a data URL and call it good

agl: yes

akshay: I am oK. seemed incomplete but an improvement.

selfissue: converting to data URL wold blow up message size

apowers: IN the CTAP spec it can be data URL or regular URL but does not specify

selfissue: there is already a display capabilities issue that we punted to v2. so not do that
... but now will repeat statement that URL can be data URL and point to RFC that defines data URL

https://github.com/w3c/webauthn/issues/932

jeffH: take look at PR and make sure it is correct.

akshay: I will look

JeffH: it is HTML spec....you can't tell where the RPid hash is created.... this would address that
... it is only implied in the spec

https://github.com/w3c/webauthn/issues/933

jeffH: this language seems incorrect. Emil agrees

elundberg: it is not possible for the autheticator to do that validation

jeffH: I can do a new PR or put it in #933 or is it #932

tony: can you do a separate PR

jeffH: yes.

<jeffh> https://github.com/w3c/webauthn/issues/assigned/AngeloKai

<jeffh> https://github.com/w3c/webauthn/pulls?q=is%3Aopen+is%3Apr+milestone%3APropRec+assignee%3AAngeloKai

tony: there are still a number of open issues, we want to get out to PR
... we need to talk about interop, so I can submit that doc
... I wnat to get any of these technical changes in for interop

jeffH: when do interop

tony: before we go there, lets talk about any open issues

akshay: I think you can close #864
... #851 move to v2,

selfissue: hold on, yiou jumped number

akshay: #864 close

jeffH: no. there is an editorial change we need to make.

akshay: OK

jeffH: I cam gong to take all my editorial issues and batch them up
... on #864 we just need to add some documentation to this spec

akshay: also #851
... we have been discussing but all looks like v2
... we should mark it as a v2

selfissue: what is the issue here?

akshay: he is saying, in certain scnario key stores that are there on machine get reset. ..then what you have is fail...this is not what RP is looking for...what to do in those scenarioes
... this is something that is breaking so move it to v2
... that is basic premise

selfissue: doesn't sound like spec change, sounds like best practice

akshay: he is looking for the solution, he has not proposed anything

agl: some spec changes are needed, internal authenticator transport site

selfissue: did we do that

akshay: what we did was enum thing

selfissue: we split non-breaking and breaking change

akshay: to solve need more change... I will let Ebrahim what he is looking for

jeffH: I am adding a comment

agl: Chrome 67 has webauthn on
... stable

selfissue: can you use FIDO2 authenticators

agl: it is not speaking CTAP yet. it is web authn U2f(CTAP)

apowers: there is a flag for CTAP2 support

tony: any more on issues

on to interop discussion

tonuy: we have to fill implementation experience for PR

interop requirements and timing

tonuy: we need to show the spec is clear and complete and meets markets needs.

<apowers> You can download Chrome canary right now, and run it with "--enable-features=WebAuthenticationCtap2". This will enable WebAuthn (and disable U2F).

tonuy: as part of that we have to test each of the spec features. need to make sure 3 independant implementation.
... need to list the implementations. we don't have to report the results of the implementation only that we have tested all the features
... of the implementations.
... the test cases that we had are complete , but we will probably have to sked an interop coming up
... we need it to create this report and put in the packet when we go to PR

<wseltzer> https://www.w3.org/Guide/transitions?profile=PR&pr=new

wseltzer: to clarify the director in reviewing the transition request to PR wants to see evidence of interop
... don't need names.
... we do need evidence on feature on feature basis.

<wseltzer> https://www.w3.org/2018/Process-20180201/#implementation-experience

wseltzer: this is a requirement in the process

tony: it is not in the current directive

wseltzer: but the director needs to be convinced...

tony: we have to try to wrap up the technical issues we have for PR
... we need an interop. When?

akshay: MSFT is ready

agl: you want CTAP2 suport?
... can we use a non-stable version

tony: it does nto have to be publically deployed

<jeffh> current MS:PropRec [type:technical] issues: https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+label%3Atype%3Atechnical+milestone%3APropRec

kpaulH: we should have this in canary in the next week or two. last week of june is bad.

tony: July

kpaulH: that would be ok

apowers: firefox may be an issue, jc out

kpaulH: we may be able to do it earlier.

tony: do we need on-site

apowers: on-site if we need de-bug

<jeffh> IETF is week of 16-Jul-2018

agl: isn't the problem we want to check registration on one machine produces credential that works on another machine

tony: so I am hearing we may have to have an in-person one. it would be small.

akshay: is saying he'll do it with all browsers and test this

tony: we also need to show different authenticators and platforms.
... move from android and move it to windows,

agl: you can have chrome on win, mac, android

kpaulH: chrome on android still demoing, have something else in a couple of weeks. but maybe not in time for interop
... we are on the way to stable.

tony: maybe we need to push it out to July and cover for JC_jones
... I want to cover the bases. part of this may impact extensions
... so I want to be complete with variious platforms and authenticators

wseltzer: suggesting. there can be multiple implementations, but success requirements is two independent implementation reports for each feature
... we can go with that at PR and continue to iterate.

tony: Ok

<apowers> When I'm out (late June - mid August), if a bug is urgent and cc'd to David Keeler (:keeler), he will help find solutions. The link above will do that.

- DRAFT -

Web Authentication Working Group Teleconference

06 Jun 2018

Attendees

Contents

interop requirements and timing

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output