Clarify relationship between PRF and hmac-secret extensions

Author: emlun

index.bs

@@ -7440,11 +7440,30 @@ This [=client extension|client=] [=registration extension=] and [=authentication
 
 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.
+This extension is modeled on top of the [[FIDO-CTAP]] `hmac-secret` extension, but can also be implemented by other means.
+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.
+This extension MAY be implemented for [=authenticators=] that do not use [[FIDO-CTAP]]
+so long as the behavior of the [=client extension inputs=] and [=client extension outputs=] obeys the following interface:
+
+- Let |salt1| and |salt2| be the variables of the same names in the below client processing steps.
+- Let |CredRandom| be an [=authenticator=]-defined, per-credential secret. |CredRandom| is static for the lifetime of the credential.
+- The <code>{{AuthenticationExtensionsPRFOutputs/results}}.{{AuthenticationExtensionsPRFValues/first}}</code> output is
+      <code>HMAC-SHA-256(K=|CredRandom|, text=|salt1|)</code> [[!RFC2104]].
+- The <code>{{AuthenticationExtensionsPRFOutputs/results}}.{{AuthenticationExtensionsPRFValues/second}}</code> output is
+      <code>HMAC-SHA-256(K=|CredRandom|, text=|salt2|)</code> [[!RFC2104]]
+      when |salt2| is present, and absent otherwise.
+
+Note: Implementing on top of `hmac-secret` causes [=authenticator extension outputs=] that are not present otherwise.
+These outputs are encrypted and cannot be used by the [=[RP]=],
+but also cannot be deleted by the client since the [=authenticator data=] is signed.
+
 
 : Extension identifier
 :: `prf`