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

> * 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:

 1. 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.
 2. Merchant calls `bank.com/.well-known/webauthn/spc-begin` with body `{"user_id": "<user ID>", "tx_info": { <requested transaction amount, recipient, currency, etc> }`
    - Note that we assume nothing about `tx_info` here - its format could be unique per bank, so this could probably be generalized to non-payment applications too.
 3. Bank initiates SPC ceremony and returns opaque token `z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8=` referencing this ceremony state
 4. Merchant calls `navigator.credentials.get({ spc: { rpId: "bank.com", token: "z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8=" } })`
 5. Browser calls `bank.com/.well-known/webauthn/spc-get` with header `X-SPC-Request-Id: z3/kmIC9+6z2ZoO7T7IvngMwa1BfQXVLcxAYsFOeUI8=`
 6. Bank returns a `PublicKeyCredentialRequestOptions` structure (would need us to define encoding for byte arrays)
 7. Browser proceeds as if this `PublicKeyCredentialRequestOptions` had been passed as `publicKey` in a normal `navigator.credentials.get()` call
 8. Merchant receives `PublicKeyCredential` result, 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?


-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-909371980 using your GitHub account


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

Received on Tuesday, 31 August 2021 16:03:47 UTC