Skip to content

Commit

Permalink
Merge pull request #2004 from selfissued/mbj-ctap2.1-errata
Browse files Browse the repository at this point in the history 
Reference CTAP 2.1 errata spec
  • Loading branch information
@selfissued
selfissued authored Dec 20, 2023
2 parents c639dd5 + 586642d commit a83c764
Showing 1 changed file with 9 additions and 9 deletions.
18 changes: 9 additions & 9 deletions index.bs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -4077,7 +4077,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=],
Expand Down Expand Up @@ -5336,11 +5336,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}
Expand Down Expand Up @@ -7387,7 +7387,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 <i>not</i> 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 <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#makecred-enterpriseattestation">enterpriseAttestation</a> signal during an <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetAssertion">authenticatorGetAssertion</a> call. Until that is changed, <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#platform-managed-enterprise-attestation">platform-managed enterprise attestation</a> will not work in that context with CTAP2 [=authenticators=].
Note: CTAP2 does not currently provide for an <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#makecred-enterpriseattestation">enterpriseAttestation</a> signal during an <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authenticatorGetAssertion">authenticatorGetAssertion</a> call. Until that is changed, <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#platform-managed-enterprise-attestation">platform-managed enterprise attestation</a> will not work in that context with CTAP2 [=authenticators=].
</dl>

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=].
Expand Down Expand Up @@ -9222,9 +9222,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": {
Expand Down

0 comments on commit a83c764

Please sign in to comment.