WebAuthn F2F

07 Mar 2019



James_Barclay, Arnar_Birgisson, John_Bradley, Christiaan_Brand, Alexei_Czeskis, Pamela_Dingle, John_Fontana, Jeff_Hodges, JC_Jones, Michael_Jones, Adam_Langley, Tom_Lowenthal, Tony_Nadalin, Kim_Paulhamus, Adam_Powers, Steven_Soneff, Nick_Steele, David_Waite, Shane_Weeden
Nadalin, JFontana
wseltzer, jfontana_


<inserted> scribenick: wseltzer

Nadalin: Welcome
... Goal of the meeting is to kick off Level 2
... make some decisions about work that would involve big changes
... so we're not dealing with big changes at the end

Authenticator Selection Enhancements

Nadalin: proposed by Rolf
... to date, I haven't heard support other than from Rolf

agl: 991 has some benefits


sbweeden: user experience
... inform user about site capabilities based upon what they register
... how do we help the user, who may not have resident key

john_bradley: agree we want to support it
... what would it actually mean
... in practice

christiaan: other side, wanting the option to say I forbid the making of a resident credential

johnbradley: different PR. don't have the option not to request a PIN

Nadalin: you have the potential metadata when you first register

johnbradley: after you register, you get metadata

<jfontana_> test

<jfontana_> Do you want to tag team scribe duties?

jcj: Browser finds out at make-credential
... RP finds out after registration

sbweeden: It's a UX issue
... As someone registering a key, I want the best possible experience
... Relying party doesn't know capabilities of my key before they call register
... RP wants passwordless, resident key, if they can
... but they'll take non-resident if that's all the user has.
... How can we get that?

christiaan: we raised this in a FIDO doc

Nadalin: We closed 987 after sbweeden opened it

<scribe> ... closed as a breaking change

agl: 987 is different, it's about RP detection


sbweeden: I want to ask for it, know what was done, so can use it later

christiaan: we can't adopt resident credentials until we have

alexei: I like this. let's do a PR

Nadalin: fairly big change to RPs

agl: we can do it in a way that doesn't require changes to RPs who don't care about it

Nadalin: could be a bad breaking change for existing RPs

agl: not if we're not silly

sbweeden: response too, how does the authenticator indicate what it actually did

Nadalin: JeffH is working on a PR

[discussion of timing of conference calls]

johnbradley: happy to work with JeffH and sbweeden
... I'm not sure about tri-state

Nadalin: want to avoid breaking RPs

sbweeden: raises a point about versioning the API

Nadalin: 476, JeffH suggests we close

jcj: I agree


johnbradley: too many options

Nadalin: closing
... We'll come back to 441 and 479

UAF Support

Nadalin: 408


agl: re UAF generally, only if there's someone prepared to argue for it

Nadalin: I've asked and haven't found an advocate
... propose to close the UAF issues, 407, 408
... if a supporter wants to put back, come argue for it

JeffH: sure

Nadalin: Closing 407, 408


Nadalin: 909


arnarb: ready from our point of view

Nadalin: do we expect browsers to support?

agl: we expect chrome to

jcj: we don't expect to implement in browser, but would pass through if natively supported

johnbradley: would you use on android?

alexei: lots of use cases

[discussion of non-credential-bound CABLE connection]

jeffh: nominally this is mergeable in the webauthn spec

Nadalin: we can't create normative extensions arbitrarily

jcj: a concern. what if the extension comes through and the browser drops it
... will that put users into confusing space

arnarb: if browser doesn't pass on cable registration session, RP will either have to fail or skip

christiaan: example of bank, if the data is available, can enable more use cases opportunistically

jcj: Thinking about the getassertion side

christiaan: we do lots of messaging in browser for the user, so the RP doesn't have to do it
... the browser, platform can give user better advice about what's available

arnarb: registration extension entirely handled by authenticator

Nadalin: does it cause confusion for user if register and can't use

arnarb: compare bluetooth key today, where can register with USB, use with bluetooth later

christiaan: I can register anything, and then show up later on a different machine where it's not avaialble
... the browser can be smart to make the right offer

Nadalin: just making sure we've got that case covered

christiaan: CABLE is a transport and it has extension data
... it only works when you send an allow list

