Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reference CTAP 2.1 errata spec #2004

Merged
merged 2 commits into from
Dec 20, 2023
Merged

Reference CTAP 2.1 errata spec #2004

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
def2363
Reference CTAP 2.1 errata spec
selfissued Nov 30, 2023
586642d
Update index.bs
selfissued Dec 4, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions index.bs
View file
Open in desktop
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 @@ -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=],
Expand Down Expand Up @@ -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}
Expand Down Expand Up @@ -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 <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 @@ -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": {
Expand Down