Consider separating the SPC powers of Third Party invocation and Payment display

[Goosth]

SPC has a number of very attractive powers. Two of those are

• The ability to show a payment specific display in the browser agent
• The ability to invoke a payment from a cross-origin domain to allow one party to use another RP's Webauthn credential.

These attributes of SPC are established when the PublicKeyCredential is created, by adding a payment extension. Today these abilities are 'enabled' via a single payment flag, and are not independently settable. Both of these attributes may be however be desirable on their own. For example:

• An RP may want to use the better payment specific display option, but not at all want another party to invoke/use their credentials for payment.
• Another RP may not want the credential to be used for payments, but would be open to others using it for a Login (see it as a form of enabling Federated Authentication)

Should we consider separating these two attributes?

• On the one hand, an RP may just choose to not share their Webauthn credential ID's, thereby preventing the cross-origin functionality. From a least privilege perspective that may not be desirable (it's still technically possible if the credentials are leaked/shared inadvertently).
• There could be a view that this cross-origin should only be allowed for the payment use-case, so separating them would expose too wide a set of functionality (cross-origin login), which is not desirable.

The suggestion could perhaps be that a WebAuthn credential should be created with a Payment extension. And that in that payment extension it should indicate if cross-origin should be allowed. For example:

  extensions: {
    "payment": {
      allowCrossOrigin: true,
    }
  }

This would allow Payment display to be enabled, with cross-origin being an additional attribute that may be set if the RP is open to this use-case.

The alternative is to allow cross-origin for all use-cases, and have a cross-origin extension that can be enabled in addition to the payments extension.

  extensions: {
    "payment": {
      isPayment: true,
    },
    "crossorigin": {
      isCrossOrigin: true
    }
  }

[stephenmcgruer]

As a note, the current proposal being discussed on the WebAuthn side would not be compatible with this proposal, as it is very firmly linking the two in an 'spc' (or 'payments') namespace. That said, it's not set in stone (far from it) and so there's room to discuss, just a heads up.

I myself have been wondering if what should be behind the 'power bit' is not the payments powers at all, but maybe just the third party invocation. This would obviously need discussion with the WebAuthn WG, but why not let an RP in a 1p context just do SPC without any special bits needed*? (One thing I've not thought about - should it be allowed in a cross-origin iframe? Probably fine, given it'll need a user gesture?)

* Caveat; the credential would likely need to be Discoverable, to power the conditionally-shown transaction UX. But that's orthogonal from an 'SPC bit'.

[Goosth]

Thanks @stephenmcgruer.

The 3p powers is definitely the one that may cause the most concern for Relying parties. We've seen recently with 'Delegated Auth' that some Banks are not that keen to 'delegate' authentication to a third party (and their UX/flows). Now SPC this is a lot less risky, since the RP's credential is still used, but some RP's may have some reservations and first want to 'check things out', before enabling it. And we don't want that to cause the payment display piece not to be used.

The Payments piece provides a clear benefit to the end consumer with a better UX. Something that matches what they are doing (a payment). Given that the 'instrument' is provided during the transaction and the customer gets a better view of what's happening, I think most RP's that support payments will be interested in it. We would need to check what this means from a the 'least-privilege access' principle here with the security/privacy folks, to ensure everyone agrees with it, since it is enabling more than what is needed for a number of RP's (only a small percentage will allow payments.

So even in that parallel discussion, we need to be clear what the SPC means. Especially if we want to consider adding other 'use-cases' to the WebAuthn flow (e.g. Adding Payee's/Person to Person payments), and how we would extend those cases.

[ianbjacobs]

See Related WebAuthn issue https://github.com/w3c/webauthn/issues/1667

[ianbjacobs]

Based on various discussions including https://github.com/w3c/webauthn/issues/1667 I have heard three main use cases involving SPC and login:

1) "1p only". A credential:

• CAN be used by the RP for SPC, and
• CANNOT be used by 3p for SPC, and
• CAN be used for login to the RP in a 1p context.

2) "SPC only". A credential:

• CAN be used by the RP for SPC, and
• CAN be used by 3p for SPC, and
• CANNOT be used for login to the RP in a 1p context.

3) "SPC and 1p Login". A credential:

• CAN be used by the RP for SPC, and
• CAN be used by 3p for SPC, and
• CAN be used for login to the RP in a 1p context.

SPC Requirements

Browsers only show the transaction dialog conditionally, when a credential is available for authentication. We expect to rely on discoverable credentials and Conditional UI (or some underlying API) for this: https://github.com/w3c/webauthn/issues/1545

In the short term, the SPC implementation is caching available credentials. We would like to avoid this in the long term.

Short term solutions

1) 1p only

• RP creates a Web Authentication
• SPC implementations accept these as SPC Credentials when the caller is the same as the RP. This would require the browser to cache data about all Web Authentication credentials, and would not work for credentials created before a browser added this support.

2) SPC only

• RP creates a credential the "payment" extension (status quo) and keeps track of the resulting credential ID as being for payments.
• RP login server rejects login in a 1p context when presented with credentials intended (only) for payments.

3) SPC and 1p Login

• RP creates a credential with the "payment" extension (status quo)
• RP login server accepts login in a 1p context when presented with any credentials

Summary of changes to the SPC specification and implementation to accommodate all three use cases in the short term: accept vanilla Web Authentication credentials in a 1p context.

Longer term proposal

Create a Web Authentication "spc" extension that defines an "spc-uses" (or similar) optional member that is an enum with values that match the above use cases.

• 1p-only (usable by 1p with SPC and for 1p login)
• 3p-nologin (usable by 3p with SPC and not for 1p login)
• 3p-login (usable by 3p with SPC and for 1p login)

