Update top level use cases to account for multi-device credentials

[timcappalli]

The current top level use cases (sctn-use-cases) were written prior to the multi-device credential effort and should be rewritten to include this new topic.

Be sure to include: https://github.com/w3c/webauthn/issues/1735

[Firstyear]

Will these use cases also discuss when RP's want to exclude multi-device credentials?

[timcappalli]

Will these use cases also discuss when RP's want to exclude multi-device credentials?

Proposed text and/or PRs are welcome!

[Firstyear]

Sure, I was in the middle of writing these up for a blog anyway, so I'll submit some text and and overview of this from the view of an RP/Enterprise and public site that would want this.

[Firstyear]

@MasterKale cc you probably have use cases here we should think about too.

[Firstyear]

So, some draft use cases. Especially as someone who implements an RP, and works with a lot of people deploying theirs, I think this boils down to a set of five possible scenarioes and workflows.

Security Token (Public) ^^^^^^^^^^^^^^^^^^^^^^^

In this use case, we want our authenticator to be a single factor to compliment an existing password. Instead of an authenticator, a TOTP scheme could alternately be used where either the TOTP or authenticator plus the password is sufficient to grant access.

Generally in this use case, most identity providers do not care about attestation of the authenticator, what is more important is that some kind of non-password authentication exists and is present.

Step wise this would appear as:

Registration:

1. The user indicates they wish to enroll a security token
2. The identity provider issues a challenge
3. The browser lists which authenticators attached to the device could be registered
4. The user interacts with the authenticator (note a pin should not be requested, but fingerprint is okay since it's "transparent")
5. The authenticator releases the signed public key
6. The authenticator is added to the users account

Authentication:

1. The user enters their username
2. The user provides their password and it is validated (note we could do this after webauthn)
3. The user indicates they wish to use a security token
4. The identity provider issues a webauthn challenge, limited by the list of authenticators and transports we know are valid for the authenticators associated.
5. The browser offers the list of authenticators that can proceed
6. The user interacts with the authenticator (note a pin should not be requested, but fingerprint is okay since it's "transparent")
7. The authenticator releases the signature

Security Token (Corporate) ^^^^^^^^^^^^^^^^^^^^^^^^^^

This is the same as the public use case, except that in many corporations we may want to define a list of trusted providers of tokens. It's important to us here that these tokens have a vetted or audited supply chain, and we have an understanding of "where" the cryptographic material may reside.

For this example, we likely want attestation, as well as the ability to ensure these credentials are not recoverable or transferable between authenticators. Resident Key may or may not be required in these cases.

Since these are guided by policy, we likely want to have our userinterfaces guide our users to register or use the correct keys since we have a stricter list of what is accepted.

The changes to the workflow in this example are based in the registration.

Registration:

1. The user indicates they wish to enroll a security token
2. The identity provider issues a challenge, with a list of what transports of known approved authenticators exist that could be used.
3. The browser lists which authenticators attached to the device could be registered, per the transport list
4. The user interacts with the authenticator (note a pin should not be requested, but fingerprint is okay since it's "transparent")
5. The authenticator releases the signed public key
6. The identity provider examines the attestation and asserts it is from a trusted manufacturer
7. The identity provider examines the enrollment, and asserts it is bound to the hardware (IE not a passkey/backup)
8. The authenticator is added to the users account

Passwordless (Public) ^^^^^^^^^^^^^^^^^^^^^

In this example, rather than having our authenticator as a single factor, we want it to be truly multifactor. This allows the user to login with nothing but their authenticator.

As a result, we need to strictly verify that the authenticator did a valid user verification.

Given that the authenticator is now the "sole" authenticator (even if multi-factor) we are more likely to want attestation here using privacy features granted through indirect attestation. That way we can have a broad list of known good security token providers that we accept.

Registration:

1. The user indicates they wish to enroll a security token
2. The identity provider issues a challenge
3. The browser lists which authenticators attached to the device could be registered
4. The user interacts with the authenticator - user verification MUST be provided i.e. pin or biometric.
5. The authenticator releases the signed public key
6. The identity provider asserts that user verification occured
7. (Optional) The identity provider examines the attestation and asserts it is from a trusted manufacturer
8. The authenticator is added to the users account

Authentication:

1. The user enters their username
2. The identity provider issues a webauthn challenge
3. The browser offers the list of authenticators that can proceed
4. The user interacts with the authenticator - user verification MUST be provided i.e. pin or biometric.
5. The authenticator releases the signature
6. The identity provider asserts that user verification occured

Passwordless (Corporate) ^^^^^^^^^^^^^^^^^^^^^^^^

Again, this is similar to above. We narrow and focus this use case with a stricter attestation list of what is valid. We also again want to strictly control and prevent cryptographic material being moved, so we want to ensure these are not transferrable. We may want resident keys to be used here too since we have a higher level of trust in our devices now too. Again, we also will be able to strictly guide UI's due to our knowledge of exactly what devices we accept.

Registration:

1. The user indicates they wish to enroll a security token
2. The identity provider issues a challenge, with a list of what transports of known approved authenticators exist that could be used.
3. The browser lists which authenticators attached to the device could be registered, per the transport list
4. The user interacts with the authenticator - user verification MUST be provided i.e. pin or biometric.
5. The authenticator releases the signed public key
6. The identity provider examines the attestation and asserts it is from a trusted manufacturer
7. (Optional) The identity provider asserts that a resident key was created
8. The identity provider examines the enrollment, and asserts it is bound to the hardware (IE not a passkey/backup)
9. The identity provider asserts that user verification occured
10. (Optional) The identity provider asserts the verification method complies to policy
11. The authenticator is added to the users account

Usernameless ^^^^^^^^^^^^

Usernameless is similar to passwordless but requires resident keys as the username of the account is bound to the key and discovered by the client. Otherwise many of the features of passwordless apply.

It's worth noting that due to the complexity and limitations of resident key management it is not feasible for any public service provider to currently use usernameless credentials on a broad scale without significant risk of credential loss. As a result, we limit our use case to corporate only, as they are the only entities in the position to effectively manage these issues.

Registration

1. The user indicates they wish to enroll a security token
2. The identity provider issues a challenge, with a list of what transports of known approved authenticators exist that could be used.
3. The browser lists which authenticators attached to the device could be registered, per the transport list
4. The user interacts with the authenticator - user verification MUST be provided i.e. pin or biometric.
5. The authenticator releases the signed public key
6. The identity provider examines the attestation and asserts it is from a trusted manufacturer
7. The identity provider asserts that a resident key was created
8. The identity provider examines the enrollment, and asserts it is bound to the hardware (IE not a passkey/backup)
9. The identity provider asserts that user verification occured
10. (Optional) The identity provider asserts the verification method complies to policy
11. The authenticator is added to the users account

Authentication:

1. The identity provider issues a webauthn challenge
2. The browser offers the list of authenticators that can proceed
3. The user interacts with the authenticator - user verification MUST be provided i.e. pin or biometric.
4. The authenticator releases the signature
5. The identity provider asserts that user verification occured
6. The identity provider extracts and uses the provided username that was supplied