SPC for non-payment use cases

[ianbjacobs]

In some payment systems (e.g., cards with 3-D Secure) merchants may with to authenticate the user in some non-payments use cases, including as part of storing a card-on-file or modifying stored information. SPC requires a total (which may be zero). How could user agents support non-payment transactions.

For example: When the total is 0, the user agent does not show the Total line. There might be a different string to display (e.g., "instrument stored" or "instrument modified") in place of the total.

My understanding is that there are some PSD2 requirements for which this capability would be useful.

cc @stare893

[stare893]

what @ianbjacobs described is a very common case. EMV 3DS already has built-in support for NPA (Non-payment Authentication) where the merchant would like to use 3DS rails for onboarding/account maintenance/ID&V etc and there will not be a payment amount to go with any of these. There is also a separate use-case of recurring payments where the payment amount will be present but the merchant would like to ensure user understands the amount will be varying.

[SensibleWood]

Regards PSD2 the most likely (non-payment) scenario is authenticating the End User for the purpose of granting access to account information for a Third-Party Provider (TPP).

In terms of how SPC might change for an invocation to support such a non-payment use cases:

• isPayment still remains true (although this may be a misnomer semantically in this case)
• total would be omitted.
• paymentInstrument would be omitted.
• payeeOrigin is tricky - semantically there is no "payee" is this case - the closest approximation would be the TPP receiving the data. Overloading this parameter with the TPP origin could be confusing for implementors and users.

All other attributes of the Assertion event can be dealt with via existing open banking APIs i.e. the data clusters the TPP is being granted to, the length of time the data will be available for, etc. Transmitting the Assertion would still fit the flows described in this document.

[ianbjacobs]

@SensibleWood, thank you for the analysis. If none of the transaction information is useful here, then this feels much closer to Web Authentication. Is it possible for the bank to initiate the authentication here in a 3p context? Or do you need the TPP (who, I assume, is not the relying party here) to authenticate the user and then share the assertion on backend rails?

[SensibleWood]

@ianbjacobs yes I agree that the Secure Payment Assertion has limited value given it doesn't convey much useful information over-and-above a regular Webauthn Authentication Assertion. Specializing the SPC API for account information has limited value right now as the consent-delivery mechanisms already exist elsewhere (although that might change in the future if consent ever need to be conveyed through a cryptographically-signed assertion).

Regards the authentication context it could happen in several ways - and these reflect flows that are already well-understood and do not differ much from the cards world (other than use of OAuth/OpenID Connect rather than 3D Secure):

• Bank authenticates through redirect (to web or app): User is redirected by TPP to bank and the bank invokes the Webauthn API as the RP. TPP follows the flow dictated by OAuth/OpenID Connect.
• Bank authenticates through iframe: Bank iframe embedded in the TPP site with cross-site enabled, bank invokes webauthn API as RP. TPP "might" need to do something funky as this has a poorer fit with OAuth/OpenID Connect.
• TPP authenticates, bank validates or verifies: In the style of SCA exception the TPP "could" be the RP, capture the Assertion then present the bank who could just "tick the box" (as in the delegated model for cards) or also verified the Assertion if the TPP chose to share the public key with them. TPP transmits through OAuth/OpenID Connect (the latter being possible out-of-the-box through login_hint), either using Core OpenID Connect or Client Initiated Backchannel Authentication.

So to answer the question: Depending on the model either the bank or the TPP can authenticate the End User. The Assertion can be carried over OAuth/OpenID Connect where it's the TPP doing so. For non-OpenID Connect markets there might be need to tailor their OAuth profile to incorporate the transmission of proofs-of-authentication.

[ianbjacobs]

Another use case I have heard: authenticating the user to get the candidate card list in a click-to-pay (SRC) flow.