Nadalin: where do we end up on 909?

jcj: not opposed
... worst case, we end up backing it out if there's not enough support
... we probably won't write code, but would pass through where available

david: prefer to wait until CABLE is exposed publicly
... it's currently only in FIDO

Nadalin: we had the same issue with hash
... if we put this in today, we're not defining CABLE, but an extension to use some functionality that could be defined elsewhere
... so here, saying create the framework. Look elsewhere for its implementatoin
... It's an optional extension.

david: concern, not objection

Nadalin: hearing no objections, some concern
... can we get a few more approvers to merge this?
... jeffh, jcj ?

jcj: I added an editorial comment
... once that's resolved, sure

Nadalin: please resolve jcj's comment

jcj: and expect me to raise an issue later if FIDO doesn't publish
... seems cool.

Authenticator Selection Enhancements (2)


agl: In consumer context, this seems to add complexity
... don't see a reason to do this
... ways to filter

Nadalin: UAF had a policy language; this supplements

christiaan: objection
... don't see a use case for the consumer
... would you want RPs to be able to say what authenticators they accept?

Nadalin: Akshay has said he's not in favor

johnbradley: other ways for enterprise to guide users

jcj: All these selection things to avoid rejecting attestation after the fact
... what happens when we strip attestations, as Firefox will default
... You can do this after the fact.
... General use case should be as wide acceptance as possible
... Optimize for the general case

apowers: Amazon merchant use case

johnbradley: policy language not more usable

nsteele: most implementations not using AAGUID but certs

alexei: either browsers or websites have to tell users something didn't work
... RPs can do better at telling users what to do instead

apowers: browser in better postion to know what user has available

johnbradley: not necessarily, e.g. bluetooth

apowers: are you concerned from privacy perspective?

johnbradley: fingerprint vector

christiaan: and do we need it

apowers: high value consumer users

agl: don't add complexity for the edge case; you can do better UI elsewhere for important cases
... when we try to do things in browser UI, websites fight us on it

apowers: worried we're leaving a big chunk of the market

Nadalin: Any objections to closing 479?
... hearing none, closing.
... 441?

agl: close

jcj: same sort of thing


johnbradley: not useful except in very constrained environment where it's not needed

Nadalin: Any objection to closing?

<scribe> ... Closed.

Nadalin: that closes all the issues noted for the morning
... We kept 991, 909 open, and closed the others.


<inserted> scribenick: jfontana_



Kim: we want smarter UI. thinking

tony: this would be a change in error conditions

kim: at some point the spec supported this, not just the Windows case. The spec should accommodate both use cases.

Alexi: at some point browsers did not have UI for this so everything blinked.

Tony: still lot of value in the blinking
... value is showing authenticator is working


jbradley: on thing we are proposed to change with Cred API. There is no allow list. Can't tell if there is a credential
... the flows will be changing.

jcj_Moz: right now in Ffox, we blink everything. We want this to be the case. Leaving space for UX to be smarter is cool
... we should think about this from privacy angle.
... the user should still have to have some interaction

jbradely: has to be some kind of interaction

discussion: MSFT does not blink everything

jcj_MOZ: as long as we can ado both. logically we will settle on optimal thing.

Im: i think that is fine, previously it was either or.

[discussion on blinking on authenticator]

Kim: I think we will write a PR

Tony: is it for this issue. does it also include the solution to this issue

Kim: yes.





scribe: mozilla wants to do this in a way that is opt-in

AGL: Chrome position,too

christiaan: maybe there isa either or. a group policy or do it on the token
... I think the browser will be responsible in allowing this - in consultation with the user.

alexei: we need to do more research. Don't close, leave open

christiaan: we should add this in CTAP, and on web authn we can leave to policy

agl: I don't want this to happen, that users demand this. ....

jbradley: we are using pre-reg on tokens to get around this.
... in some instances.
... there are some down sides.
... works for some enterprises.

[discussion on credentials being made on token]

shane: think concept of enterprise can be expanded more broadly
... bank customer, assigned to an account. not just enterprises, it is bindings 1 to 1 , token to account

jbradley: you can do that manually.
... it is enterprise mind set. Credential that is important here.

alexei: exploring if we could get rid of individual attestation and do something else.
... hoping to come back and report what I learned with #1147

