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

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

 1. Backwards compatible all the way back to U2F security keys
 2. Works with resident credentials on existing FIDO2 security keys
 3. The RP remains in control of which credentials have the SPC capability
 4. Credentials must be created with the SPC capability explicitly enabled; it is impossible for existing credentials to be opted in accidentally
 5. 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?

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


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

Received on Tuesday, 2 November 2021 16:08:58 UTC