Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Use Cases for L3 #2139

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 37 additions & 37 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -402,27 +402,34 @@ Beyond that, the intended audiences for this document are the following main gro

## Use Cases ## {#sctn-use-cases}

The below use case scenarios illustrate use of two very different types of [=authenticators=], as well as outline further
scenarios. Additional scenarios, including sample code, are given later in [[#sctn-sample-scenarios]].
The below use case scenarios illustrate use of two very different types of [=authenticators=] and credentials across two common deployment types,
as well as outline further scenarios. Additional scenarios, including sample code, are given later in [[#sctn-sample-scenarios]].

### Registration ### {#sctn-usecase-registration}
### Consumers and Multi-Device Credentials ### {#sctn-usecase-consumer-mdc}

#### Registration #### {#sctn-usecase-consumer-mdc-reg}

- On a phone:
* User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using
(possibly a legacy method such as a password), or creates a new account.
* The phone prompts, "Do you want to register this device with example.com?"
* The phone prompts, "Do you want to create a passkey for example.com?"
* User agrees.
* The phone prompts the user for a previously configured [=authorization gesture=] (PIN, biometric, etc.); the user
provides this.
* Website shows message, "Registration complete."


### Authentication ### {#sctn-usecase-authentication}
#### Authentication #### {#sctn-usecase-consumer-mdc-auth}

- On a laptop or desktop:
* User pairs their phone with the laptop or desktop via Bluetooth.
* User navigates to example.com in a browser and initiates signing in.
* User gets a message from the browser, "Please complete this action on your phone."
* If the [=multi-device credential=] (commonly referred to as a synced [=passkey=]) is available on the device:
* the browser or operating system prompts the user for a previously configured [=authorization gesture=] (PIN, biometric, etc.);
the user provides this.
* Web page shows that the selected user is signed in, and navigates to the signed-in page.
* If the synced [=passkey=] is not available on the device:
* the browser or operating system prompts the user for an external authenticator,
such as a phone or security key.
* the user selects a previously linked phone.

- Next, on their phone:
* User sees a discrete prompt or notification, "Sign in to example.com."
Expand All @@ -434,44 +441,37 @@ scenarios. Additional scenarios, including sample code, are given later in [[#sc
* Web page shows that the selected user is signed in, and navigates to the signed-in page.


### New Device Registration ### {#sctn-usecase-new-device-registration}
### Workforce and Single-Device Credentials ### {#sctn-usecase-workforce-sdc}

This use case scenario illustrates how a [=[RP]=] can leverage a combination of a [=roaming authenticator=] (e.g., a USB security
key fob) and a [=platform authenticator=] (e.g., a built-in fingerprint sensor) such that the user has:
This use case scenario illustrates how a workforce-centric [=[RP]=] can leverage a combination of a [=roaming authenticator=] (e.g., a USB security
key) and a [=platform authenticator=] (e.g., a built-in fingerprint sensor) such that the user has:

- a "primary" [=roaming authenticator=] that they use to authenticate on new-to-them [=client devices=] (e.g., laptops,
desktops) or on such [=client devices=] that lack a [=platform authenticator=], and
- a low-friction means to strongly re-authenticate on [=client devices=] having [=platform authenticators=].
- a low-friction means to strongly re-authenticate on [=client devices=] having [=platform authenticators=], or
- a means to strong re-authenticate on [=client devices=] having [=passkey platform authenticators=] which do not support [=single-device credentials=]
(commonly referred to as a device-bound [=passkey=])

Note: This approach of registering multiple [=authenticators=] for an account is also useful in account recovery use cases.
#### Registration #### {#sctn-usecase-workforce-sdc-reg}

- First, on a desktop computer (lacking a [=platform authenticator=]):
* User navigates to `example.com` in a browser and signs in to an existing account using whatever method they have been using
(possibly a legacy method such as a password), or creates a new account.
* User navigates to account security settings and selects "Register security key".
* Website prompts the user to plug in a USB security key fob; the user does.
* The USB security key blinks to indicate the user should press the button on it; the user does.
* Website shows message, "Registration complete."
In this example, the user's employer mails a security key which is preconfigured with a device-bound [=passkey=].

Note: Since this computer lacks a [=platform authenticator=], the website may require the user to present their USB security
key from time to time or each time the user interacts with the website. This is at the website's discretion.
A temporary PIN was sent to the user out of band.

- Later, on their laptop (which features a [=platform authenticator=]):
* User navigates to example.com in a browser and initiates signing in.
* Website prompts the user to plug in their USB security key.
* User plugs in the previously registered USB security key and presses the button.
* Website shows that the user is signed in, and navigates to the signed-in page.
* Website prompts, "Do you want to register this computer with example.com?"
* User agrees.
* Laptop prompts the user for a previously configured [=authorization gesture=] (PIN, biometric, etc.); the user provides this.
* Website shows message, "Registration complete."
* User signs out.
#### Authentication #### {#sctn-usecase-workforce-sdc-auth}

- Later, again on their laptop:
* User navigates to example.com in a browser and initiates signing in.
* Website shows message, "Please follow your computer's prompts to complete sign in."
* Laptop prompts the user for an [=authorization gesture=] (PIN, biometric, etc.); the user provides this.
* Website shows that the user is signed in, and navigates to the signed-in page.
- On a laptop or desktop:
* User navigates to corp.example.com in a browser and initiates signing in.
* The browser or operating system prompts the user for their security key.
* The user connects their USB security key
* The USB security key blinks to indicate the user should press the button on it; the user does.
* The browser or operating system asks the user to enter their PIN.
* The user enters the temporary PIN they were provided and continues.
* The browser or operating system informs the user that they must change their PIN and prompts for a new one.
* The user enters their new PIN and continues.
* The browser or operating system restarts the authentication flow and asks the user to enter their PIN.
* The user enters their new PIN and taps the security key.
* Web page shows that the selected user is signed in, and navigates to the signed-in page.


### Other Use Cases and Configurations ### {#sctn-other-configurations}
Expand Down