Web Authentication WG

26 Feb 2020



jcj_moz, jeffh, jfontana, jbarclay, selfissued, nmooney
Nadalin, Fontana


<jcj_moz> Zakim start meeting

Authenticator Recovery proposal update

<jcj_moz> Zakim help

<jeffh> jbradley: encouraging platforms look at and consider implementing this extension

<jeffh> ...will look into sharing the "shape" of the needed extension

<jeffh> jcj_moz: moz is intending to implement this

<scribe> agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0070.html

<scribe> Meeting: W

<scribe> Meeting: Web Authentication WG

<jeffh> ...thinking that we webauthn/fido need to provide for account recovery, and assuming the security review (to be published) is positive, Moz will implement

jc_moz: once we have it , we can ease a thorny issues around web authn

Ricky: there is reveiw to prove this out - when is deliverable

jc_moz: output would be the proof logic and research paper of that proof

bradley: we should have this in a month of so.
... after we get this done need to convince RP this is good thing
... backup authen can be used go get a new credential
... wneh you recover yo can create a new backup.
... we tried to separate the key material and meta data of where you used it.

jc_moz: spec on RP side is non-trivial

bradley: can enroll a credential without having your backup.

jc_moz: when the paper is published, that is when the work will start.
... specific to this mechanism.

<jeffh> ...if you have detailed questions, email emil@yubico.com (I think that email addr is correct) aka @emlun on github

ltony: still have caBLE issue in fido land, brings in network transport. any cisco updates

nickS: working on it. we will have something soon.
... we will move forward with a PR. We are are doing this on CAble to PR branch

tony: imagine there will be change over in WEg authn land.



nickM: would you prefer an issue with our current intentions.

tony: that works.
... we can track it and get it on our radar.

Arnar: for new caBLE PR there is nothing new.

tony: we should close 909


tony: enterprise attestation

christiaan: we have a PR
... fido says they need two weeks

tony: PR should have answered the questions.
... discuss on the 4th of march
... thye have had there two weeks

agl: add an entreprise attestation type ?

christiaan: merge it now?

jc_moz: it is still a enum
... we need to un-enum it
... we ran into this with transports

agl: should we touch the enum, where do we create the mess?

tony: it is a breaking change.

jeffH: we have six enum types. we need to address?
... should we apply to all enums

jc_moz: first we should do enterprise attstation .

agl: transports are special, but browser has to do something. what is the behavior

jc_moz: good question. options areedefault or error
... are a default or error

jeffH: we should submit an issue to deal with dom strng

agl: we should un-enum some things - lets take a look at what they are.
... client data serialization
... we serialize with json. proposal value is json but validators can depend on keys come in specified order...will be a conical JSON
... we are adding structure.
... it is structure within previous specification

jeffH: it should go through standard JSON parser

dwaite: if anything other than browser can access, that when someone could try to game system
... if extension where I can supply data, have to be carefull. could be client level attestation
... i am worried about some of previous issues with SAML

agl: I have said JSON is not too hard.
... referring to open SSH
... openSSH has looked at this proposal
... I can work on a PR. aim is to avoid another sub-section in Level 3
... opinions welcome.

jc_moz: i am in favor of making this easier, JSON can be a heavy lift.

shane: suggest. I did not read PR yet, parsing JSON may be preferred

agl: I will make that clear.

bradley: there are opps. here to inject bad things

dwaite: we will have to careful how we explain this

bradely: we can wind up with something now that might shoot us in the foot later

agl: i should write validator algorithms

dwaite: I think that is missing.
... we need to be clear with the validation rules.

agl: i understand the concern.
... the fix fields will never change. we could add more, but the first 4 won't change

tony: we are saying they are fixed now, but that can change in the future

agl: we are committing to never changing these four fields.

alexei: can we add a version number.
... when we do version 2 it would break everything.
... everytime we change we break everything.

proposal is client data serialization. Adam will write a PR.

jc_moz: mozilla is opposed to this.
... we have to make a PR that reverts a handful of changes.

jeffH: will be one policy for get and disallow use of create in cross origin iFrames

bradley: i don't think the payment people know this is there.
... the payment people don't like the idea of explaining a flag in a browser.

agl: it is behind a flag so we did not pre-maturely ship things.

tony: jc you will write PR for thils

jc_Moz: think jeffH should but I can help.

jeffH: OK


jc_moz: I agree with the issue and think we should close it.
... also #1293 is part of that

agl: close great

tony: and do PR for
... #1336

Ricky: our concern is taken care of by the other issue.

jc_moz: I want to make sure Apple is on board

ricky: i am saying this is OK given the feedback.

closing #1303 and opening a PR on #1336


