webauthn
webauthn copied to clipboard
w3c
Cross origin authentication without iframes (accommodating SPC in WebAuthn)
On WebAuthn WG call on 2021-08-25, a proposal concerning secure payment confirmation (SPC) was discussed which probably originated from web payments groups. Attaching for more details: [WebAuthn WG August 2021] Secure Payment Confirmation.pdf
In above proposal, a mini proposal is to open up authentication to cross origin without iframes. Opening up this issue to hopefully have the concentrated conversation around cross origin authentication without iframes and want to talk about security, privacy and user experience and potential misuse.
So at the moment, we don't allow authentication outside of origin in webauthn. We allowed it in iframes in L2, but don't allow it for any other website to be able to invoke .get() call credentials without iframes.
Recently, we discussed to open up .create() call inside iframes. Till this point RP is in control. If it chooses to, like all of non-payment scenarios, it can choose to not enable these calls in iframes. And if they do, they know who the parent is so that they can potentially filter out origins that they trust.
I see three kind of RPs with different levels of control.
- RP who never wants to do .create() or .get() calls outside of their origin. Current webauthn spec protections allow that which really helps in phishing resistant property of WebAuthn.
- Most RPs live in this space
- RP who is OK with iframes but only want to do in iframes because they are still in control of who can invoke webauthn ceremonies.
- RP who wants .create() and .get() calls outside of origin. Like merchants, who wants to do on-behalf of banks.
- The above Web Payments proposal is not proposing .create() call outside of iframes at the moment. But I heard @christiaanbrand saying that he wants to do that in future.
The most concern I have is around the third category of RPs/Scenarios which will negatively impact Category 1 and also category 2.
IIUC, the proposal is to only allow credentials who are marked as SCP compliant to be opened up for now for authentication in cross origin case.
- I don't understand, how these credentials will be marked as such and be temper proof by the calling website. I think the proposal is that merchant will have all the credentialIDs and will invoke it .get() call with a new field set which says that this credential is marked as SCP compliant.
- What is the cryptographic proof that says that this credential is created with SCP in mind? How will browser determine that one credential is allowed vs another credential is not allowed.
If we cannot determine this without tampering, then we have privacy issues. A phishing website will get the credentialID and invoke it in their origin, user will be prompted with the dialog, which most likely they don't much read, and user approves and website knows that user has credential for a website which they have no right to enquire.
In above context, let's get one thing out of the way. CredentialIDs are public and that's why we don't store PII information in that. In webauthn designs, we allow with username flows, where given a username, credentialIDs being returned for passwordless authentication silently. Ofcourse, RP can add fake one, but they need to also provide the real ones. Even outside webauthn, credentialIDs are kind of treated as semi public info. And till now this was not an issue because no other origin can really use them. So credentialIDs will be known to many parties.
Another point I heard was around it is only applicable for non-discoverable credentials. I don't understand why. I can understand that this design only works if used in allowlist context, which can be satisfied by both non-discoverable as well discoverable credentials. And restricing it to only with allowlist, I am not sure what we are getting. As mentioned above, credential IDs are not really protected in any full secure way by the RPs.
Third argument I heard that any websites ability to popup authentication, even if we restrict it SCP credentials only is only a nuisance. I argue that it is a privacy issue and a possibly a phishing vector. It gives ability for a random RP to almost know for certainty that a credential exist for a website. And that is why, the second category above which says, I have cases around cross-origin authentication, but I only want it to be inside an iframe. And that should be RP's choice. Even if this is nuisance, it seriously hampers the webauthn brand.
Till now, I am only thinking from RP's persctive. I haven't thought through, where the user choice in all of this.
Overall, it seems that this is dangerous and in pursuit of solving one desire to not have iframes (which I don't disagree with per say, but just recently we rejected other legitimate use cases around raw signatures), we are messing up with core fundamentals too much here. Ofcourse, I don't have the full design and I may be wrong here.
@agl @christiaanbrand @equalsJeffH @ve7jtb for above questions and clarifications if I misunderstood things.
SPC builds on a model that requires untrusted third-parties (merchants) dealing with credentialId and card data in clear. State-of-the-art systems like Apple Pay need none of that. In practice the SPC API requires outsourcing to trusted service providers to be invoked which is an unusual feature for Web APIs.
https://github.com/cyberphone/doc/blob/gh-pages/payments/review-secure-payment-confirmation.md#technical-issues
@cyberphone , Although your comments are related, I want this issue to be focused on implications of opening up the webauthn API in cross-origin without iframe context to existing RPs who have nothing to do with payment scenarios. I would prefer not discussing merits of SPC with other models on this issue.
For example, if I am an RP who does not care about payments at all, how do I prevent any random website from starting a webauthn operation on my behalf.
It is more than just a nuisance for such RP. It is also about webauthn brand. Today an RP can say that no other website can invoke such an operation. And I would like that property to remain if we allow such proposal. If that conversation changes to we don't know who can invoke us and RP has no control, that is a problem. Even if server rejects such a response, it hurts the webauthn brand IMO.
@akshayku If I understood this correctly, the idea is that this feature would indeed only apply to keys that were explicitly created for SPC, "payment keys".
Probably, but I don't understand how browser will determine that. If that results in authenticator deciding it, then that webauthn system pop still comes up probably resulting in "No such credentials found". Which no other origin has ability to do today. And that is a UI problem.
@akshayku The process is approximately like this:
- The User in some unspecified way provides a payment instrument (card number)
- The Merchant uses that to lookup Issuer and its FIDO server
- Using the card number the Merchant invokes the FIDO server
- If there is an authenticator associated with the card number, SPC can be invoked, otherwise it the Merchant code must do something else
The "black box" concept used by Apple Pay et al, would if applied to FIDO not require a single change in the WebAuthn access model.
This is how the Web Payment folks describe the process above: https://lists.w3.org/Archives/Public/public-webauthn/2021Aug/att-0129/_WebAuthn_WG_August_2021__Secure_Payment_Confirmation.pdf#page=13 In the real world the credential discovery process is much more complex and practically always require outsourcing to scale.
I'll let Stephen respond to Akshay's question. But, before that, two notes/questions:
-
Today, WebAuthn can be used (at least for Get operations) in iFrames. And, as far as I know, up until this point, we were fine with it. There's nothing an RP can do to prevent (and I also don't think they need to be able to do that). It has no impact on either security or privacy from my perspective. Any disagreements on that?
-
Anders, though you're correct in saying that untrusted merchants will get to deal with credentialIds, I don't think that's a problem for the security of our implementation. Like public keys, they're not supposed to be secret, although there is an argument here about linkability (privacy), since we're already dealing with card numbers I think that's okay? In other words, SPC's security model does not depend on the integrity of untrusted merchants.
Today, WebAuthn can be used (at least for Get operations) in iFrames. And, as far as I know, up until this point, we were fine with it. There's nothing an RP can do to prevent (and I also don't think they need to be able to do that). It has no impact on either security or privacy from my perspective. Any disagreements on that?
No disagreements on this, but I think we can improve it to be more granular between allowing it to be iFrames vs no iFrames which browser can do for every RP, instead of RP having to do it. With this third class of RPs who are OK with SPC, I have some design in mind, but want to confirm first the above questions.
Usability is something I am concerned about and I want current property of no-one else being able to ask for my credentials to remain.
That property of only allowing RPs to decide what they want is something I want to explore technically.
Hi Akshay,
You're asking an important question here, so thank you and I apologize for not covering this explicitly in my presentation. We definitely have to make sure that RPs opt-in here and that that is supported at the technical level.
which probably originated from web payments groups
For the record, there is no probably. Secure Payment Confirmation has been developed entirely within the W3C Web Payments Working Group from its inception >1 year ago to today.
[...] I don't understand how browser will determine [whether a credential is SPC-enabled].
The unappealing answer for today is: we currently store a browser-local list of credentials created in that browser with SPC permission, and require at auth-time that a credential matches the list. This has many issues of course, and so is not the long-term plan.
The longer-term plan should be authenticator-based, I think - perhaps a platform authenticator API in the intermediate future, or a CTAP bit in the longer-term to enable all authenticators. Or there may be a superior solution that the WebAuthn WG are better able to come up with (as my FIDO-level knowledge falls short!).
If that results in authenticator deciding it, then that webauthn system pop still comes up probably resulting in "No such credentials found". Which no other origin has ability to do today. And that is a UI problem.
My hope is that the same APIs required for Conditional UI will enable SPC without a platform 'No such credentials' prompt. The question one is trying to answer from the browser code is "Do any of these credentials exist on this device and are enabled for SPC". The first half is close to Conditional UI, the second half is new.
This long term plan would require Discoverable Credentials, and that is why I believe SPC should require them too.
I don't quite understand why there should be an exception (alternative approach) for SPC credentials. I'm happy to hear the argument for this, but from a purist POV, what really makes them special that they deserve to be treated differently from credentials used for other authentication scenarios?
I would hope that whatever model is arrived at it would be suitable and relevant for all WebAuthn credentials and as much as possible all use cases, and that such an exception doesn't just exist to placate those opposed to changing the current model.
@sbweeden The biggest change required by SPC is liberating keys domain wise: https://w3c.github.io/secure-payment-confirmation/#sctn-payment-extension-registration That is, a payer must be able to exercise his/her payments keys with any merchant.
There are two other alternatives which do not require any updates of WebAuthn:
- Redirect payment requests to the RP. This was one of the things the SPC folks (understandably) wanted to avoid.
- Run the entire user authorization process inside of SPC in the same way as Apple Pay does. This option has never been discussed but is IMO a much better idea than building on a severely dated "Card NOT Present" architecture requiring 500 pages of documentation, certified merchant server software, and merchants becoming a part of a specific PKI in order to access bank related security services.
(to be completely fair, registration would indeed need additional meta data like account Ids and logotypes to work, but the WebAuthn security model remains intact)
The unappealing answer for today is: we currently store a browser-local list of credentials created in that browser with SPC permission, and require at auth-time that a credential matches the list. This has many issues of course, and so is not the long-term plan.
This is not a good design. This does not work cross-browser.
The longer-term plan should be authenticator-based, I think - perhaps a platform authenticator API in the intermediate future, or a CTAP bit in the longer-term to enable all authenticators. Or there may be a superior solution that the WebAuthn WG are better able to come up with (as my FIDO-level knowledge falls short!).
Probably. But not sure we need anything else than what we already have. If we are having a clause of only SPC credentials work here, then we are leaving behind lot of external authenticators currently in the market. Which probably we don't need to. I would like to understand whether we have a need for separating out normal credentials vs SPC credentials. And if there is a need, can that be satisfied with having two subdomains like login.RP.com and payments.RP.com?
My hope is that the same APIs required for Conditional UI will enable SPC without a platform 'No such credentials' prompt. The question one is trying to answer from the browser code is "Do any of these credentials exist on this device and are enabled for SPC". The first half is close to Conditional UI, the second half is new.
@sbweeden has a point. Why only restrict to SPC type of credentials? Why not everything?
The other thing here is "on this device" clause. We believe that user should be able to use external authenticators if they choose to. And we don't want SPC to be restricted only to platform authenticators. And for external authenticators, there cannot exist an API which says tell me the credentials when that device is not even plugged in at that moment. Hence the UI prompt occurs to guide the user first and that is a big problem in all of this.
In your current design, RP is not in control. Credential IDs are public and anyone who has Credential IDs can ask for authentication if we allow cross-origin authentication. Big problem is that pop up which removes the behavior currently which says that only RP control authentication request ceremony and no one else can even start the operation. Even if browser adds this information and RP can check on the server in the response, it is big problem for the WebAuthn brand and we don't want anyone else to ask for WebAuthn authentication on our behalf. That would be one of my requirement that RP must be in control of whether anyone else can ask for WebAuthn operation to even start the browser WebAuthn operation. RP must be be able to decide what behavior they want and what scenarios they want to support.
The solution I am thinking of is along the following lines.
- RP declares the security/usability/scenarios supported for WebAuthn credentials at their origin
- May be RP has a .well-known URL/file which browser will check if accessed from another origin that is not the top level origin. I think we did something similar for U2F in terms of appid?
- Two permissions. RP can specify multiple permissions.
- Allow WebAuthn in iframes
- Allow WebAuthn in cross-origin
- Browser checks for above permissions when WebAuthn is not done in RP's origin.
This long term plan would require Discoverable Credentials, and that is why I believe SPC should require them too.
I wonder whether you choose non-discoverable because that what Android supports today or there is some other reason? For comparison, Windows only support discoverable credentials and not planning to support non-discoverable credentials. And I would like to Windows Hello and external authenticators to also be able to satisfy the SPC requirements because user verification is what should matter to the RPs. Whether those credentials are in allow list or not, should not matter IMO.
@akshayku @sbweeden There may be a terminology issue buried here.
"Cross-origin" for authentication usually means that you have something that can be used for authentication to multiple and potentially independent RPs like an X.509 certificate.
"Cross-origin" for SPC however, is not about multiple RPs, but to permit arbitrary domains launching authorization/authentication requests to the RP that once created the key in question.
These use cases do not appear to have much in common.
RP declares the security/usability/scenarios supported for WebAuthn credentials at their origin
May be RP has a .well-known URL/file which browser will check if accessed from another origin that is not the top level origin. I think we did something similar for U2F in terms of appid?
Two permissions. RP can specify multiple permissions.
- Allow WebAuthn in iframes
- Allow WebAuthn in cross-origin
Browser checks for above permissions when WebAuthn is not done in RP's origin.
I've been thinking about something along these lines too. This could also enable a lot more, here are some ideas:
The .well-known resource could specify an allow-list of which domains may use WebAuthn cross-origin. Although I've understood that payment providers may want to allow any merchant, so maybe a dynamic solution similar to the Access-Control-Allow-Origin header would be preferred.
If the .well-known resource is dynamic, it could also return a list of allowed credential IDs for the operation. That could remove the need for an SPC bit stored on the authenticator, preserving backwards compatibility with existing authenticators.
Taking that one step further, the .well-known resource could return all the request parameters, taking even more complexity off the merchant. The merchant might not even need to see the user's credential IDs at all (though the response would still be returned to the merchant, so the merchant would see that credID and user handle unless we obfuscate that too somehow).
As a rough but concrete example incorporating all of the above, say the flow could go something like this:
- Merchant somehow asks user for some user ID and for which bank it is. Maybe a credit card number, or a user ID and domain stored in a browser wallet, etc.
- Merchant calls
bank.com/.well-known/webauthn/spc-beginwith body{"user_id": "<user ID>", "tx_info": { <requested transaction amount, recipient, currency, etc> }- Note that we assume nothing about
tx_infohere - its format could be unique per bank, so this could probably be generalized to non-payment applications too.
- Note that we assume nothing about
- Bank initiates SPC ceremony and returns opaque token
z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8=referencing this ceremony state - Merchant calls
navigator.credentials.get({ spc: { rpId: "bank.com", token: "z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8=" } }) - Browser calls
bank.com/.well-known/webauthn/spc-getwith headerX-SPC-Request-Id: z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8= - Bank returns a
PublicKeyCredentialRequestOptionsstructure (would need us to define encoding for byte arrays) - Browser proceeds as if this
PublicKeyCredentialRequestOptionshad been passed aspublicKeyin a normalnavigator.credentials.get()call - Merchant receives
PublicKeyCredentialresult, sends this back to bank somehow, bank confirms transaction somehow
I'm sure there are lots of problems and incompatibilities here, as I know very little of how payment systems work. One clear drawback is that this would require a whole protocol on its own for the browser<->bank communications, with all the inertia that entails. But has something along these lines been considered?
Dirk and I talked about something like what @emlun is proposing a couple of years ago for permission based cross-origin authentication requests.
One issue was the merchants didn't want the browsers making a call to the bank for each request for performance reasons.
One thing we considered was the RP publishing a JWKS at a .well-known. That would contain a public key that the bank would use to sign delegation authorizations.
The merchant would send the card number to the bank and get back a list of RPID and a time-limited dedication authorization that would go to the browser allowing the RP to treat the RP as a proxy for the specified RPID.
The browser would need to cache the public key but that could be relatively long lived and used across multiple merchants.
The browser would check that the deligation ticket in the request is valid before allowing the RP to specify a third party RPID.
If we wanted to not keep a cross domain flag in the authenticator for the credential then we could probably do that if the allow list was part of the signed object. That would prevent the merchant from making a request with credentials in an allow list that the RP doesn't intend for cross domain.
I think it would solve Akshays problem with only allowing specific proxies.
I don't quite get why the requirement for discoverable credentials. While this should work for discoverable credentials when an allow list is provided, I don't see any reason that a discoverable credential is required.
If we decide to store a flag for the credential that could be stored in the credentialID allowing non discoverable credentials to work as well.
So I mostly agree with @emlun but think the browser should just be getting a key in the .well-known so it can be cached and be replicated via CDN.
@emlun wrote:
I'm sure there are lots of problems and incompatibilities here, as I know very little of how payment systems work. One clear drawback is that this would require a whole protocol on its own for the browser<->bank communications, with all the inertia that entails. But has something along these lines been considered?
The only thing that has been considered is adopting the Google/Stripe pilot as the foundation for a thing that now are just days from becoming a public draft. SPC is effectively W3C's last chance in a very long time creating a useful Web based addition to the payment landscape. My analysis (FWIW) indicates that SPC will not prevail: https://github.com/cyberphone/doc/blob/gh-pages/payments/review-secure-payment-confirmation.md#external-review-googlew3c-secure-payment-confirmation-spc
That SPC does not (unlike just about every other payment method in existence), present itself as a branded icon in checkout pages reveals a limited understanding of commercial and marketing realities. The conveners are probably counting on that Stripe and their likes will market SPC but they won't. SPC is just a feature in a long list of methods supported by proprietary "checkout APIs".
IMO any alternative work should start by asking the question: What problems do the existing on-line payments methods suffer from and is there something we could do about this? If that question only returns increased security and/or marginally better UX, there is nothing to do because that's not enough to move this very slow market. Put in other words: a useful solution must also function as an "enabler" for new functionality that should be attractive for consumers, merchants, and banks. Since none of these parties are active in public standardization efforts this comes with certain challenges 😎
@stephenmcgruer @christiaanbrand
@emlun Wrote:
- Merchant somehow asks user for some user ID and for which bank it is. Maybe a credit card number, or a user ID and domain stored in a browser wallet, etc.
This is where the troubles begin. Merchants asking for something related to the user versus having that in a browser wallet is a watershed issue because the latter does in a proper design (e.g. Apple Pay), eliminate the need sharing PII like user Ids or card numbers with untrusted third parties (e.g. merchants).
Apologies for the delay here folks, I got wrapped up with other happenings this week. Starting with Akshay's latest comment:
This is not a good design. This does not work cross-browser.
We are in agreement! It's a hack, to speak plainly, which suffices to let us see if the general concept of SPC (trustable user authentication initiated by merchants) is attractive to the payments industry.
I would like to understand whether we have a need for separating out normal credentials vs SPC credentials. [...] @sbweeden has a point. Why only restrict to SPC type of credentials? Why not everything?
One thing to make clear, from my perspective - the term 'SPC credential' exists only to differentiate the ability to utilize the credential in a third-party initiated authentication. I do not expect a long-term solution in WebAuthn to even refer to SPC - the concept might be called 'third-party enabled credentials' or something like that (I'm bad at naming!). SPC then becomes a spec that relies on such 'third-party enabled credentials'.
We believe that user should be able to use external authenticators if they choose to. And we don't want SPC to be restricted only to platform authenticators. And for external authenticators, there cannot exist an API which says tell me the credentials when that device is not even plugged in at that moment. Hence the UI prompt occurs to guide the user first and that is a big problem in all of this.
I think this might still be compatible with SPC. To maintain authentication ceremony privacy, SPC has to show a user dialogue whether or not the passed credentials match the device. In the match case, it's a transaction dialog (followed by WebAuthn if the user agrees to verify the transaction). In the non-match case, it's a form of error dialogue that we try to make payment-specific. It seems like the latter could additionally allow for the user to plug an external authenticator in at that moment, and it would 'retry' the matching logic?
In your current design, RP is not in control. [...]. RP must be be able to decide what behavior they want and what scenarios they want to support.
As discussed in the call; I (and I think at least @christiaanbrand will agree with me) am asserting that the RP does have control, in that this behavior is opt-in when they create the credential. I agree they don't have absolute control, but as per below I don't think that's desirable for the payments case.
The solution I am thinking of is along the following lines. [...]
The issue with this solution, as with @emlun 's, is what @ve7jtb points out below - it puts the bank back in the middle of the payment transaction. This re-introduces the performance and reliability issues we were trying to get away from (though I will cede that it does still keep the user-confusion issue out of it as the user never sees this).
Moreso, this solution, as with @emlun 's and @ve7jtb 's do not integrate with or build on top of existing widely-used payment protocols that banks are familiar with and which they trust. SPC's current model should (I believe) work with any payment protocol where the merchant and the bank talk on some form of backend protocol - which is most of them.
I wonder whether you choose non-discoverable because that what Android supports today or there is some other reason? For comparison, Windows only support discoverable credentials and not planning to support non-discoverable credentials. And I would like to Windows Hello and external authenticators to also be able to satisfy the SPC requirements because user verification is what should matter to the RPs. Whether those credentials are in allow list or not, should not matter IMO.
I think you perhaps misread: we choose Discoverable, not non-Discoverable. That's actually why SPC cannot launch currently on Android, because I think that Discoverable Credentials are required for it's long-term success. (I could be wrong!).
(Although perhaps we are just using different definitions here... you're correct that currently SPC requires the merchant to pass in the list of credentials, which is very 'non-Discoverable' like. The reason was that in our opinion from the website's perspective credentials should only be Discoverable for the RP, not for a third-party.)
I don't quite get why the requirement for discoverable credentials. While this should work for discoverable credentials when an allow list is provided, I don't see any reason that a discoverable credential is required.
The reason I've pushed for Discoverable Credentials isn't related to the third-party initiated authentication ceremony. It is related to SPC's ability to only show the browser transaction UX if the credentials match this device (i.e. if there's a chance the user could succeed, assuming they wish to and that they can pass the WebAuthn ceremony). This seems very close to Conditional UI (which is in some ways solving the same question... roughly), and Conditional UI requires Discoverable Credentials.
If we can find a way of doing that without requiring Discoverable Credentials, SGTM!
@stephenmcgruer wrote:
SPC's current model should (I believe) work with any payment protocol where the merchant and the bank talk on some form of backend protocol - which is most of them.
This is not entirely correct, in most cases there is a third party in the middle.
For EMV which is the most widely used payment authorization system there is no direct communication between the merchant and the customer's bank; it is a pure store-and-forward system depending on trusted intermediaries for the communication with banks (which BTW often is bank specific).
3DS (and SPC) introduces a new requirement: retrieving the URL to the bank's (ACS) Access Control Server using the card number as key. According to the 3DS specification this operation requires certified merchant software and an X.509 certificate for authentication which is why 3DS more or less presume outsourced operation. That is, merchants will in general not be able invoking SPC themselves.
How does this relate to this issue you may [rightfully] wonder? Well, by rather building on EMV you get away from just about all privacy, UI, credential discovery, scalability, logotype integrity, and certification issues mentioned here and in the SPC draft. An EMV variant would preferably not be built on top of the WebAuthn API, it would rather use CTAP2 and funnel hashed transaction requests through clientDataHash (and thus eliminating clientDataJSON). Backing authenticators would still be 100% compatible with WebAuthn in case RPs would like to use them for login as well.
I'm happy that the wallet concept completely does away with this issue as well as issues like:
- https://github.com/w3c/secure-payment-confirmation/issues/101
- https://github.com/w3c/secure-payment-confirmation/issues/124
- https://github.com/w3c/secure-payment-confirmation/issues/109
@cyberphone what you are proposing is not impossible as an eventual end-goal: a Web Payments API that involves payment specific interactions with secure hardware (as opposed to going via generic WebAuthn).
However, as I think you know, the scope of such an undertaking is HUGE.
The goal of SPC, as @stephenmcgruer alludes to above, is to figure out if the market is even interested in merchant initiated payment authN. Hence, the current design has some hacks but it will get us on a road to more experiments and iterations and ultimately a solution that the market will actually use.
SPC is not a payment method, your comments about branding and icons suggest you are either missing the point or refuse to listen (I've pointed this out to you before). SPC is an authN mechanism that can be used by ANY payment method. To leverage SPC a payment method must define a way for the merchant to discover the credential IDs it can use for a particular transaction. In a card transaction using 3DS, this is defined in the 3DS spec, other payment methods will define other ways for this to work. That's not in scope for SPC.
Please stay on topic in this thread so we can focus on the issue of cross-origin auth.
@stephenmcgruer - maybe I am being stupid but I can't think of a use case that is impossible if SPC simply required merchants to embed an RP iframe.
I presume the issue with this is not the technical limitations?
@stephenmcgruer - maybe I am being stupid but I can't think of a use case that is impossible if SPC simply required merchants to embed an RP iframe.
I presume the issue with this is not the technical limitations?
Looking only at 3DS*, I would generally agree with that statement.
As per the presentation I gave in the WebAuthn WG two weeks ago, the main reasons are reducing friction, avoiding merchants having to embed resources from arbitrary banks, and the aforementioned reliability of issuer web-services. Stripe had a great writeup on this a long time ago, and I would welcome input from @jcemer if they wish to add more explanations, reasons, and/or data :).
- Outside of 3DS my payment method knowledge is much poorer; I cannot think of any existing flows that would require this, but they may exist and I would look to the Web Payments WG to help us figure that out.
@adrianhopebailie https://github.com/w3ctag/design-reviews/issues/544#issuecomment-915822393
I deleted @cyberphone's comment. This is not part of our agenda and was never more than a comment and therefore there is no need for noise about it on this thread.
I've discussed a bit with @ve7jtb and we have a proposal for how the "SPC bit" could be stored for external authenticators: essentially, we could "namespace" the RP ID.
Specifically: when a merchant initiates SPC registration for RP ID acmebank.com, the browser calls authenticatorMakeCredential and sets the RP ID to spc://acmebank.com and clientDataJSON.action: "payment.create". Similarly, for SPC authentication the browser calls authenticatorGetAssertion with RP ID spc://acmebank.com and clientdataJson.action: "payment.get". The precise format and naming of the namespace/prefix is of course up for discussion (maybe payment:// to mirror action?), but that's the idea. Platform authenticators can store the "SPC bit" however they like without affecting the API.
Some implications of this approach (not always obvious if they are advantages or disadvantages):
- Backwards compatible all the way back to U2F security keys
- Works with resident credentials on existing FIDO2 security keys
- The RP remains in control of which credentials have the SPC capability
- Credentials must be created with the SPC capability explicitly enabled; it is impossible for existing credentials to be opted in accidentally
- SPC credentials will be exclusively for SPC and cannot also be used for login
Although, (3), (4) and (5) don't have to be true for platform authenticators - those certainly could manage both the "SPC bit" and SPC access dynamically if they so wish.
This wouldn't solve the issue of allowing access to the SPC API in the first place (preventing rogue UI prompts), though.
Thoughts on that?
I like this pattern. It would also allow for future use of WebAuthn credentials for ephemeral session binding across devices (cross-device wallet use cases).
update 19-Nov-2021: Ignore this post -- I'd (obviously) forgotten about OpenSSH's existing use of the ssh: namespace in RP IDs as akshayku and ve7jtb point out below.
WRT @emlun and @ve7jtb's above proposal, while I'm sympathetic with the goal of finding a clean way to denote webauthn/fido creds as being "enabled"/"authorized" for use in payments contexts, the primary issue I see with this particular approach is that the RP ID is defined as a valid domain string, not a URL (or serialized origin). Setting them to the latter may be problematic.
the primary issue I see with this particular approach is that the RP ID is defined as a valid domain string, not a URL (or serialized origin). Setting them to the latter may be problematic.
I agree, and the proposal doesn't change that in the web-layer API. From the perspective of the RP, the RP still sets the RP ID to acmebank.com, for example. Only in the under-the-hood CTAP call does the browser add the namespace prefix so that the authenticator instead sees scp://acmebank.com.
...ah, right, but that means that the RP will need to verify the response rpIdHash against SHA256(prefix + rpId) instead of the usual SHA256(rpId). That doesn't seem to me like a big issue, since the RP already needs special logic to process an SPC response anyway. But it does mean that platform authenticators must necessarily work in the same way - which might also be a good thing, if the list above is considered advantages.