Merge branch 'w3c:main' into main

index.bs

@@ -2234,9 +2234,7 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
         </dl>
     </li>
 
-1. Throw a "{{NotAllowedError}}" {{DOMException}}. In order to prevent information leak that could identify the
-    user without [=user consent|consent=], this step MUST NOT be executed before |lifetimeTimer| has expired. See
-    [[#sctn-make-credential-privacy]] for details.
+1. Throw a "{{NotAllowedError}}" {{DOMException}}.
 
 During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and
 authorizing an authenticator. When <code>|options|.{{CredentialCreationOptions/mediation}}</code> is set to {{CredentialMediationRequirement/conditional}}, prominent modal UI should <i>not</i> be shown <i>unless</i> credential creation was previously consented to via means determined by the user agent.
@@ -2683,9 +2681,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
             1.  Return |constructAssertionAlg| and terminate this algorithm.
     </dl>
 
-1. Throw a "{{NotAllowedError}}" {{DOMException}}. In order to prevent information leak that could identify the
-    user without [=user consent|consent=], this step MUST NOT be executed before |lifetimeTimer| has expired. See
-    [[#sctn-assertion-privacy]] for details.
+1. Throw a "{{NotAllowedError}}" {{DOMException}}.
 
 </div>
 
@@ -3871,7 +3867,7 @@ Note: The {{AttestationConveyancePreference}} enumeration is deliberately not re
     ::  The [=[RP]=] wants to receive the [=attestation statement=] as generated by the [=authenticator=].
 
     :   <dfn>enterprise</dfn>
-    ::  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. User agents MUST NOT provide such an attestation unless the user agent or authenticator configuration permits it for the requested [=RP ID=].
+    ::  The [=[RP]=] wants to receive an enterprise attestation, which is an [=attestation statement=] that may include information which uniquely identifies the authenticator. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless the user agent or authenticator configuration permits it for the requested [=RP ID=].
 
         If permitted, the user agent SHOULD signal to the authenticator (at [invocation time](#CreateCred-InvokeAuthnrMakeCred)) that enterprise attestation is requested, and convey the resulting [=/AAGUID=] and [=attestation statement=], unaltered, to the [=[RP]=].
 </div>
@@ -4486,6 +4482,7 @@ Note: The {{PublicKeyCredentialHint}} enumeration is deliberately not referenced
 
 <div dfn-type="enum-value" dfn-for="PublicKeyCredentialHint">
     [=[WRPS]=] may use this enumeration to communicate hints to the user-agent about how a request may be best completed. These hints are not requirements, and do not bind the user-agent, but may guide it in providing the best experience by using contextual information that the [=[RP]=] has about the request. Hints are provided in order of decreasing preference so, if two hints are contradictory, the first one controls. Hints may also overlap: if a more-specific hint is defined a [=[RP]=] may still wish to send less specific ones for user-agents that may not recognise the more specific one. In this case the most specific hint should be sent before the less-specific ones.
+    If the same hint appears more than once, its second and later appearences are ignored.
 
     Hints MAY contradict information contained in credential {{PublicKeyCredentialDescriptor/transports}} and {{AuthenticatorSelectionCriteria/authenticatorAttachment}}. When this occurs, the hints take precedence. (Note that {{PublicKeyCredentialDescriptor/transports}} values are not provided when using [=discoverable credentials=], leaving hints as the only avenue for expressing some aspects of such a request.)
 
@@ -5959,7 +5956,8 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
 
 1. Verify that the <code>[=rpIdHash=]</code> in |authData| is the SHA-256 hash of the [=RP ID=] expected by the [=[RP]=].
 
-1. Verify that the [=UP=] bit of the <code>[=flags=]</code> in |authData| is set, unless <code>|options|.{{CredentialCreationOptions/mediation}}</code> is set to {{CredentialMediationRequirement/conditional}}.
+1. If <code>|options|.{{CredentialCreationOptions/mediation}}</code> is not set to {{CredentialMediationRequirement/conditional}},
+    verify that the [=UP=] bit of the <code>[=flags=]</code> in |authData| is set.
 
 1. If the [=[RP]=] requires [=user verification=] for this registration,
     verify that the [=authData/flags/UV=] bit of the <code>[=flags=]</code> in |authData| is set.
@@ -6388,7 +6386,7 @@ implementable by [=authenticators=] with limited resources (e.g., secure element
                 [=attestation trust path=].
 
 
-### Packed Attestation Statement Certificate Requirements ### {#sctn-packed-attestation-cert-requirements}
+### Certificate Requirements for Packed Attestation Statements ### {#sctn-packed-attestation-cert-requirements}
 
 The attestation certificate MUST have the following fields/extensions:
 
@@ -6427,7 +6425,7 @@ The firmware of a particular authenticator model MAY be differentiated using the
 For example, the following is an attestation certificate containing the above extension OIDs as well as required fields:
 
 ~~~ pem
------BEGIN CERTIFICATE----- <!-- bikeshed emdash workaround -->
+-----BEGIN CERTIFICATE-----
 MIIBzTCCAXOgAwIBAgIUYHS3FJEL/JTfFqafuAHvlAS+hDYwCgYIKoZIzj0EAwIw
 QTELMAkGA1UEBhMCVVMxFDASBgNVBAoMC1dlYkF1dGhuIFdHMRwwGgYDVQQDDBNF
 eGFtcGxlIEF0dGVzdGF0aW9uMCAXDTI0MDEwMzE3NDUyMVoYDzIwNTAwMTA2MTc0
@@ -6438,7 +6436,7 @@ YH9yMOOcci3nr+Q/jOBaWVERo0cwRTAhBgsrBgEEAYLlHAEBBAQSBBDNjDlcJu3u
 3mU7AHl9A8o8MBIGCysGAQQBguUcAQEFBAMCASowDAYDVR0TAQH/BAIwADAKBggq
 hkjOPQQDAgNIADBFAiA3k3aAUVtLhDHLXOgY2kRnK2hrbRgf2EKdTDLJ1Ds/RAIh
 AOmIblhI3ALCHOaO0IO7YlMpw/lSTvFYv3qwO3m7H8Dc
------END CERTIFICATE----- <!-- bikeshed emdash workaround -->
+-----END CERTIFICATE-----
 ~~~
 
 The attributes above are structured within this certificate as such:
@@ -6458,6 +6456,10 @@ The attributes above are structured within this certificate as such:
       2A                                 -- Firmware version: 42
 ~~~
 
+### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements}
+
+The Extension OID `1.3.6.1.4.1.45724.1.1.2` ( `id-fido-gen-ce-sernum` ) MAY additionally be present in packed attestations for enterprise use. If present, this extension MUST indicate a unique octet string value per device against a particular AAGUID. This value MUST remain constant through factory resets, but MAY be distinct from any other serial number or other hardware identifier associated with the device. This extension MUST NOT be marked as critical, and the corresponding value is encoded as an OCTET STRING. This extension MUST NOT be present in non-enterprise attestations.
+
 ## TPM Attestation Statement Format ## {#sctn-tpm-attestation}
 
 This attestation statement format is generally used by authenticators that use a Trusted Platform Module as their cryptographic
@@ -6544,8 +6546,8 @@ engine.
     - Verify that `extraData` is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg".
     - Verify that `attested` contains a `TPMS_CERTIFY_INFO` structure as specified in [[!TPMv2-Part2]] section 10.12.3,
         whose `name` field contains a valid Name for |pubArea|,
-        as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[!TPMv2-Part1]]
-        section 16.
+        as computed using the procedure specified in [[!TPMv2-Part1]]
+        section 16. Note that the hash algorithm is included within the attested `name` field of the TPMS_CERTIFY_INFO structure.
     - Verify that |x5c| is present.
     - Note that the remaining fields in the "Standard Attestation Structure" [[!TPMv2-Part1]]
         section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored.
@@ -8832,8 +8834,8 @@ credential|credentials=] listed by the [=[RP]=] in {{PublicKeyCredentialCreation
 If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing for
 which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
 failure response as soon as an excluded [=authenticator=] becomes available. In this case - especially if the excluded
-[=authenticator=] is a [=platform authenticator=] - the [=[RP]=] could detect that the [=ceremony=] was canceled before the
-timeout and before the user could feasibly have canceled it manually, and thus conclude that at least one of the [=public key
+[=authenticator=] is a [=platform authenticator=] - the [=[RP]=] could detect that the [=ceremony=] was canceled
+before the user could feasibly have canceled it manually, and thus conclude that at least one of the [=public key
 credential|credentials=] listed in the {{PublicKeyCredentialCreationOptions/excludeCredentials}} parameter is available to the user.
 
 The above is not a concern, however, if the user has [=user consent|consented=] to create a new credential before a
@@ -8852,12 +8854,18 @@ key credential|credential=] is listed by the [=[RP]=] in {{PublicKeyCredentialRe
 - A named [=public key credential|credential=] is available, but the user does not [=user consent|consent=] to use it.
 
 If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing
-for which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
-failure response as soon as the user denies [=user consent|consent=] to proceed with an [=authentication ceremony=]. In this
-case the [=[RP]=] could detect that the [=ceremony=] was canceled by the user and not the timeout, and thus conclude that at least
+for which [=public key credential|credentials=] are available.
+For example, one such information leak may happen if the client displays instructions and controls
+for canceling or proceeding with the [=authentication ceremony=]
+only after discovering an [=authenticator=] that [=contains=] a named [=credential=].
+In this case, if the [=[RP]=] is aware of this [=client=] behavior,
+the [=[RP]=] could detect that the [=ceremony=] was canceled by the user and not the timeout, and thus conclude that at least
 one of the [=public key credential|credentials=] listed in the {{PublicKeyCredentialRequestOptions/allowCredentials}} parameter is
 available to the user.
 
+This concern may be addressed by displaying controls allowing the user to cancel an [=authentication ceremony=] at any time,
+regardless of whether any named [=credentials=] are available.
+
 
 ### Privacy Between Operating System Accounts ### {#sctn-os-account-privacy}