Add consideration of browser permissions framework for extension processing

index.bs

@@ -3759,15 +3759,6 @@ WebAuthn [=[RP]=].
     Specification](https://dev.w3.org/geo/api/spec-source.html#coordinates_interface).
 
     <pre>
-    CDDL:
-      {
-       loc: positionCoordinates,
-      }    
-      positionCoordinates = [
-         latitude: float64,
-         longitude: float64,
-         altitude: float64
-         ]
      CBOR Example:
         ...                                         -- [=RP ID=] hash (32 bytes)
         81                                          -- UP and ED set
@@ -3861,6 +3852,7 @@ This [=registration extension=] and [=authentication extension=] enables use of
                     01           -- Subitem 3: CBOR short for Matcher Protection Type Software
     </pre>
 
+
 # IANA Considerations # {#sctn-IANA}
 
 ## WebAuthn Attestation Statement Format Identifier Registrations ## {#sctn-att-fmt-reg}
@@ -4289,6 +4281,101 @@ upon a client's behavior; e.g.: the Relying Party should store the challenge tem
 until the operation is complete. Tolerating a mismatch will compromise the security
 of the protocol.
 
+## Attestation Security Considerations ## {#sec-attestation-security-considerations}
+
+### Attestation Certificate Hierarchy ### {#cert-hierarchy}
+
+A 3-tier hierarchy for attestation certificates is RECOMMENDED (i.e., Attestation Root, Attestation Issuing CA, Attestation
+Certificate). It is also RECOMMENDED that for each WebAuthn Authenticator device line (i.e., model), a separate issuing CA is
+used to help facilitate isolating problems with a specific version of a device.
+
+If the attestation root certificate is not dedicated to a single WebAuthn Authenticator device line (i.e., AAGUID), the AAGUID
+SHOULD be specified in the attestation certificate itself, so that it can be verified against the [=authenticator data=].
+
+
+### Attestation Certificate and Attestation Certificate CA Compromise ### {#ca-compromise}
+
+When an intermediate CA or a root CA used for issuing attestation certificates is compromised, WebAuthn [=authenticator=]
+attestation keys are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
+has recorded the public attestation keys for their devices can issue new attestation certificates for these keys from a new
+intermediate CA or from a new root CA. If the root CA changes, the [=[RPS]=]  MUST update their trusted root certificates
+accordingly.
+
+A WebAuthn Authenticator attestation certificate MUST be revoked by the issuing CA if its key has been compromised. A WebAuthn
+Authenticator manufacturer may need to ship a firmware update and inject new attestation keys and certificates into already
+manufactured WebAuthn Authenticators, if the exposure was due to a firmware flaw. (The process by which this happens is out of
+scope for this specification.) If the WebAuthn Authenticator manufacturer does not have this capability, then it may not be
+possible for [=[RPS]=] to trust any further attestation statements from the affected WebAuthn Authenticators.
+
+If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [=[RP]=]'s policy
+requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the [=[RP]=] also
+un-registers (or marks with a trust level equivalent to "[=self attestation=]") [=public key credentials=] that were registered
+after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
+that [=[RPS]=] remember intermediate attestation CA certificates during Authenticator registration in order to un-register
+related [=public key credentials=] if the registration was performed after revocation of such certificates.
+
+If an [=ECDAA=] attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked
+authenticators) maintained by the related ECDAA-Issuer. The [=[RP]=] SHOULD verify whether an authenticator belongs to the
+RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm]]). For example, the FIDO Metadata Service
+[[FIDOMetadataService]] provides one way to access such information.
+
+
+## credentialId Unsigned ## {#credentialIdSecurity}
+
+The [=credential ID=] is not signed.
+This is not a problem because all that would happen if an [=authenticator=] returns
+the wrong [=credential ID=], or if an attacker intercepts and manipulates the [=credential ID=], is that the [=[RP]=] would not look up the correct
+[=credential public key=] with which to verify the returned signed [=authenticator data=]
+(a.k.a., [=assertion=]), and thus the interaction would end in an error.
+
+## Browser Permissions Framework and Extensions ## {#browser-permissions-framework-extensions}
+
+The Web Authentication API should leverage the browser permissions framework as much as possible when obtaining user permissions for 
+certain extensions.  An example is the location extension (see [[#sctn-location-extension]]), which should make use of the existing browser permissions framework for the
+Geolocation API.  
+
+# Privacy Considerations # {#sctn-privacy-considerations}
+
+The privacy principles in [[!FIDO-Privacy-Principles]] also apply to this specification.
+
+## Attestation Privacy ## {#sec-attestation-privacy}
+
+Attestation keys can be used to track users or link various online identities of the same user together. This can be mitigated
+in several ways, including:
+
+- A WebAuthn [=authenticator=] manufacturer may choose to ship all of their devices with the same (or a fixed number of)
+    attestation key(s) (called [=Basic Attestation=]). This will anonymize the user at the risk of not being able to revoke a
+    particular attestation key if its private key is compromised.
+
+    [[UAFProtocol]] requires that at least 100,000 devices share the same attestation certificate in order to produce
+    sufficiently large groups. This may serve as guidance about suitable batch sizes.
+
+- A WebAuthn Authenticator may be capable of dynamically generating different attestation keys (and requesting related
+    certificates) per [=origin=] (following the [=Privacy CA=] approach). For example, a WebAuthn Authenticator can ship with a
+    master attestation key (and certificate), and combined with a cloud operated privacy CA, can dynamically generate per
+    [=origin=] attestation keys and attestation certificates.
+
+- A WebAuthn Authenticator can implement [=Elliptic Curve based direct anonymous attestation=] (see [[FIDOEcdaaAlgorithm]]).
+    Using this scheme, the authenticator generates a blinded attestation signature. This allows the [=[RP]=] to verify the
+    signature using the [=ECDAA-Issuer public key=], but the attestation signature does not serve as a global correlation handle.
+
+
+## Authentication Ceremonies ## {#sec-assertion-privacy}
+
+In order to protect the user from being identified without [=user consent|consent=], implementations of the
+{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} method need to take care to
+not leak information that could enable the [=[RP]=] to distinguish between these cases:
+
+- A named [=public key credential|credential=] is not available.
+- 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 the operation. In this case the [=[RP]=]
+could detect that the operation 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.
+
 
 # Acknowledgements # {#acknowledgements}
 We thank the following for their contributions to, and thorough review of, this specification: Richard Barnes, Dominic Battré,