diff --git a/index.bs b/index.bs index c0bea2288..e0de53f3b 100644 --- a/index.bs +++ b/index.bs @@ -905,7 +905,7 @@ When this method is invoked, the user agent MUST execute the following algorithm : If any |authenticator| returns a status indicating that the user cancelled the operation, :: 1. [=set/Remove=] |authenticator| from |issuedRequests|. - 2. [=set/For each=] remaining |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation on + 1. [=set/For each=] remaining |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation on |authenticator| and [=set/remove=] it from |issuedRequests|. : If any |authenticator| returns an error status, @@ -2794,34 +2794,34 @@ When verifying a given {{PublicKeyCredential}} structure (|credential|) as part 1. Using |credential|'s {{Credential/id}} attribute (or the corresponding {{PublicKeyCredential/rawId}}, if [=base64url encoding=] is inappropriate for your use case), look up the corresponding credential public key. -2. Let |cData|, |aData| and |sig| denote the value of |credential|'s {{PublicKeyCredential/response}}'s +1. Let |cData|, |aData| and |sig| denote the value of |credential|'s {{PublicKeyCredential/response}}'s {{AuthenticatorResponse/clientDataJSON}}, {{AuthenticatorAssertionResponse/authenticatorData}}, and {{AuthenticatorAssertionResponse/signature}} respectively. -3. Perform JSON deserialization on |cData| to extract the [=client data=] |C| used for the signature. +1. Perform JSON deserialization on |cData| to extract the [=client data=] |C| used for the signature. -3. Verify that the {{CollectedClientData/type}} in |C| is the string `webauthn.get`. +1. Verify that the {{CollectedClientData/type}} in |C| is the string `webauthn.get`. -4. Verify that the {{CollectedClientData/challenge}} member of |C| matches the challenge that was sent to the authenticator in +1. Verify that the {{CollectedClientData/challenge}} member of |C| matches the challenge that was sent to the authenticator in the {{PublicKeyCredentialRequestOptions}} passed to the {{CredentialsContainer/get()}} call. -5. Verify that the {{CollectedClientData/origin}} member of |C| matches the [=[RP]=]'s [=origin=]. +1. Verify that the {{CollectedClientData/origin}} member of |C| matches the [=[RP]=]'s [=origin=]. -6. Verify that the {{CollectedClientData/tokenBindingId}} member of |C| (if present) matches the [=Token Binding ID=] for the +1. Verify that the {{CollectedClientData/tokenBindingId}} member of |C| (if present) matches the [=Token Binding ID=] for the TLS connection over which the signature was obtained. -7. Verify that the {{CollectedClientData/clientExtensions}} member of |C| is a subset of the extensions requested by the +1. Verify that the {{CollectedClientData/clientExtensions}} member of |C| is a subset of the extensions requested by the [=[RP]=] and that the {{CollectedClientData/authenticatorExtensions}} in |C| is also a subset of the extensions requested by the [=[RP]=]. -8. Verify that the [=rpIdHash=] in |aData| is the SHA-256 hash of the [=RP ID=] expected by the [=[RP]=]. +1. Verify that the [=rpIdHash=] in |aData| is the SHA-256 hash of the [=RP ID=] expected by the [=[RP]=]. -9. Let |hash| be the result of computing a hash over the |cData| using SHA-256. +1. Let |hash| be the result of computing a hash over the |cData| using SHA-256. -10. Using the credential public key looked up in step 1, verify that |sig| is a valid signature over the binary concatenation of +1. Using the credential public key looked up in step 1, verify that |sig| is a valid signature over the binary concatenation of |aData| and |hash|. -11. If the [=signature counter=] value |adata|.[=signCount=] is nonzero or the value stored +1. If the [=signature counter=] value |adata|.[=signCount=] is nonzero or the value stored in conjunction with |credential|'s {{Credential/id}} attribute is nonzero, then run the following substep: - If the [=signature counter=] value |adata|.[=signCount=] is @@ -2843,7 +2843,7 @@ When verifying a given {{PublicKeyCredential}} structure (|credential|) as part [=[RP]=]-specific. -12. If all the above steps are successful, continue with the authentication ceremony as appropriate. Otherwise, fail the +1. If all the above steps are successful, continue with the authentication ceremony as appropriate. Otherwise, fail the [=authentication|authentication ceremony=]. @@ -2932,18 +2932,18 @@ implementable by [=authenticators=] with limited resources (e.g., secure element 1. Let |authenticatorData| denote the [=authenticator data for the attestation=], and let |clientDataHash| denote the [=hash of the serialized client data=]. - 2. If Basic or Privacy CA attestation is in use, the authenticator produces the |sig| by concatenating |authenticatorData| and + 1. If Basic or Privacy CA attestation is in use, the authenticator produces the |sig| by concatenating |authenticatorData| and |clientDataHash|, and signing the result using an attestation private key selected through an authenticator-specific mechanism. It sets |x5c| to the certificate chain of the attestation public key and |alg| to the algorithm of the attestation private key. - 3. If [=ECDAA=] is in use, the authenticator produces |sig| by concatenating |authenticatorData| and |clientDataHash|, and + 1. If [=ECDAA=] is in use, the authenticator produces |sig| by concatenating |authenticatorData| and |clientDataHash|, and signing the result using ECDAA-Sign (see section 3.5 of [[!FIDOEcdaaAlgorithm]]) after selecting an [=ECDAA-Issuer public key=] related to the ECDAA signature private key through an authenticator-specific mechanism (see [[!FIDOEcdaaAlgorithm]]). It sets |alg| to the algorithm of the selected [=ECDAA-Issuer public key=] and |ecdaaKeyId| to the [=identifier of the ECDAA-Issuer public key=] (see above). - 4. If [=self attestation=] is in use, the authenticator produces |sig| by concatenating |authenticatorData| and |clientDataHash|, + 1. If [=self attestation=] is in use, the authenticator produces |sig| by concatenating |authenticatorData| and |clientDataHash|, and signing the result using the credential private key. It sets |alg| to the algorithm of the credential private key, and omits the other fields. @@ -2954,7 +2954,7 @@ implementable by [=authenticators=] with limited resources (e.g., secure element 1. Verify that |attStmt| is valid CBOR conforming to the syntax defined above, and perform CBOR decoding on it to extract the contained fields. - 2. If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case: + 1. If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case: - Verify that |sig| is a valid signature over the concatenation of |authenticatorData| and |clientDataHash| using the attestation public key in |x5c| with the algorithm specified in |alg|. - Verify that |x5c| meets the requirements in [[#packed-attestation-cert-requirements]]. @@ -2962,12 +2962,12 @@ implementable by [=authenticators=] with limited resources (e.g., secure element extension matches the [=aaguid=] in |authenticatorData|. - If successful, return attestation type Basic and [=attestation trust path=] |x5c|. - 3. If |ecdaaKeyId| is present, then the attestation type is ECDAA. In this case: + 1. If |ecdaaKeyId| is present, then the attestation type is ECDAA. In this case: - Verify that |sig| is a valid signature over the concatenation of |authenticatorData| and |clientDataHash| using ECDAA-Verify with [=ECDAA-Issuer public key=] identified by |ecdaaKeyId| (see [[!FIDOEcdaaAlgorithm]]). - If successful, return attestation type ECDAA and [=attestation trust path=] |ecdaaKeyId|. - 4. If neither |x5c| nor |ecdaaKeyId| is present, [=self attestation=] is in use. + 1. If neither |x5c| nor |ecdaaKeyId| is present, [=self attestation=] is in use. - Validate that |alg| matches the algorithm of the [=credentialPublicKey=] in |authenticatorData|. - Verify that |sig| is a valid signature over the concatenation of |authenticatorData| and |clientDataHash| using the credential public key with |alg|. @@ -3310,12 +3310,12 @@ This attestation statement format is used with FIDO U2F authenticators using the as follows: 1. Verify that |attStmt| is valid CBOR conforming to the syntax defined above, and perform CBOR decoding on it to extract the contained fields. - 2. Let |attCert| be the value of the first element of |x5c|. Let |certificate public key| be the public key + 1. Let |attCert| be the value of the first element of |x5c|. Let |certificate public key| be the public key conveyed by |attCert|. If |certificate public key| is not an Elliptic Curve (EC) public key over the P-256 curve, terminate this algorithm and return an appropriate error. - 3. Extract the claimed |rpIdHash| from |authenticatorData|, and the claimed |credentialId| and |credentialPublicKey| from + 1. Extract the claimed |rpIdHash| from |authenticatorData|, and the claimed |credentialId| and |credentialPublicKey| from |authenticatorData|.[=attestedCredentialData=]. - 4. Convert the COSE_KEY formatted |credentialPublicKey| (see Section 7 of [[!RFC8152]]) to CTAP1/U2F public Key + 1. Convert the COSE_KEY formatted |credentialPublicKey| (see Section 7 of [[!RFC8152]]) to CTAP1/U2F public Key format [[!FIDO-CTAP]]. - Let |publicKeyU2F| represent the result of the conversion operation and set its first byte to 0x04. @@ -3328,10 +3328,10 @@ This attestation statement format is used with FIDO U2F authenticators using the (representing y coordinate) from |credentialPublicKey|, confirm its size to be of 32 bytes and concatenate it with |publicKeyU2F|. If size differs or "-3" key is not found, terminate this algorithm and return an appropriate error. - 5. Let |verificationData| be the concatenation of (0x00 || |rpIdHash| || + 1. Let |verificationData| be the concatenation of (0x00 || |rpIdHash| || |clientDataHash| || |credentialId| || |publicKeyU2F|) (see Section 4.3 of [[!FIDO-U2F-Message-Formats]]). - 6. Verify the |sig| using |verificationData| and |certificate public key| per [[!SEC1]]. - 7. If successful, return attestation type Basic with the [=attestation trust path=] set to |x5c|. + 1. Verify the |sig| using |verificationData| and |certificate public key| per [[!SEC1]]. + 1. If successful, return attestation type Basic with the [=attestation trust path=] set to |x5c|. # WebAuthn Extensions # {#extensions} @@ -4095,19 +4095,19 @@ In this flow, the [=[RP]=] does not have a preference for [=platform authenticat username and password, or additional authenticator, or other means acceptable to the [=[RP]=]. Or the user may be in the process of creating a new account. -2. The [=[RP]=] script runs the code snippet below. +1. The [=[RP]=] script runs the code snippet below. -3. The client platform searches for and locates the authenticator. +1. The client platform searches for and locates the authenticator. -4. The client platform connects to the authenticator, performing any pairing actions if necessary. +1. The client platform connects to the authenticator, performing any pairing actions if necessary. -5. The authenticator shows appropriate UI for the user to select the authenticator on which the new credential will be +1. The authenticator shows appropriate UI for the user to select the authenticator on which the new credential will be created, and obtains a biometric or other authorization gesture from the user. -6. The authenticator returns a response to the client platform, which in turn returns a response to the [=[RP]=] script. If +1. The authenticator returns a response to the client platform, which in turn returns a response to the [=[RP]=] script. If the user declined to select an authenticator or provide authorization, an appropriate error is returned. -7. If a new credential was created, +1. If a new credential was created, - The [=[RP]=] script sends the newly generated [=credential public key=] to the server, along with additional information such as attestation regarding the provenance and characteristics of the authenticator. - The server stores the [=credential public key=] in its database and associates it with the user as well as with the @@ -4215,26 +4215,26 @@ credential. 1. The user visits example.com, which serves up a script. -2. The script asks the client platform for an Authentication Assertion, providing as much information as possible to narrow +1. The script asks the client platform for an Authentication Assertion, providing as much information as possible to narrow the choice of acceptable credentials for the user. This can be obtained from the data that was stored locally after registration, or by other means such as prompting the user for a username. -3. The [=[RP]=] script runs one of the code snippets below. +1. The [=[RP]=] script runs one of the code snippets below. -4. The client platform searches for and locates the authenticator. +1. The client platform searches for and locates the authenticator. -5. The client platform connects to the authenticator, performing any pairing actions if necessary. +1. The client platform connects to the authenticator, performing any pairing actions if necessary. -6. The authenticator presents the user with a notification that their attention is needed. On opening the +1. The authenticator presents the user with a notification that their attention is needed. On opening the notification, the user is shown a friendly selection menu of acceptable credentials using the account information provided when creating the credentials, along with some information on the [=origin=] that is requesting these keys. -7. The authenticator obtains a biometric or other authorization gesture from the user. +1. The authenticator obtains a biometric or other authorization gesture from the user. -8. The authenticator returns a response to the client platform, which in turn returns a response to the [=[RP]=] script. +1. The authenticator returns a response to the client platform, which in turn returns a response to the [=[RP]=] script. If the user declined to select a credential or provide an authorization, an appropriate error is returned. -9. If an assertion was successfully generated and returned, +1. If an assertion was successfully generated and returned, - The script sends the assertion to the server. - The server examines the assertion, extracts the [=credential ID=], looks up the registered credential public key it is database, and verifies the assertion's authentication signature.