When the "spc-uses" member is not present, or if the extension is not supported, the credential falls back to being an ordinary Web Authentication credential.

Question: Would this require changes to CTAP and authenticators, or by virtue of being a Web Authentication extension it would "just work"? (I don't know anything about Web Authentication extensions...)

Regarding the Namespace Proposal

Proposal thread starts here: https://github.com/w3c/webauthn/issues/1667#issuecomment-957887836

• This proposal supports the "SPC only" use case but not the "SPC and 1p Login" use case.
• For the "SPC only" use case, it offers additional protection against accidental support for login.

[ianbjacobs]

Update from SPC task force discussion today: apparently "3p-nologin" is not considered an important use case. That should make life easier.

[ianbjacobs]

Below is an updated proposal for short and longer term management of Web Authentication credentials for use with SPC and login.

Goal:

• Reduce the total number of user registrations, taking into account both SPC and login use cases.

Use cases:

1. Enable a relying party to use a credential for both login (in a 1p context) and SPC (by the RP, or by other parties in a 3p context).
2. Enable a relying party to use a credential in a 1p context, for both login and SPC, while not allowing other parties to use it for SPC.
3. Enable a user to seamlessly reuse a credential across browser instances on the same device.

Short term solution:

• Capabilities:
  • Browser considers the following to be SPC Credentials: a. Vanilla Web Authentication credentials in a 1p context. b. Web Authentication credentials that were created with "payments" extension, when used in either a 1p or 3p context.
  • At creation time, the browser caches information about SPC Credentials for lookup at authentication time.
• Limitations:
  • Does not satisfy use case 3 (due to per-browser caching).
• RP notes:
  • For any use case where the RP wishes to distinguish SPC credentials from login credentials, the RP can use a subdomain as the rpid.
• Implementation notes:
  • The current Chrome implementation does not support capability (a). One implication in the short-term would be that the browser would have to cache information about all Web Authentication credentials, not just those created with the "payments" extension.
• Specification notes:
  • The SPC spec would need to enhance the SPC Credential definition for capability (a).

Longer term solution:

• Capabilities:
  • At credential creation time, authenticator sets a bit to indicate that the credential may be used cross-origin for SPC.
  • At authentication time in a 1p context: a1. Browser calls an API provided by the Authenticator, to silently confirm/deny if a given credential is present on that Authenticator (to remove need for browser-level caching).
  • At authentication time in a 3p context:
    a2. Browser calls an API provided by the Authenticator, to silently confirm/deny if a given cross-origin enabled credential is present on that Authenticator (to remove need for browser-level caching).
  • Specification notes:
    • The SPC spec would need to enhance the SPC Credential definition for the vanilla Web Authentication / 1p use case.
    • The SPC spec would remove the "payment" extension.
    • New Web Authentication extension definition for the "cross origin" bit. (There was some discussion of a "type" member that might also be useful in other cases beyond SPC; see issue 1637.)

See also SPC sequence diagrams

Observations:

• A "namespace" proposal has been discussed on WebAuthn issue 1667. A limitation of this proposal is that it might not be straightforward to address use case 1. Because the namespace proposal does not eliminate the need for enhanced authenticator capabilities, it seems preferable just to pursue the "cross origin bit" in authenticators to address all three use cases.

[ianbjacobs]

See related issue regarding user awareness of cross-origin bit: https://github.com/w3c/secure-payment-confirmation/issues/154

[stephenmcgruer]

The SPC task-force discussed this issue on Monday, and came to the conclusion that we should make our proposal clearer and attempt to drive towards a request for CTAP support. As such, I intend to post the following to WebAuthn issue 1667 tomorrow after the WPWG meeting:

""" Acknowledging that this issue has been long and contains many sub-discussions and proposals, I wanted to be clear on what we (WPWG) think are the next steps here.

At this point, we believe that we need authenticator-level support for the following two things:

1. At creation time, the ability to ask the authenticator to set a bit in the credential, indicating that the credential may be used cross-origin for SPC.
2. At authentication time, a mechanism to ask an authenticator (or to determine directly from a credential ID):
   1. If a credential is SPC-enabled
   2. If a credential is available on the authenticator, without user interaction with the device. (We believe this similar to that which is required for the WebAuthn Conditional UI Proposal.)

(Note that the above presumes that SPC in a 1p context will always be available, and that the bit will indicate that it is also allowed from a 3p context. As always, login will never be allowed from a 3p context.)

As we understand it, these require CTAP level changes, so our next step would be to send a proposal to the FIDO2TWG for these, within the next 2 weeks. Please feel free to give us any input before we move to do that :). """

[ianbjacobs]

@stephenmcgruer, for 2.ii, you link to SPC mention of conditional UX. It might also be useful in your post on 1667 to signal the relationship of this capability to conditional UX (for those who may not follow the link).

[stephenmcgruer]

(Edited to include, thanks Ian)

[ianbjacobs]

Based on 5 May discussion, here is what we expect as next steps:

• FIDO will discuss the CTAP modification for the 3p bit. (Underway!)
• We will discuss with platforms how to access that bit in platform-specific credential listing APIs.
• We will explore with Web Authn / FIDO2TWG how to access the bit in CTAP credential listing APIs.

I do note that at today's discussion, we began (but did not complete) to broach the connection between this topic and the non-modal UI discussions happening in WebAuthn.

[ianbjacobs]

Based on discussion today in the joint meeting at TPAC, it seems that the "third-party bit" has landed in CTAP and we can expect a forthcoming publication.

[ianbjacobs]

FIDO has made available a review draft of CTAP that includes a section that references SPC:

12.6. Third-Party Payment authentication (thirdPartyPayment) https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#sctn-thirdPartyPayment-extension