Multiple Credentials in a single Enrollment

[cyberphone]

A thing for the future maybe...

For payment systems there is a need to support multiple payment instruments because an Issuer may want to support international card networks as well as national or regional payment networks.
Although you could link multiple payment instruments to a single credential, this creates another dimension in both the RP and the the local credential database. Therefore it seems preferable to enroll multiple credentials in a (for the user) single step.

An issue that could arise is that the use would have to a provide multiple authenticator gestures (and maybe PINs as well) which adds "fuzz" to the process.

Yet another issue is that you might at the same time want to deploy related credentials that do not necessarily require explicit user authorization. An example of that are credentials that are dedicated for lookup tasks like account balance requests.

---

In a system predating FIDO, this is accomplished by a session-based credential management scheme where only the session key is attested, while authenticator- and key-creation have distinct session-based API methods. To avoid leaving a credential container in a potentially incomplete (useless) state, the credential management process (session) is atomic.

[Firstyear]

I don't think this is a good idea. Registration ceremonies today due the them being 1 to 1 for the ceremony to a registered credential, means that the UV policy can be understood and checked, as well as accepted or rejected based on extension requirements.

To allow registration to have multiple credentials registered in a single ceremony would be "the final nail" in uv::preferred and it's ambiguity, but also makes it hard to accept/reject based on a single member of the registration not being valid, when all others other.

[cyberphone]

@Firstyear I'm not sure I understand exactly what you are referring to. My assumption is that you would login to your on-line bank (using whatever login method they require) and select the service "Virtual Payment Cards". There you may be able to select one or more cards. The rest is pretty much a mystery for the average user.

This is how the UV currently works in Windows 10 for setting up / registering a platform-based credential:

For payments this UI is not entirely applicable (...) since a payment credential is not meant to authenticate a person to the Issuer, but to authorize a payment to a Merchant.

The credential selection process offered by Windows 10, is even worse; basing payments on that is simply put not possible. BTW, do anybody out there know how to list and delete such credentials?
Control Panel\User Accounts\Credential Manager provides no clues whatsoever.
Another take on credential selection: https://cyberphone.github.io/doc/saturn/ui-demo/index.html

Anyway, physical payment cards are often co-branded which means that they in reality function as two cards (VISA/MC + local brand), so this idea has a precedent. For practical (and historical) reasons such cards share keys but that is not compatible with current payment industry developments and also leads to confusion regarding credit versus debit cards; they are not the same.

[Firstyear]

If this is payment specific, then why is it here in the webauthn group? If you are tallking about registering (enrolling) many credentials at once, this is not a good idea for webauthn in it's current form due to possible ambiguity and ux issues.

[cyberphone]

Maybe there is no valid use-case for multiple identity credentials? Regarding the WebAuthn UX and credential management, I believe it needs more work in order to challenge existing solutions. A logotype is an absolute minimum.

[Firstyear]

There is a valid case for multiple identity credentials, but they each need to be registered in seperate ceremonies. Else types like userVerification become ambiguous, as does extension registration and processing.

[emlun]

If you're talking about registering multiple credentials each on a separate authenticator, then I agree with @Firstyear that this probably won't fit in very well.

If you're talking about registering multiple credentials all on the same authenticator, that sounds like a duplicate of #1546.

[cyberphone]

If you're talking about registering multiple credentials all on the same authenticator, that sounds like a duplicate of #1546.

Yes, that's more like it. However, this seems to be outside of CTAP2.

[emlun]

It is currently, but CTAP2 could be extended to support it, or WebAuthn could perhaps be extended to have the client perform more than one CTAP call in one ceremony (in fact, clients already do for things like PIN verification) to enable the functionality for existing authenticators.

Looks like we can close this as a duplicate of #1546, then. You're welcome to re-open it in case there's something here not covered by #1546.