ricky: this needs to be reconciled with get assertion in conjunction with an iFrame.
... I need to read this more closely, but need to reconcile some of what is here.

jc_moz: there are concerns at Moz. we want to build a pattern for Web Authn

agl: I strongly recommend you assume no state.

ricky: where we are, devs should assume no access to local state.

gl: I would like to have examples.


ricky: directions to devs, i would say no.
... I don't think it is a spec issue. I think it can be closed.

tony: jeff will add comments.
... we are briing uup #1372


shane: reason why I brought it up, related to scenario that web authn could not implement but u2f could
... seems to me that RP have a trust relationship does not necessarily need to have creds registered at each one of them
... i was trying to implement..
... it doesn't seem the only way should be to register all of them.

bradley: there are some RPs concerned about it.

tony: with shane's concern. some were thinking about #1372, Dirk did present some things at FIDO plenary. He will show this.

shane: how does Dirk presentation differ from what I am talking about.

tony: payments also brought this up on a call.

Dirk presents propsal

dirk: proposal RP A can create a credentail for RP B
... what about tracking/correlation?
... RP S cannon exercis the credential aftereward.
... cannot exercise ...
... looking for feedback.
... P
... and to do a PR to webauthn spec

ricky: I think we need more explanation, where do requirements come from
... UX and re-direct is something I want to understand.

bradley: we are making this case to the PSD2 people in Europe

jc_moz: so the presentation of the cross-frame credentials is concerning. how do we communicate this to users.
... this flow can be confusing.

bradley: this does not introduce correlation.

shane: facets idea is not for solving this use case.

agl: this is new form of cross origin communication. I am not the right person to give an opinion.

bradley: you have to do some kind of federation to do this
... this may be a change for the web authn on platforms
... we ar ea bit vague what web authn is.

dirk: i wil have action items

tony: have it for the web payments meetings.
... shane last words

shane: issues I have raised are different from what dirk is working on.
... totally different scenario, chance for confusion if we lump into same discussion
... I am not against Dirk's proposal. I have a different scenario.

tony: we want to leave this open for now. there is not a real solution.

shane: if consensus of the browser vendors is we are not doing facet IDs, that is the decision.
... I suspect there is good reason behind their ideas.

christiaan: we are moving away from cross origin.
... it is hard to defend now

shane: thoughts are strong here and they are landing against such a proposal

christiaan: what shane is proposing can be abused.

tony: those aree major issues for today, but some issues to close.
... #909 caBLE extensions

jeffH: which we are not going to need




tony: we will fix enum here. and #1376 will take care of the other enums.
... agl should updatge


jeffH: looks good to me.
... waiting for reply from Akshay

tony: that takes us through PRs
... we still have a few issues.
... want to take care of https://github.com/w3c/webauthn/pull/1369 in next RD draft.
... who will take this.
... shane leave #1372 open

shane: want to have something that says why we are not doing this.
... I don't know the answer

tony: do this one with other cross origin stuff? https://github.com/w3c/webauthn/issues/1377


jc_moz: i think this is no action
... I am about to land a bug

jeffH: close this?

jc_moz: it is a bug on firefox, this is closed.

tony: still working on #1207, 1208 1291

#1208, #1292

#1291 not 92

tony: apple not opposed, think we can go adhead and close this on #1292


jeffH: close


jc_moz: interested in this as an idea

tony: update this jc?
... don't close, add a comment.


agL: this is just about what you put in your UI

christiaan: like android can use many modalities, and have done it without the need for this. ]
... this is pre-cursor to RPs eliminating support for modalities .

jc_moz: this is going back to RP showing more context

agl: if you are trying to return a name or a string. names can be mis-understood

tony: should we close.

jeffh: I will close it.


tony: we need someone to do this.
... if we don't do something this willl fall off bucket


agl: lots of words on this. need someone to turn this into something concrete.

tony: somebody should create a PR

agl: add a convenience method.

selfissued: my hygiene to this is you might be introducing duplication and then values that are not the same

jc_Moz: we give back a dictionary.

tony: need a PR

agl: this is editorial thing. I should do this.

Debate on required, preferred, discourage, forbid and use cases.

christiaan: we don't have forbid today, but I want to add it

dirk: there is no need to support this use case

shane: use case is deisgn for targets

agl: if we support all four, everyone will be happy.

jeffH: added this issue after discussion. https://github.com/w3c/webauthn/issues/1379

tony: will work on CTAP 2.0 to consider this issue

dwaite: do we want to do clean-up
... clean up extensions.

jbradley: I will clean up extensions.

tony: any other topics for today


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/02/27 00:41:35 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: jcj_moz, jeffh
Present: jcj_moz jeffh jfontana jbarclay selfissued nmooney
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0070.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]