- From: ianbjacobs <notifications@github.com>
- Date: Thu, 10 Feb 2022 14:11:51 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/675/1035582921@github.com>
Hi @plinss, I talked about this topic a bit in a blog post: https://www.w3.org/blog/wpwg/2021/10/06/spc-design-choices-for-flexibility-and-scale/ In short: * In practice we are likely to see a variety of solutions with different relying parties. * Solutions where the account provider is the relying party are likely to most closely approach "register once, reuse credentials easily everywhere." We certainly hope to support that model but it might require time for service providers to integrate SPC into their solutions. * In the Stripe and Adyen pilots, on the other hand, the PSP is the relying party. The user registers credentials with the PSP and the PSP uses SPC at transaction time. How the PSP then works with the account provider regarding risk assessment is outside the scope of SPC. EMVCo and FIDO have published, for example, a paper on leveraging FIDO authentication in a delegated model: https://fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-secure-using-fido-for-payment-authentication/ Thus: * In the "issuing bank is the relying party" model there should be one registration and lots of reuse. * In the "delegated to the PSP model" there should be one registration per PSP, and the PSP would communicate with account provider. I hope that helps, Ian -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/675#issuecomment-1035582921 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/675/1035582921@github.com>
Received on Thursday, 10 February 2022 22:12:04 UTC