From ee25baebbe4390c8eea167072ad31d4ff03602ec Mon Sep 17 00:00:00 2001
From: Emil Lundberg <emil@yubico.com>
Date: Fri, 6 Sep 2024 18:23:48 +0200
Subject: [PATCH] Rename first-factor roaming authenticator and integrate
 passkey term in text

---
 index.bs | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/index.bs b/index.bs
index d0b5feb7b..c5a18aaca 100644
--- a/index.bs
+++ b/index.bs
@@ -497,7 +497,7 @@ A variety of additional use cases and configurations are also possible, includin
 In this section, we walk through some events in the lifecycle of a [=public key credential=], along with the corresponding
 sample code for using this API. Note that this is an example flow and does not limit the scope of how the API can be used.
 
-As was the case in earlier sections, this flow focuses on a use case involving a [=first-factor roaming authenticator=]
+As was the case in earlier sections, this flow focuses on a use case involving a [=passkey roaming authenticator=]
 with its own display. One example of such an authenticator would be a smart phone. Other authenticator types are also supported
 by this API, subject to implementation by the [=client platform=]. For instance, this flow also works without modification for the case of
 an authenticator that is embedded in the [=client device=]. The flow also works for the case of an authenticator without
@@ -4963,13 +4963,13 @@ lists and names some [=authenticator types=] of particular interest.
                 <td> [=Single-factor capable=] </td>
             </tr>
             <tr>
-                <th> <dfn>First-factor roaming authenticator</dfn> </th>
+                <th> <dfn>Passkey roaming authenticator</dfn> </th>
                 <td> [=cross-platform attachment|cross-platform=] </td>
                 <td> [=client-side credential storage modality|Client-side storage=] </td>
                 <td> [=Multi-factor capable=] </td>
             </tr>
             <tr>
-                <th> <dfn>[=Passkey=] platform authenticator</dfn> </th>
+                <th> <dfn>Passkey platform authenticator</dfn> </th>
                 <td> [=platform attachment|platform=] ({{AuthenticatorTransport|transport}} = {{AuthenticatorTransport/internal}}) or [=cross-platform attachment|cross-platform=] ({{AuthenticatorTransport|transport}} = {{AuthenticatorTransport/hybrid}})</td>
                 <td> [=client-side credential storage modality|Client-side storage=] </td>
                 <td> [=Multi-factor capable=] </td>
@@ -4987,13 +4987,18 @@ A [=second-factor roaming authenticator=] is more likely to be used
 to authenticate on a particular [=client device=] for the first time,
 or on a [=client device=] shared between multiple users.
 
-[=User-verifying platform authenticators=] and [=first-factor roaming authenticators=]
+[=Passkey platform authenticators=] and [=passkey roaming authenticators=]
 enable passwordless [=multi-factor=] authentication.
 In addition to the proof of possession of the [=credential private key=],
 these authenticators support [=user verification=] as a second [=authentication factor=],
 typically a PIN or [=biometric recognition=].
 The [=authenticator=] can thus act as two kinds of [=authentication factor=],
 which enables [=multi-factor=] authentication while eliminating the need to share a password with the [=[RP]=].
+These authenticators also support [=discoverable credentials=], also called [=passkeys=],
+meaning they also enable authentication flows where username input is not necessary.
+
+The [=user-verifying platform authenticator=] class is largely obsoleted by the [=passkey platform authenticator=] class,
+but the definition is still used by the {{PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable}} method.
 
 The combinations not named in <a href="#table-authenticatorTypes">Table <span class="table-ref-previous"></span></a>
 have less distinguished use cases: