Adding some sentences to describe credential sharing between multiple users

[Kieun]

Proposed Change

Some of passkey providers have been introduced passkey sharing features across users (family members or co-workers). Current spec does not have any description about the credential sharing between multiple users.

It would be better to express the generated credentials could be shared with the help of underlying platforms or others.

[emlun]

Hm. I would agree that passkey sharing (not to be confused with multi-device credentials) goes against some of the assertions we make throughout the spec. See for example the definition of Bound credential:

Bound credential "Authenticator contains a credential" "Credential created on an authenticator"

A public key credential source or public key credential is said to be bound to its managing authenticator. This means that only the managing authenticator can generate assertions for the public key credential sources bound to it.

This may also be expressed as "the managing authenticator contains the bound credential", or "the bound credential was created on its managing authenticator". Note, however, that a server-side credential might not be physically stored in persistent memory inside the authenticator, hence "bound to" is the primary term. See § 6.2.2 Credential Storage Modality.

Also the definition of Credential Key Pair:

Credential Key Pair Credential Private Key Credential Public Key User Public Key User Credential [...] A credential private key is the private key portion of a credential key pair. The credential private key is bound to a particular authenticator - its managing authenticator - and is expected to never be exposed to any other party, not even to the owner of the authenticator. [...]

I would say one could argue that a multi-device credential synced between several of one user's devices still satisfies these if all are tied to one single cloud account. I don't think you could make that argument for credentials freely shared between different people's cloud accounts, though.

There's also the security consideration §13.4.6. Credential Loss and Key Mobility which, even ignoring credential sharing, is just inaccurate since the introduction of the backup state flags:

This specification defines no protocol for backing up credential private keys, or for sharing them between authenticators. In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering multiple credentials for the same user. For example, a user might register platform credentials on frequently used client devices, and one or more roaming credentials for use as backup and with new or rarely used client devices.

Relying Parties SHOULD allow and encourage users to register multiple credentials to the same user account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators.

[Firstyear]

Is there really any need to have specific call outs to multiple users here? I could share my yubikey pin to my partner and that would be "shared". There is no need for the spec to be aware of the credential being accessed by multiple people, since multiple users can be hidden behind a single user/login (eg sharing a netflix account). And that's exactly how it will work with say apples passkey sharing, where the RP will not know the difference between the credential being on my phone, or my partners.

I think we just leave everything as "a user" and what that user decides to do with their credentials is up to them and their own risk/threat analysis. We don't really need to call out anything specific for this IMO.

[Kieun]

The original credential was bound to the user's device. And after introducing passkey, the credential is now bound to the user's account of the underlying passkey providers.

Now, we have sharing features across multiple users, which is bound to something which is not specified anywhere.

This is the reason why I raised the issues for.

[timcappalli]

The original credential was bound to the user's device. And after introducing passkey, the credential is now bound to the user's account of the underlying passkey providers.

There is no case where an existing device-bound passkey can become shared with another user's authenticator.

[Kieun]

There is no case where an existing device-bound passkey can become shared with another user's authenticator.

I'm asking about the security and related policy around credential sharing of passkeys. If the credential could be sent (copied) to other users, then it is no longer bound to the user device and user account of the passkey providers.

[sbweeden]

My perspective is that WebAuthn as a spec deals with clients (browsers) and RP (servers) processing rules, and doesn't have any influence over how an authenticator protects/manages/shares credentials beyond what might be indirectly conveyed via attestation, and the associated promises the authenticator vendor might make associated with that. As such I'd consider any notion of credential sharing is outside the scope of the WebAuthn specification. Ultimately if those things are of concern to a deployer, then attestation should be requested and RP policy dictates what happens next.

[emlun]

I would agree that it were out of scope if not for the fact that the spec does make some assertions about who and what has access to credential keys, as noted above. I agree that most of this should be left as authenticator implementation details, but I think we need to adjust some of those assertions that don't reflect reality.