Open Goosth opened 2 years ago
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'.
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.
See Related WebAuthn issue https://github.com/w3c/webauthn/issues/1667
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:
2) "SPC only". A credential:
3) "SPC and 1p Login". A credential:
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.
1) 1p only
2) SPC only
3) SPC and 1p Login
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.
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.
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...)
Proposal thread starts here: https://github.com/w3c/webauthn/issues/1667#issuecomment-957887836
Update from SPC task force discussion today: apparently "3p-nologin" is not considered an important use case. That should make life easier.
Below is an updated proposal for short and longer term management of Web Authentication credentials for use with SPC and login.
Goal:
Use cases:
Short term solution:
Longer term solution:
See also SPC sequence diagrams
Observations:
See related issue regarding user awareness of cross-origin bit: https://github.com/w3c/secure-payment-confirmation/issues/154
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:
(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 :). """
@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).
(Edited to include, thanks Ian)
Based on 5 May discussion, here is what we expect as next steps:
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.
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.
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
SPC has a number of very attractive powers. Two of those are
These attributes of SPC are established when the
PublicKeyCredential
is created, by adding apayment
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:Should we consider separating these two attributes?
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:
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.