jbradley: having individual attestation is a challenge to not violate privacy.

shane: this is almost a contradiction to a run on serial numbers.

tom: it feels much like a credential.
... attestation seems like it is fit for account, is it member of authenticators I trust?
... this does not feel like attestation, feels like credentials; but not like the other credentials. feels like third thing.

[discussion on credential/attestation]

tony: alexei will look at this and come back with additional info.


tony: there is a registry question

selfissue: the authors of the registry spec - JeffH primary- are working with IETF to finish making that an RFC.
... the pub deadline is Monday.
... I don't think there is biz case for adding to Web Auth,

tony: just let this happen on IANA?

seflissue: yes

jeffH: I think we are in agreement


tony: do we let this happen by IANA also.

serlfissue: I would say yes.
... #1121 can use the registry that is being created by IANA

tony: this is likely how we should deal with any attestation we end up creating here.


tony: we need to write a PR.
... assigning to Elundberg


alexei: I made a PR to remove almost all SafetyNet references.

apowers: do you do IANA registration?

jeffH: yes.

tony: for safety net

selfissue: it will be registered.
... it is in IANA requirements for Level 1

apowers: I will look at #968 and close it.

arnar: we can find Android people to help close it.

apower: OK
... I will look at this are get back to baseline.

agl: these should be android problems, not web authn

User Verification

tony: go to user verification isues.


correct: https://github.com/w3c/webauthn/issues/1162

tony: keep this open and chip away at it.


tony: think Mike had some issues.
... look and see if it addresses the issues


tony: we don't have the ability to address these things?

jcj_moz: I think it is fine.
... the normative aspect is not in the spec

[discussion of #1118

selfissue: I am OK in merging #1118 and moving on
... adding the example, also helps, which is #1165
... I will reveiw 1165 and 1118.

jcj_moz: I will approve it.

tony: so we will close 1117, when 1118 is approved.


correction: https://github.com/w3c/webauthn/issues/911

tony: to use feature policy, we just need a value.

agl: our web payments guys want i-frame support, how do we advance that.

jeffH: I have been chipping away on this with M. West
... we won't solve this today...

tony: we should try to influence the web app sec people in the direction we would like to see this go and to help move things along

jcj_moz: we should support permissions, feature policy does not
... if we have to make a choice, we should do permissions - for user interaction.

tony: asks if jcj_moz can work with web app sec
... we need the support which ever way it goes

agl: can we send a message to web app sec

wseltzer: I can send a message - needs to be a clear message.

jbradley: we need this to solve some issues - leaning toward permissions.

jcj_moz: looks like Ffox and safari and chrome have permissions - I can look into Edge
... all we have to do is define the string and refer to the document.

tony: we need web app sec credential piece

jeffH: we need to make something happen that is not awful

jbradley: let's inform the group.

selfissue: can this be put in the issue, agl?

tony: I will put a stake in the ground.

agl: we are looking for guidance...

tony: yes.


[discussion silent authenticator issues]

tony: not in authn, but are in CTAP

Silent Authenticators

tony: wht do we eant ot do here.

<wseltzer> https://github.com/w3c/webauthn/issues/199

tony: they can create some security issues
... not seeing big demand. Google may have one.

tom: is there a use case


tom: what are the use cases just for color

selfissue: one co. want to put silent authenticator in racks fo machines and use it as unforgeable way
... there is nobody there for physical presence.

tony: there are payment issues, if transaction is of certain value may not do again the authentication ceremony
... I am not proposing for Web authn. just asking. JeffH opened this up.

tom: could I get the super cookie description

jbradley if you remove user consent for creating for getting cred. and allow remote RPs - they potentially it becomes way to tracking some.

toM: does not sound so much like a big issue
... when we clear cookies, I would no longer do no touch, I would do new touch.
... I think we know how to mitigate this issue

jbradley: lookingfor way around. lots of ways to create super cookeies. not the end of the world. but this is a privacy issue.

tom: I don't think it is good for any web standard to create some thing that may track people
... there are clear ways to attach silent or not-silent privacy controls.
... note that this is scary danger zone.
... and also I think we can probably rely on browsers to not create a super cookie

jbradley: maybe we need something like token binding.

jbradely: creds are not stored in the browser. they can be persisted over a long period of time

agl: I suggest close not action

apowers: we have lots of interest in here, rest api, alexa devices.
... you still want device to show the user is stillthere.

agl: ctap 2 will do this.

shane: what about browser sesssion scenario

jcj_moz: all of these things could be done in a session, we are really talking about having public key crypto version of that
... the continual consent actions of this, is thet one use case that makes sense. question, are we adding that much. How much difficulty do we add for small improvement in security
... we are really talking about something that can auto re-fresh cookies in environment where you are not regularly logging in

pamD: europeans will have something to say about this. PSD2
... the EBA specifies a time limit.

agl: does apowers example require the web?

apowers: if you sniff an entire session, can grab the cookies. ...

agl: ctap2 lets you do silent authenticators...

apowers: the primary use case for us is a ctap2 use case.
... but want this to apply through web as well.

agl: you want continues authentications, the worry.

apowers: compromise

jcj_moz: my question, where does this fit into a web worker?
... not trying to belittle apowers use case, just want to make sure we will use this if we implement

apwers: you dont' want to burn out your security key because every call goes thorugh it.

jcj_moz: on one hand we are saying we don't trust the web security model
... is this CTAP 2 over a separate session?

apowers: I don't like sessions, necessarily

jbradley: there is a spec there

apowers: token binding. :-)

