SPC Task Foce

Web Authentication proposal for using namespaces

WebAuthn issue

Gerhard: There are two topics really:

a) Protecting keys

b) Splitting cross-origin / for payments

Gerhard: Regarding "spc:" prefix. See my comment:

https://github.com/w3c/webauthn/issues/1667#issuecomment-975171376
… there are multiple use cases, but for banks the primary use case is authentication in their own domain

smcgruer_[EST]: SPC namespace would be allowed to be used with (1) cross-origin behavior and (2) transaction UX
… namespace will prevent login use cases

John_Bradley: There's no reason SPC couldn't use login credentials for payments for BOUND origins
… and a special cross-origin type for other use cases

smcgruer_[EST]: So we could create a "cross-origin:" prefix
… that would mean that if you are a smart merchant, you could not use cross-origin for login

gerhard: The thing I'm worried about with the ns is that it excludes other use cases.

==========

1) If you want to limit to same origin, just allow SPC with WebAuthn vanilla

2) Logging on same origin

3) Login from different origin

4) Payment from different origin

Gerhard: Seems like we want to allow all but #3 (login from non-rp)
… in the case of 3DS and open banking, the other three use cases are interesting

John_Bradley: Login from not-pr.com is problematic.
… other than payments context there is no backchannel protocol.
… if we agreed that all banking credentials could be used as non-rp.com for payments we would not need to differentiate.

Gerhard: Feedback we've heard from issuers is that they are not that keen in using a credential from the merchant.
… what I don't want is banks to not adopt SPC due to theory that credentials could be misused.

smcgruer_[EST]: There's another reason to have the separation - some WebAuthn folks never want their credential to be used by another domain.
… so I think there's good reason to separate the 3p use case if we can.
… if we have a 3p enabled ns, you could have payment and login on rp.com with a single credential (since all 1p)
… once you add the "3p:" namespace, non-rp.com could use the credential ONLY for payments (not login)
… so there is no upgrade path.
… can you use 3p credentials for login?

John_Bradley: Not without changing WebAuthn due to rpid
… if you attempt to say that you are an rpid that the browser can't validate, because there's a colon it's not a valid UI

smcgruer_[EST]: But the developer experience would be terrible

Ian: I am hearing from Gerhard that "same origin" more important than "reuse for login"

John_Bradley: If we limit ourselves to discoverable credentials, we can also leverage the user_id field.
… we could have flag that says "this can be used cross-origin with SPC"
… we have a number of characters we can use in the field for flags
… but we'd need to limit ourselves to discoverable credentials.
… you'd lose non-discoverable credentials, but that might be an ok tradeoff.

JeffH: Why discoverable credentials only?

John_Bradley: No user_id returned in non-discoverable credentials. (You COULD return it but nobody does.)

<Gerhard_> Question: Who could inform us if the usage of Payment in First party would require a special permission / setting during creation?

<Gerhard_> Then we can focus exclusively on the Cross-domain part of the problem..

JeffH: In WebAuthn we say user_id can be used by the RP.
… we state that it's really for an account identifier

John_Bradley: Right, you could not use an existing credential cross-origin

John_Bradley: We could make a structured field.
… I think we have 64 bytes in that field

JeffH: We could do some form of namespace stuff there fore newly created credentials.

JohN_Bradley: An upside is that you would not need an extension. the RP could just make them.
… the semi-downside is that arbitrary RPs could discover the format, but nothing we are doing would stop them anyway

Gerhard_: Is this WebAuthn Level 2?

John_Bradley: Would work with any authenticators that support discoverable credentials.
… and works in roaming authenticators (that support discoverable credentials)

smcgruer_[EST]: My pitch has been that we do discoverable credentials; but in current design you can fall back to non-discoverable credentials.

John_Bradley: I prefer also supporting non-discoverable credentials; but probably going with "what we have in hand" better

https://github.com/w3c/webauthn/issues/1667

ACTION: John Bradley to write up proposal on that thread

JeffH: I suggest we add SPC to the title of that issue.

Gerhard: One question is do we need a flag for 1p usage? (or just 3p usage)

John_Bradley: I don't think WebAuthn has an opinion on using a WebAuthn credential for payments in a 1p

Gerhard: Second point is: what if we want to use it for still other custom displays (related to payment)
… e.g., P2P or recurring
… in other words "even more use cases"

John_Bradley: We may wish to consider structured data to avoid stepping on toes
… e.g., "ephemeral" flag so that credentials are not replicated across devices

Next call

29 Nov