Meeting minutes
Web Authentication WG
[Ian Jacobs WebAuthn issue slides]
SPC Issue 157
IJ: What is status of request to FIDO2TWG?
smcgruer_[EST]: Proposal has been made; we had an initial discussion on Tuesday (this week); they have assigned some reviewers.
John_Bradley: Will be a topic of conversation at FIDO plenary in 2 weeks
… after a first read of the proposal extension makes sense.
… will probably have to have discussions about what the response means.
… if a fido authenticator does not understand the bit you won't get it back in the response; that could be a useful signal
… what goes into the extension and how is it treated by the RP?
John_Bradley: Rather than have the platform management flags, I prefer the individual extension flag to allow authenticators to manage the storage.
Ian: Who is participating from WPWG in the FIDO meeting?
Christiaan: I'll be there and will work with Stephen
Ian: For WebAuthn, what has to happen and how do we get it done?
John_Bradley: WebAuthn just passes through the extension during create().
Ian: Is the extension defined in a W3C specification?
John_Bradley: It would more likely be CTAP
… since relies on changes to the protocol
smcgruer_[EST]: Agree that there are no "client processing steps" at creation time.
… but for WebAuthn folks, given that we want to expose this in a way similar to Conditional UI, is there a WebAuthn spec change for credential listing APIs?
ChristiaanBrand: We are talking about the client querying the credential store; this is outside of scope of WebAuthn itself IMO
John_Bradley: Because platform authenticators do some proprietary things, there is no defined API between browser and platform authenticator.
… closest we may have is Akshay API that will expose information from windows platform authenticator to browsers running on windows.
… but that's not in any specification.
smcgruer_[EST]: So I hear 2 work streams (1) working with platform authenticators (2) for remote authenticators, CTAP changes
John_Bradley: We have to figure out in CTAP a standardized way to say "this bit is exposed this way in credential management output"
… there are two ways the platform could get at the information, doing a get() with or without allow list and iterating through credential list, or using credential management API.
John_Bradley: Some of this is CTAP work and will require collaboration.
smcgruer_[EST]: We do have an extension in the SPC spec. At registration time, the client extension steps (1) enable cross-origin creation, which we'd like to move out of SPC (2) they do some enforcement on forcing discoverable credentials, etc.
… we might be able to remove client steps at registration
… but at authentication time, we put payment information in client data.
… we'll either need to move this into WebAuthn or keep it in SPC.
… are you ok with an extension defined in SPC?
John_Bradley: Probably most appropriate for WebAuthn.
… we should also consider whether the extension information is passed on through to the authenticator so that authenticators with displays can also display it.
… e.g., CABLE scenario, where the display of information can be displayed on different screens.
… there are reasons to prefer mobile device (e.g., less malware)
… so there's probably a good argument for passing data through to authenticators that can display it
[Brief side discussion on I18N here]
John_Bradley: Note that the authenticator would not be storing some information (due to space constraints)
smcgruer_[EST]: How should we resolve question of where information goes?
John_Bradley: We have to figure out what comes back in the extension (e.g., hash of what was displayed) that can be compared to collected client data.
smcgruer_[EST]: I think the payment industry needs it to be signed over.
John_Bradley: In the signed extension you'd get back a hash of what the display information was.
John_Bradley: We need to be sure that in the spec, if we are going with extension, that existing roaming authenticators without this extension would still be usable with SPC in a 1p context, assuming they support discoverable credentials.
… we should make sure that, in the short term, the population of existing roaming authenticators work in a 1p context.
John_Bradley: As long as we define the extension in the right way, it should make that easier.
John_Bradley: When WebAuthn client sees extension for special bit, then the client may take multiple paths to enumerate available credentials.
… so there's probably some platform processing things that we'd want to change.
John_Bradley: Some of that extension processing would happen only in the SPC context.
Things that have to be done:
* Define the extension
* Figure out the UI (and where that is specified)
Tony: We have to look at "is this useful for anything else for webAuthn?"
ChristiaanBrand: We should look at generic transaction signing again in WebAuthn
SPC Issue 154
John_Bradley: Anybody that implements a user dialog about opt-ing out. I think this should not be in WebAuthn. Could be done at the platform layer.
<smcgruer_[EST]> +1
John_Bradley: e.g., chrome could allow someone to allow setting the bit, and the RP would know because they would not get the extension back.
Tony: If we leave it up to the platform to do the dialog, it will be done differently everywhere, which will also be confusing.
John_Bradley: Saying you need to do a dialog has not created conformity across browsers to date.
John_Bradley: I'm against forcing browsers to have this dialog.
Tony: +1
John_Bradley: Extra dialogs will create drop-off. We may see banks, for example, causing users to create 2 credentials (one for 1p, one for 3p)
smcgruer_[EST]: I don't think from a user perspective that SPC is different here from WebAuthn in an iframe.
Tim: I agree with that point. This discussion reraises issue of naming RPIDs in dialog
SPC Issue 128
smcgruer_[EST]: There is an existing tracking concern around WebAuthn and tracking, where RP somehow registers user in a malicious context, and then later the malicious tracker activates web authn in a 3p context.
… our privacy folks said SPC lowers bar slightly during registration (in a cross-origin iframe).
… there are protections against this (e.g,. permissions policy)
… so our privacy folks asked for user activation
… so our plan is to fold this in.
Tony: This would affect WebAuthn (user activation)
smcgruer_[EST]: It only affects you if you are creating a payment-labeled credential. Longer term could be better in WebAuthn.
<SameerT> +1 to Stephen's point
smcgruer_[EST]: we would like to have the conversation about cross-origin registration in WebAuthn; payment industry partners would like that in order to use more WebAuthn
John_Bradley: Is this "user activation" for iframe only or all credentials?
smcgruer_[EST]: it's only for cross-origin create
John_Bradley: Cross-origin creation not allowed in WebAuthn; if we add it, then user activation is probably a good idea.
SPC Issue 12
John_Bradley: We heard from BPCE yesterday that they would want roaming authenticators.
Gerhard: Yes, the WPWG would love support for roaming authenticators in SPC. But for it to roam, we would need "no cacheing"
John_Bradley: Browser only needs to store information for credentials to be used in a 3p context.
… would work now without that bit in a 1p context.
smcgruer_[EST]: The important part of SPC is we only show the transaction dialog when there is a chance the user can succeed (a form of conditional UI, as it were).
… it means there's a matching credential nearby. This is trickier for roaming authenticators. Today we do it for platform authenticators via cached data.
… if we want to do it without the spc bit, we'd need to cache ALL FIDO credentials.
John_Bradley: The SPC bit is about "this credential can be used in a 3p context for SPC".
… I think banks will want to be able to use FIDO credentials with SPC in a 1p context.
Christiaan: I think this roaming authenticators for bank use cases is a great use case.
John_Bradley: The question is the SPC dialog ... to cause SPC to go look for another authenticator.
Ian: How is this managed today?
John_Bradley: Non-modal UI is not there yet but coming. I believe there will be an additional option for roaming authenticators.
… we did start a conversation on pairing a roaming authenticator with platform so that credentials could be pre-populated and cached.
… it's not really a problem if all discoverable credentials are displayed.
… if it's not appropriate for SPC, then the verifier should not be sending the credential ID
John_Bradley: We'd have to understand conditions under which this optional UX could be displayed.
… would need to indicate that someone wants to use an external authenticator.
… not sure that cacheing all the credentials from roaming authenticators is that big a problem.
smcgruer_[EST]: The cacheing idea is interesting, but might be better at platform level rather than browser level.
Tim: There's definitely a benefit to a link type function at OS level
Christiaan: Are we saying that the user's new (that is: not yet registered) roaming authenticators won't work?
John_Bradley: Maybe first time you plug in your key you are asked "do you want to use this for secure payments"
Tim: I think it would be like when you plug phone into computer and there's a pairing experience / dialog
Christiaan: I Think sounds reasonable to cache data
John_Bradley: We can do this now with credential management
Gerhard: We don't want to deviate in UX and other processes.
… if 3DS sends back 5 credentials (2 platform, 2 phone, 1 roaming)....I am hearing that Stephen wants to know that there are 2 that work
… Stephen is cacheing the first two
… until we are clear on WebAuthn way forward, we don't want to implement it in SPC
[Stephen shows a demo]
… you could plug in security key in dialog that tells user no credential found.
… so in this case, WebAuthn ceremony could be triggered first, and then only after the tx dialog would be shown; that's the inverse of how it works today (first tx then webauthn)
… if I've never registered, there is a UX issue.
… I like John's pre-cacheing idea but even without that there are some things we could do.
John_Bradley: If Non-modal UI is used to get the list of credentials; that can also be used to expose the credentials from roaming authenticators
SameerT: Does the RP know that a credential comes from a roaming authenticator?
John_Bradley: You get back a transport hint.
… so "USB" and "NFC" and "BLE" give you some information
Tony: Are you sure this is checked at certification?
John_Bradley: In certification processes they checked that it is provided; but they do not check that it is accurate
SameerT: If the RP knows that the device being used is a roaming authenticator, they may not send it if the UX will break.
SPC Issue 174
John_Bradley: Depends on timing; when extension codified.
… we should probably redefine the extension.
… the extension is "Device Public Key"
… please return me a flag so that I can tell whether the credential is being used on the same device or a new device.
… for security purposes a verifier can tell whether this is a new device.
Tim: The RP does NOT need to request the extension.
… the flag is set at creation time
John_Bradley: We should make sure that SPC causes platform discoverable credentials created on Android to emit the device public key extension
Tim: Suggest not hard coding the extension in SPC
John_Bradley: If we don't require it as "always being required" then we need to tell all merchants that they need to include it. Request is potentially coming from a 3p
… that's why making it mandatory in SPC would simplify some things
Tim: I do agree with that.
Tim: Are these banking folks ok with the change?
Jonathan_Blocksom: Here at Capital One, we'd send fact of new device to our risk engine; it would probably send a request for MFA at that point.
Tim: That's exactly how we imagine this being used. So I guess I am in favor of requiring it.
ACTION: Ian to work with all the chairs to schedule continued coordination time with WebAuthn
Best Buy experience with WebAuthn for Login
Joe: We've been looking at WebAuthn for frictionless login with good security
… there is an option to select WebAuthn to log into your profile
… there are a few hurdles we've seen
… first one is "what do we call this"?
… it's not easy to relay to customer what they will be doing.
Joe: We are also hearing from our devs that the technical documents can be confusing / in complete.
Tony: Do you think people understand what WebAuthn is? They understand "sign in with Google" etc.
Joe: I agree. That friction we are feeling is that consumers may not get it
… they are starting to communicate more closely to familiar phrases.
Tim: In the press today we are making an industry push to call this "Use a Passkey"
… we'd like to move away from platform specific branding
… we are pushing strongly for this.
<bdewater> https://
Tim: We think this is a good approach moving forward.
Joe: Where are we in our journey? Testing and learning.
… I appreciate the press release today describes things that will be helpful from a UX perspective.
[Joe shows a demo of how this works today on bestbuy.com]
[Joe lists benefits of using FIDO over passwords]
Joe: We see the value; key is to test and learn
smcgruer_[EST]: Small question on the demo - right at the start there is a best buy mobile UI
… did the user click a button to cause that modal to show up?
Joe: It pops up post registration
Ian: Anybody want to speak to documentation?
Gerhard: Regarding the device spread you've seen with this (between Mac, Windows, Android)...
Joe: Right now primarily on desktop (Chrome, Edge)
… for our in-app experience, I could see what information we are seeing in terms of adoption.
Dom: Thank you for the presentation. I am chair of the WebAuthn Adoption Community Group. You indicate that your team found gaps in documentation. Is that documentation on the API itself, or the overall user journey with WebAuthn?
… the CG would be keen to get feedback from your team on challenges encountered
Joe: The big piece was API documentation.
… the documentation was perceived as "confusing"
… they felt it was incomplete; they had to figure out how to connect the dots to make the final API call.
… I can ask internally for more specific.
Ian: Plans?
Joe: It's on and people are monitoring
… we are also getting feedback through surveys
… I think there is interest in using this an expanding where we can
John_Fontana: Are you using this in an enterprise context?
Joe: I don't think they are looking at this today
… I will check with technical teams on other interests.
User Recognition
[Ian Jacobs WebAuthn user recognition slides]
<smcgruer_[EST]> ... talked previously in this WG around changes in privacy in browsers
<smcgruer_[EST]> ... at TPAC people said user recognition important
<smcgruer_[EST]> ... two threads (1) fraud mitigation, (2) returning users for flows like SRC
<smcgruer_[EST]> ... Update: Anti-Fraud CG started meeting this year; so far approved charter and close to approving use-cases
<smcgruer_[EST]> ... some emerging proposals for the use-cases
<smcgruer_[EST]> ... Have invited them to the WPWG to share updates
<smcgruer_[EST]> ... On the returning user flow; some use-cases have come up - SRC (remember SRC identity), Open Banking (remember preferred bank), ...
<smcgruer_[EST]> ... There are some approaches without 3p cookies with UX: pop-up, Storage Access API, WebAuthn+Conditional UI
<smcgruer_[EST]> ... For conditional UI, strongly attached to autofill in Chrome currently, but we may be interested in other experiences that aren't autofill-based. For later discussion with WebAuthn WG
<smcgruer_[EST]> ... Other technologies that don't seem applicable: Trust Tokens, isLoggedIn - they both lack user info
<smcgruer_[EST]> ... The First Party Sets proposal may be useful for use-cases like SRC, where there are multiple networks
<smcgruer_[EST]> ... to wrap-up - want to look at Conditional UI for SRC
<smcgruer_[EST]> ... plus - what are we missing in general?
smcgruer_[EST]: There's a slightly broader scope for user recognition than you speak to: there are also use cases where PSPs have experiences they want to provide across merchants.
… suppose I have "Stephen's Shop" that is build on Shopify. Shopify may also want to recognize users across shops they support, for other use cases.
… I think there are more use cases than Ian covered.
Next meeting
26 May