tom: the log in solution will make sessions the weakest link.

apowers: that is philosophical

jbradely: if you exapnd web authn, it may become more confusin gto people.
... this ties sessions to devies.

apowers: conversation is do we have a good way of doing this
... do we kill this.

tony: this one gets to that point. lot to do to make it safe.

jbradley: being able to use CTAP to silently get credential, nothing to stop us from doing that ...
... noting stopping us in ctap or web authn for Oauth client authentication.

apowers: I think we can get a lot of use out of this

jcj_moz: my question, is why not do this in the forehground

jbradley: thye don't want to collect user consent

tom: they don't want a bad user experience

jcj_moz: the longest sessions we see are like New York Times.
... where is the ....how long can we run without user consent.

alexei: do we want to document the questions.

jcj_moz: is this a thing to discuss with web extensions working group.

tony: I would like to close this. if you want to open PR with clear solution to this problem..
... someone can do that.

tom: sounds like there is a plausible argument that is something web authn does not do.

tony: so suggestion is close and open if you have a plausible solution
... adam?

apowers: not excited about this

tony: what are we solving.

alexei: does this prevent us from doing this in the future.

tony: it says currently there is no proposed way to do this.

apowers: what is value prop of Level 2

tony: caBLE, making changes in CTAP, attestation.
... and more

agl: I think there are lots of bug fixes.

tom: if i think of level 2 as 1.1, is that a good mental model of the work being done

agl: that is what today is about
... I am not dissatisfied with Level 1

jbradley: would like to see Level 1 deployments...

apowers: lets educate people now, instead of blind siding that later.

jbradley: this could take two years to figure out, but if there are thing with impact in the short term, lets deal with those things - and then move to level 3

apowers, so silent authn goes to level 3

tom: that sounds reasonable.
... within that we establish a normative judgment what we think Level 2 ia about.

tony: so there is no time for a level 3 in the charter. so we would have to amend charter for level 3.
... we extended charter before

jeffH: we have done this before. We have a level 3 idea before we had new charter.

wseltzer: seem like a good thing to have things in a big bucket.
... we need understanding that it might not ever happen.

jcj_moz: I don't understand how to do this right now, but it would be cool to continue to kill cookies from the web.
... i just don't know how to get from here to there right now
... I have not had these discussion within mozilla
... should I go do that and think about getting rid of cookies.

agl: killing cookies is in the water for Google, but that is M. West's water
... he has at least three solutions.

apowers: can we send him an email

tony: maybe you have that conversation in web app sec. but not here.
... do it there.
... last topic of the day - discovering from device loss.

agl: we need it.

Recovering from Device Loss

agl: our charter limits scope to level 2, but this is bigger and needs to get done.

tony: do we go with charter revision now, or run out current charter. it will be a formal process.

agl: current charter is a nice deadline.

wseltzer: w3c says it likes groups to come bac kto AC review for long charger extensions.

