diff --git a/index.bs b/index.bs index 9ccb00601..52eab31ad 100644 --- a/index.bs +++ b/index.bs @@ -1459,21 +1459,21 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S This section normatively specifies the API for creating and using [=public key credentials=]. The basic idea is that the credentials belong to the user and are [=managing authenticator|managed=] by a [=[WAA]=], with which the [=[WRP]=] interacts through the [=client platform=]. [=[RP]=] scripts can (with the [=user consent|user's consent=]) request the -browser to create a new credential for future use by the [=[RP]=]. See Figure , below. +browser to create a new credential for future use by the [=[RP]=]. See Figure , below.
- +
Registration Flow
Scripts can also request the user’s permission to perform -[=authentication=] operations with an existing credential. See Figure , below. +[=authentication=] operations with an existing credential. See Figure , below.
- +
Authentication Flow
@@ -4152,7 +4152,7 @@ The [=authenticator data=] has a compact but extensible encoding. This is desire limited capabilities and low power requirements, with much simpler software stacks than the [=client platform=]. The [=authenticator data=] structure is a byte array of 37 bytes or more, -laid out as shown in Table . +laid out as shown in Table .
@@ -4247,10 +4247,10 @@ the requested [=public key credential|credential=] is [=scoped=] to exactly matc - If the authenticator does not include any [=authData/extensions|extension data=], it MUST set the [=authData/flags/ED=] [=flag=] to zero, and to one if [=authData/extensions|extension data=] is included. -Figure shows a visual representation of the [=authenticator data=] structure. +Figure shows a visual representation of the [=authenticator data=] structure.
- +
[=Authenticator data=] layout.
@@ -4306,11 +4306,11 @@ the same procedure as other [=assertion signatures=] generated by the [=authenti ### Credential Backup State ### {#sctn-credential-backup} Credential [=backup eligibility=] and current [=backup state=] is conveyed by the [=authData/flags/BE=] and [=authData/flags/BS=] [=flags=] in the [=authenticator data=], as -defined in Table . +defined in Table . The value of the [=authData/flags/BE=] [=flag=] is set during [=authenticatorMakeCredential=] operation and MUST NOT change. -The value of the [=authData/flags/BS=] [=flag=] may change over time based on the current state of the [=public key credential source=]. Table below defines +The value of the [=authData/flags/BS=] [=flag=] may change over time based on the current state of the [=public key credential source=]. Table below defines valid combinations and their meaning.
@@ -4412,7 +4412,7 @@ The above examples illustrate the primary authenticator type characte - Whether the authenticator is [=discoverable credential capable=] — the [=credential storage modality=]. These characteristics are independent and may in theory be combined in any way, -but Table +but Table lists and names some [=authenticator types=] of particular interest. @@ -4478,7 +4478,7 @@ 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]=]. -The combinations not named in Table +The combinations not named in Table have less distinguished use cases: @@ -4838,13 +4838,13 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o specified in [[#sctn-authenticator-data]] including |processedExtensions|, if any, as the [=authData/extensions=] and excluding [=attestedCredentialData=]. This |authenticatorData| MUST include [=attested credential data=] if, and only if, |attestationFormat| is not `none`. 1. Let |signature| be the [=assertion signature=] of the concatenation |authenticatorData| || |hash| using the - [=public key credential source/privateKey=] of |selectedCredential| as shown in Figure , below. A simple, + [=public key credential source/privateKey=] of |selectedCredential| as shown in Figure , below. A simple, undelimited concatenation is safe to use here because the [=authenticator data=] describes its own length. The [=hash of the serialized client data=] (which potentially has a variable length) is always the last element.
- +
Generating an [=assertion signature=].
@@ -4949,10 +4949,10 @@ Authenticators may be required to store arbitrary strings chosen by a [=[RP]=], Each arbitrary string in the API will have some accommodation for the potentially limited resources available to an [=authenticator=]. If string value truncation is the chosen accommodation then authenticators MAY truncate in order to make the string fit within a length equal or greater than the specified minimum supported length. Such truncation SHOULD also respect UTF-8 sequence boundaries or [=grapheme cluster=] boundaries [[UAX29]]. This defines the maximum truncation permitted and authenticators MUST NOT truncate further. -For example, in figure the string is 65 bytes long. If truncating to 64 bytes then the final 0x88 byte must be removed purely because of space reasons. Since that leaves a partial UTF-8 sequence the remainder of that sequence may also be removed. Since that leaves a partial [=grapheme cluster=] an authenticator may remove the remainder of that cluster. +For example, in figure the string is 65 bytes long. If truncating to 64 bytes then the final 0x88 byte must be removed purely because of space reasons. Since that leaves a partial UTF-8 sequence the remainder of that sequence may also be removed. Since that leaves a partial [=grapheme cluster=] an authenticator may remove the remainder of that cluster.
- +
The end of a UTF-8 encoded string showing the positions of different truncation boundaries.
@@ -4995,14 +4995,14 @@ or otherwise perform [=None|no attestation=]. All this information is returned by [=authenticators=] any time a new [=public key credential=] is generated, and optionally when exercised, in the overall form of an attestation object. The relationship of the [=attestation object=] with [=authenticator data=] (containing -[=attested credential data=]) and the [=attestation statement=] is illustrated in figure , below. +[=attested credential data=]) and the [=attestation statement=] is illustrated in figure , below. If an [=authenticator=] employs [=self attestation=] or [=None|no attestation=], then no provenance information is provided for the [=[RP]=] to base a trust decision on. In these cases, the [=authenticator=] provides no guarantees about its operation to the [=[RP]=].
- +
[=Attestation object=] layout illustrating the included [=authenticator data=] from a {{CredentialsContainer/create()|create()}} operation (containing [=attested credential data=]) and the [=attestation statement=].
@@ -5061,7 +5061,7 @@ Attestations in [=assertions=] could be helpful in at least the following situat ### Attested Credential Data ### {#sctn-attested-credential-data} Attested credential data is a variable-length byte array added to the [=authenticator data=] when generating an [=attestation -object=] for a credential. Its format is shown in Table . +object=] for a credential. Its format is shown in Table .