W3C

– DRAFT –
Web Authentication WG

01 December 2021

Attendees

Present
dveditz, elundberg, jbarclay, jfontana_
Regrets
-
Chair
-
Scribe
jfontana_

Meeting minutes

wendy: asked for a charter extension, asked for 6 months. don't expect to take nearly that long
… about to send out update on addressing the objections

tonuy: at the beginning of the year?
… liley 15th is last meeting of the year

tony: anything else on charter
… mozillla had no response to chat on charter

jeffH: they did not formally object, they are from other parties.

tony: will you make a PR

agl: I commented on what I saw, he wrote some words, but not a PR
… waiting for him to get back to me

tony: looks like proposed wording would close all the objections.

go to PRS

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

agl: i have not looked at response, these aren't major.

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

jeffH: work in progress

shane: when pass keys are prevalent, there is still a bunch of to-dos there, more on the way
… it feels like this extension will be called for on many requests
… interested in thoughts of more RPs

TimC: a couple of use cases.

shane: wnat a credential but no control for that.

timC: you only use device key in your logic
… there will platforms that require sync
… seom will need extension

some

agl: don't ignore primary key
… you get better flows with more verification

jeffH: I thik shane is saying how RP will use this extension - it is not clear

elundburg: there is no current in-spec precedent of RP extension processing steps, but like we added to recovery system, maybe something like that can be done here

shane: I would like to review something like that.

jeffH: attestation is not the issue, the RP will have to deal with what it gets back in terms of attestation
… it will have to factor that in risk assessment

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

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

jeffH: still work in progress, but close

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

elundburg: still holding

tony: open issues, untriaged.

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

tony: thinking this was for FIDO.

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

akshay: asking for more on this, there are 3-4 requirements we are trying to work out.
… design requirements has changed on this
… I need to look again.
… with SPC, there is an API that will call the WebAuth. public? private?
… this is in a payments scenario.
… do we need to change webauthn to help make the SPC call?
… web auth spec needs to say a third party can be enabled.

jeffH: I think that is a web authn extension

aksay: in that context can I call with web authn

agl: no
… it is payment request

jbradley: needs to be some sort of control.
… not random RPs
… we are still at the level of how this will work, rather than how APIs releate

akshay: has to come from SPC calll

jeffH: yes. jeff explains

akshay: what if RP sets this extension and does not use SPC

agl: that is not the way it was intended.

jbradley: there are restrictions, need to say that someplace
… could bve signifacnt changes on how webauthn works.

agl: i don't believe normal web authn creds can be used in SPC space

jbradley: this is what banks are asking for

agl: looking at different contexts.

jbradley: depends on how it is flagging. it determines behavior
… can separate the credentials for webauthn and spc. the topic of the other issue was to combine.

agl: that want one credential to solve all the problems

jbradley: spc is going back and forth on this.
… one thing is two categories of creds. first party and third party
… we could lose the filter of this credential is only good for authentication
… comes down to three different credentials, some good for multiple things
… storage is tricky part.
… only tough the SPC logic and not first part.

touch
… waiting for a good idea here.

agl: aren't these good ideas.

jbradley: it can work, doesn't feel clean.
… could get conflict

elundberg: using userID is not the best idea.

jbradley talking about credential management API; but that could means changes to CTAP 2.1

elundberg: there is a drawback.

jbradley: almost a new data member rather than re-using cred blob
… not much cred blob deployment

akshay: opinion, both ideas I really do not like.
… if you keep changing requirements it looks more and more like it needs a new property on the keys
… user ID or cred blob is not something I want to change
… I don't want to tangle with first party

jbradley: the name space does not let third party SPC cred used for normal WebAuthn authentication

akshay: I do not see that solution right now

jbradley: could do name space thing, but if you want to use SpC for cred in first party context, then we need to do something different in name space
… if we separate the SPC cred, so it is not used for normal authentication, they may ned two name spaces

akshay: they have their own server logic

jbradely: I will look at it to see what we can do, but some of the browser may have to change

jeffH: it could be a client extension and not pass down to authenticator

akshay: thinking that with SPC

jbradley: maybe we never mix SPC context

agl: I want to talk about JSON

Martin: Issue1683
… want JSON serialized - all the RPs have to write their own serialization
… shold we make RPs lives easier?

akshay: if it helps RPs i am favor of this

tony: does not seem to break anything.

martin: it is backward compatible.
… default case for simple RP

tony: is there support
… agl?

agl: yes

dan: I would want to support this
… I would support in mozilla at some time later

agl: JSON here would not unpack authn data .
… would turn into strings

Minutes manually created (not a transcript), formatted by scribe.perl version 159 (Fri Nov 5 17:37:14 2021 UTC).

Diagnostics

Succeeded: s/is some explicit language, like/is no current in-spec precedent of RP extension processing steps, but like/

No scribenick or scribe found. Guessed: jfontana_

Maybe present: agl, aksay, akshay, dan, elundburg, jbradely, jbradley, jeffH, Martin, shane, TimC, tonuy, tony, wendy