tony: likely we would need AC review
... do we want to discuss device loss
... I hear motion for level 3
... level 2 is what we want to do. it is not just refinement
... if the group says things are needed then we will work on it.

nick: some direction in the spec would be good re: device loss

tom: seems refinement is next step in level 1. that is valuable clarification. do we push to L3 if it is more than a refinement. let's make a note of where we are

jbradley: the stage seems to be lets put together some proposals.
... we should keep it on the roadmap and see if we can get it donw.

nick: one of first questions we hear is what if I lose my device.

jbradley: now solution is register multiple authenticators

nick: that is something.

shane: it does not have to be authenticator, it is account recovoery.

jbradley: we are loking at something that speaks to account recovery, but pre-mature how it would fit in web auth or elsewhere

jeffH: leave this issue open and tag with...

jbradley: there is a proposal from google, there are others, we need to decide what we might do at CTAP or at Web authn

agl: we have consensus of a model that works.


tony: so right now this is not tagged t the right level or milsestone. thisis not a working draft 01 issue
... we cna move to level 2, draft 2 or level 3

tom: is there a reference we can use for upstream change that is something we don't know what to do with.
... if we are close to draft and don't have ??? we can move it to a level 3


tony: moving to level 3
... level 2 01 and level 2 02

alexei: can I open issues.

tony: yes.

Other/New issues

<wseltzer> https://github.com/w3c/webauthn/issues/1173



<inserted> scribenick: wseltzer

jcj: just opened 1173
... against my previous arguments, because some RPs wanted this
... it's transitory, but several years likely

sbweeden: is it capability support, not just CTAP2?

jcj: but this isn't exposing user info, but just about platform capability
... only version of browser and OS

sbweeden: driver is RP's desire to deliver good UX

Nadalin: do you want L2?

jcj: this is about to ship in FF

johnbradley: they likely want resident credentials

agl: at which point does this become true
... among feature support

johnbradley: helping RPs to guide users to a viable combo
... but as you add feature detection, fingerprinting

arnarb: we need to know use cases better

agl: understand your need to do this
... and still think we should close as wontfix

tomlowenthal: if the answer is purely determined by UA string, then doesn't add to fingerprint surface

jcj: firefox doesn't return build number
... so we preferred to add this string than adding windows build number to UA

Nadalin: close, no action

Alexei: we've done a bit of thinking re incognito, clearing cookies, and what that means for the spec
... User should have a clear expectation

agl: touch ID. If you clear your state in chrome, you wipe out platform touch ID
... but not on windows

Nadalin: you can call API to reset TPM, but not delete individual credentials

alexei: one conception of private browsing session: what you do there disappears at the end of the session
... but not the case for platform authenticators
... how should we help user understand

johnbradley: should private mode use different RPIDs so credentials don't mysteriously cross over

jcj: but different RPID goes back to RP, to know you're in private mode

tomlowenthal: plausible that user thinks of credential like download more than like browsing
... but potential of revealing credential from non-private mode in private mode would be unfortunate

agl: we wrestle with thse issues. a group consensus would be interesting

johnbradley: I think people will be surprised
... if there's no allow list, and pick list shows two logins

alexei: how do we not unpleasantly surprise users?

jeffh: incognito/private browsing doesn't appear in credman

tomlowenthal: private browsing isn't specified in web standards; it's a browser choice
... browsers can make different reasonable choices
... user surprisal is right benchmark, but it doesn't work in private browsing mode because users confidently misdescribe that all the time

Nadalin: since we inherit from CredMan, we should deal with this question there
... other issues?

selfissued: Move Angelo to former editor status


Nadalin: currently we have Draft 1 L2 set for April 15
... ideally, be done with L2 by TPAC, September 16-20 2019
... I'm going to put in for a WebAuthn session there, in Fukuoka Japan
... there's a FIDO seminar the following week
... so I'm going to request meeting Thursday or Friday
... Trying to set a pace for us to finish L2 by TPAC

Call timing

Nadalin: proposal to move the call 2 hours later

sbweeden: then I could make it

jcj: that's hard for Europe

Nadalin: we'll ask on the list
... polling to see if there are any objections in the room, and hearing none


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2019/03/08 00:57:30 $