[webauthn] Cross origin authentication without iframes (#1667)

akshayku has just created a new issue for https://github.com/w3c/webauthn:

== Cross origin authentication without iframes ==
On WebAuthn WG call on 2021-08-25, a proposal concerning secure payment confirmation was discussed which probably originated from web payments groups. Attaching for more details: 
[[WebAuthn WG August 2021] Secure Payment Confirmation.pdf](https://github.com/w3c/webauthn/files/7051084/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. 

1. 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
2. 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. 
3. 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.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 26 August 2021 03:21:35 UTC