Merge pull request #1836 from w3c/prf2

Only expose the UV PRF

index.bs

@@ -6622,14 +6622,14 @@ At this time, one [=credential property=] is defined: the [=resident key credent
 
 ### Pseudo-random function extension (<dfn>prf</dfn>) ### {#prf-extension}
 
-This [=client extension|client=] [=registration extension=] and [=authentication extension=] allows a [=[RP]=] to evaluate outputs from a pseudo-random function (PRF) associated with a [=credential=]. The PRFs provided by this extension map from {{USVString}}s of any length to 32-byte {{ArrayBuffer}}s.
-
-When requested, if a [=credential=] is created on an [=authenticator=] that supports this extension then either one or two freshly-seeded PRFs are associated with it. If two PRFs are associated then, when outputs are requested, one PRF is evaluated if [=user verification=] is performed and the other is evaluated if only a [=test of user presence|user presence test=] is performed. It is the responsibility of the [=[RP]=] to set the {{PublicKeyCredentialRequestOptions/userVerification}} parameter accordingly: [=[RPS]=] SHOULD *consistently* use either the {{UserVerificationRequirement/required}} or {{UserVerificationRequirement/discouraged}} values of {{UserVerificationRequirement}} when using this extension, otherwise the outputs may vary for a given input. To avoid mistakes, the default value of {{UserVerificationRequirement/preferred}} is prohibited when using this extension during [=assertion=] because that could cause the PRF used to vary between operations if [=user verification=] is later enabled on an [=authenticator=].
+This [=client extension|client=] [=registration extension=] and [=authentication extension=] allows a [=[RP]=] to evaluate outputs from a pseudo-random function (PRF) associated with a [=credential=]. The PRFs provided by this extension map from {{BufferSource}}s of any length to 32-byte {{BufferSource}}s.
 
 As a motivating example, PRF outputs could be used as symmetric keys to encrypt user data. Such encrypted data would be inaccessible without the ability to get assertions from the associated [=credential=]. By using the provision below to evaluate the PRF at two inputs in a single [=assertion=] operation, the encryption key could be periodically rotated during [=assertions=] by choosing a fresh, random input and reencrypting under the new output. If the evaluation inputs are unpredictable then even an attacker who could satisfy [=user verification=], and who had time-limited access to the authenticator, could not learn the encryption key without also knowing the correct PRF input.
 
 This extension is implemented on top of the [[FIDO-CTAP]] `hmac-secret` extension. It is a separate [=client extension=] because `hmac-secret` requires that inputs and outputs be encrypted in a manner that only the user agent can perform, and to provide separation between uses by WebAuthn and any uses by the underlying platform. This separation is achieved by hashing the provided PRF inputs with a context string to prevent evaluation of the PRFs for arbitrary inputs.
 
+The `hmac-secret` extension provides two PRFs per credential: one which is used for requests where [=user verification=] is performed and another for all other requests. This extension only exposes a single PRF per credential and, when implementing on top of `hmac-secret`, that PRF MUST be the one used for when [=user verification=] is performed. This overrides the {{UserVerificationRequirement}} if neccessary.
+
 Note: this extension may be implemented for [=authenticators=] that do not use [[FIDO-CTAP]] so long as the behavior observed by a [=[RP]=] is identical.
 
 : Extension identifier
@@ -6641,8 +6641,8 @@ Note: this extension may be implemented for [=authenticators=] that do not use [
 : Client extension input
 ::  <xmp class="idl">
     dictionary AuthenticationExtensionsPRFValues {
-        required ArrayBuffer first;
-        ArrayBuffer second;
+        required BufferSource first;
+        BufferSource second;
     };
 
     dictionary AuthenticationExtensionsPRFInputs {
@@ -6677,8 +6677,8 @@ Note: If PRF results are obtained during [=registration=] then the [=[RP]=] MUST
 
 : Client extension processing ([=authentication extension|authentication=])
 ::
-      1. If {{PublicKeyCredentialRequestOptions/userVerification}} has the value {{UserVerificationRequirement/preferred}}, return a {{DOMException}} whose name is “{{NotSupportedError}}”.
       1. If {{AuthenticationExtensionsPRFInputs/evalByCredential}} is not empty but {{PublicKeyCredentialRequestOptions/allowCredentials}} is empty, return a {{DOMException}} whose name is “{{NotSupportedError}}”.
+      1. If any [=map/key=] in {{AuthenticationExtensionsPRFInputs/evalByCredential}} is the empty string, or is not a valid [=base64url encoding=], or does not equal the {{PublicKeyCredentialDescriptor/id}} of some element of {{PublicKeyCredentialRequestOptions/allowCredentials}} after performing [=base64url encoding|base64url decoding=], then return a {{DOMException}} whose name is “{{SyntaxError}}”.
       1. Initialize the {{AuthenticationExtensionsClientOutputs/prf}} extension output to an empty dictionary.
       1. Let |ev| be null, and try to find any applicable PRF input(s):
           1. If {{AuthenticationExtensionsPRFInputs/evalByCredential}} is present and [=map/exists|contains=] an [=map/entry=] whose [=map/key=] is the [=base64url encoding=] of the [=credential ID=] that will be returned, let |ev| be the [=map/value=] of that entry.