Web Payments Working Group

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