Supporting roaming authenticators

[jcjones]

When we create a new payment credential using your roaming credential, it's implied that the browser stores the credential displayName and icon so that when it's presented as an authentication option in the future, the browser can provide the user that useful bit of context that "this will use your Blue Authenticator to approve putting this purchase on your Yellow Card ending in 9999."

Moving the Blue Authenticator to another computer though and doing the same operation with the same account will prvoide a compatible credentialId that the browser can then use to approve this new purchase ... but there's no knowledge of what that credentialId would be approving for. E.g., the context would be, "This will use your Blue Authenticator to approve for an unknown payment type."

Browsers could sync that data around, but many people have many reasons to not sync, so this is a "normal" edge case. What should happen when a browser can't display useful context? Ignore that credential ID?

[danyao]

This is a great question! We are skirting it now by restricting this only to platform authenticators. 😅

In the long term, I think the best user experience would be for displayName and icon to be saved in the authenticator. I wonder if we can leverage WebAuthn extensions for this.

Another blocker before we can expand to roaming authenticators is for WebAuthn API to provide a mechanism to filter only authenticators that support 2-factor (e.g. USB authenticator with biometrics sensor). I believe all payment use cases would need 2-factor, and the transport option is not really meant to differentiate this capability.

[ianbjacobs]

I'm going to close this issue in favor of issue #92, which touches on the SPC design goal of removing the need for browser-stored information (for instruments, certainly, and ultimately for credential ids as well). Issue #92 resolution should also eventually help us accommodate roaming authenticators.

[samuelweiler]

I want to see roaming authenticators supported.

Just to make sure this is being tracked, I'm reopening this issue with @ianbjacobs' consent.

[stephenmcgruer]

From the SPC spec side, there are two concrete changes we would likely have to make to allow roaming authenticators:

1. Remove the check for authenticatorAttachment in the client extension processing steps.
2. Rework how we deal with the steps to determine if a credential is SPC-enabled and steps to silently determine if a credential is available for the current device to support remote authenticators.

(This presumes also that remote authenticators support (2), e.g. via some CTAP protocol change. Under discussion in WebAuthn currently.)

The tricky part is obviously step (2); we need a different approach where we would continuously poll for authenticator devices that support any of the passed in credentials. However this is somewhat at odds with the goal of SPC to have a conditionally-shown transaction UX (i.e., that is only shown if the user can definitely use SPC on this device).

One possible workaround we've considered internally is to have a 'fallback' experience for remote authenticators. This isn't the best experience, and I'm open to other ideas, but it would at least enable not-yet-available remote authenticators without hurting the 'happy path' of platform or immediately-available remote authenticators. A mock:

[stephenmcgruer]

We actually discussed this issue during the May remote meeting (minutes), but didn't transfer the results here. The gist was that we are monitoring possible upcoming changes in WebAuthn (e.g., OS-level caching of information from remote authenticators) that may help provide a smoother flow here, but which are still quite far out.

Given this, I propose that we mark this issue as after-v1 and revisit the above solution (or any improvements in WebAuthn if they have occurred) after that.

(For discussion in June 23 WPWG)

[Goosth]

Thanks Stephen,

Yes, I support this proposal.

From: Stephen McGruer @.> Sent: Wednesday, 22 June 2022 23:19 To: w3c/secure-payment-confirmation @.> Cc: Subscribed @.***> Subject: Re: [w3c/secure-payment-confirmation] Supporting roaming authenticators (#12)

We actually discussed this issue during the May remote meeting (minuteshttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2022%2F05%2F05-wpwg-minutes.html&data=05%7C01%7Cgoosthuizen%40entersekt.com%7Cf3d6bebb1e5d4aef3fab08da5494daa4%7C19c3aeac7d8a4c9e80b99f9510adc7f7%7C1%7C0%7C637915295546133408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oHvU4hm9NohPpKi9w1wgRZnUG7aD%2BzWdeuA4cXaqR5A%3D&reserved=0), but didn't transfer the results here. The gist was that we are monitoring possible upcoming changes in WebAuthn (e.g., OS-level caching of information from remote authenticators) that may help provide a smoother flow here, but which are still quite far out.

Given this, I propose that we mark this issue as after-v1 and revisit the above solution (or any improvements in WebAuthn if they have occurred) after that.

(For discussion in June 23 WPWG)

- Reply to this email directly, view it on GitHubhttps://github.com/w3c/secure-payment-confirmation/issues/12#issuecomment-1163609786, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARA57QEWQESQMPLQKQGGMRLVQN7M7ANCNFSM4PML7MYA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[ianbjacobs]

Discussed with WebAuthn WG today [1]. More discussion needed in WPWG, in conjunction with fallback UX discussions.

[1] https://www.w3.org/2023/05/03-webauthn-irc