diff --git a/index.bs b/index.bs index dd0a371d8..d21a0b80c 100644 --- a/index.bs +++ b/index.bs @@ -218,11 +218,11 @@ spec: WHATWG URL; urlPrefix: https://url.spec.whatwg.org/ type: dfn text: same site; url: host-same-site -spec: FIDO-CTAP; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html +spec: FIDO-CTAP; urlPrefix: https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html type: dfn text: CTAP2 canonical CBOR encoding form; url: ctap2-canonical-cbor-encoding-form - text: §6.2. Responses; url: responses - text: large, per-credential blobs; url: large-blob + text: §6. Authenticator API; url: authenticator-api + text: large, per-credential blobs; url: authenticatorLargeBlobs spec: FIDO-APPID; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-appid-and-facets-v2.0-id-20180227.html type: dfn @@ -4086,7 +4086,7 @@ describes that [=authenticator model=]. Authentication API implementation, when operating on the authenticators supported by that [=client platform=], MUST be indistinguishable from the behavior specified in [[#sctn-api]]. -Note: [[!FIDO-CTAP]] is an example of a concrete instantiation of this model, but it is one in which there are differences in the data it returns and those expected by the [[#sctn-api|WebAuthn API]]'s algorithms. The CTAP2 response messages are CBOR maps constructed using integer keys rather than the string keys defined in this specification for the same objects. The [=client=] is expected to perform any needed transformations on such data. The [[!FIDO-CTAP]] specification details the mapping between CTAP2 integer keys and WebAuthn string keys, in section [=§6.2. Responses=]. +Note: [[!FIDO-CTAP]] is an example of a concrete instantiation of this model, but it is one in which there are differences in the data it returns and those expected by the [[#sctn-api|WebAuthn API]]'s algorithms. The CTAP2 response messages are CBOR maps constructed using integer keys rather than the string keys defined in this specification for the same objects. The [=client=] is expected to perform any needed transformations on such data. The [[!FIDO-CTAP]] specification details the mapping between CTAP2 integer keys and WebAuthn string keys in Section [=§6. Authenticator API=]. For authenticators, this model defines the logical operations that they MUST support, and the data formats that they expose to the client and the [=[WRP]=]. However, it does not define the details of how authenticators communicate with the [=client device=], @@ -5344,11 +5344,11 @@ the [=authenticator=] MUST: The below signature format definitions satisfy this requirement and serve as examples for deriving the same for other signature algorithms not explicitly mentioned here: - For COSEAlgorithmIdentifier -257 (RS256), `sig` MUST contain the signature generated using the - RSASSA-PKCS1-v1_5 signature scheme defined in section 8.2.1 in [[RFC8017]] with SHA-256 as the hash function. + RSASSA-PKCS1-v1_5 signature scheme defined in Section 8.2.1 of [[RFC8017]] with SHA-256 as the hash function. The signature is not ASN.1 wrapped. - For COSEAlgorithmIdentifier -37 (PS256), `sig` MUST contain the signature generated using the - RSASSA-PSS signature scheme defined in section 8.1.1 in [[RFC8017]] with SHA-256 as the hash function. + RSASSA-PSS signature scheme defined in Section 8.1.1 of [[RFC8017]] with SHA-256 as the hash function. The signature is not ASN.1 wrapped. # [=[WRP]=] Operations # {#sctn-rp-operations} @@ -7394,7 +7394,7 @@ The weight that [=[RPS]=] give to the presence of a signature from a supplementa : enterprise :: The [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. [=Authenticators=] MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested [=RP ID=]. If not permitted, then follow the steps for `direct` attestation. Otherwise |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsSupplementalPubKeysInputs/attestationFormats}}, and |attAaguid| is the corresponding [=/AAGUID=], which MAY be the [=authenticator's=] AAGUID. - Note: CTAP2 does not currently provide for an enterpriseAttestation signal during an authenticatorGetAssertion call. Until that is changed, platform-managed enterprise attestation will not work in that context with CTAP2 [=authenticators=]. + Note: CTAP2 does not currently provide for an enterpriseAttestation signal during an authenticatorGetAssertion call. Until that is changed, platform-managed enterprise attestation will not work in that context with CTAP2 [=authenticators=]. 1. Let |spk| be the newly created or existing supplemental public key, in COSE_Key format [=credentialPublicKey|in the same fashion as for the user credential's credentialPublicKey=] when the latter is conveyed in [=attested credential data=]. @@ -9114,9 +9114,9 @@ for their contributions as our W3C Team Contacts. "FIDO-CTAP": { "authors": ["J. Bradley", "J. Hodges", "M. B. Jones", "A. Kumar", "R. Lindemann", "J. Verrept"], "title": "Client to Authenticator Protocol (CTAP)", - "href": "https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html", + "href": "https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html", "status": "FIDO Alliance Proposed Standard", - "date": "15 June 2021" + "date": "June 21, 2022" }, "FIDO-UAF-AUTHNR-CMDS": {