Support Secure Payment Confirmation (SPC)

[emlun]

Discussed in #284

^{Originally posted by voirtimid May 18, 2023}
Hi guys,

I was playing around with FIDO authentication and wanted to try out Secure Payment Confirmation SPC (https://www.w3.org/TR/secure-payment-confirmation/) also. I'm using this library for the server part. Do you have any plans to extend the library with SPC specific features.

Thank you in advance.

Regards,

Oliver

[emlun]

We'll look into adding support for this in version 2.5.0, but I can't promise anything definitive just yet.

Perhaps we'll split this up and do the minimum soon and the rest later to give it more time to mature:

1. At minimum, the library needs to (conditionally) allow collectedClientData.type: "payment.get" in RelyingParty.finishAssertion(). This could be added fairly soon as an experimental feature. Then an RP that wants to use SPC could add the extension inputs
2. For completeness, the library should add the option to configure all of the extension inputs and any server-side steps specified in the SPC spec. This will need some more careful thought, but it doesn't seem like a lot of work.

So perhaps we might do (1) in the next release and (2) soon after. I can't say for certain now, but we're definitely putting this on the to do list.

[voirtimid]

Thank you for your quick answer and for putting SPC support into consideration.

I just want to share what I observed while testing SPC. As addition to what you wrote in point 1 above, I would like to add that the origin validation that is done in Step13 of FinishAssertionSteps should be skipped for SPC authentications (https://www.w3.org/TR/secure-payment-confirmation/#sctn-use-case-merchant-authentication).

Thanks,

Oliver

[emlun]

Minimal support for this is now implemented in PR #310. We aim to release this as an experimental feature in an early pre-release later this week, and refine SPC support later in the release cycle.

As of now the origin validation remains unchanged, but this does not stop downstream applications from "overriding" the default origin validation. Similar to the discussion in #289 (comment), the RelyingParty class can easily be re-instantiated per request with a new origins setting in order to customize the acceptable origins on a per-request basis. The RelyingParty class has no internal mutable state, so re-instantiating like this is perfectly safe. This is probably not the ideal end state, but it's enough for downstream applications to start experimenting with SPC support.

[emlun]

Minimal support is now available in experimental release 2.6.0-alpha1. Please note that experimental features may change or be deleted before reaching a mature release.

[voirtimid]

Hi Emil, thank you a lot.