(am rushing a bit here, so the last sentence of the above is not as polished as I'd otherwise like...)

see also https://github.com/fido-alliance/fido-2-specs/issues/873

Integrated, but have changed some wording. PTAL.

And thanks for https://github.com/fido-alliance/fido-2-specs/issues/873. I didn't notice that CTAP2.0 was different and I've updated the wording here accordingly.

I think that there should be a clarification about the exact process to perform a key rotation as this section is hard to parse.

It's not clear if the "first" or "second" prf is the one returned during this exension. This must be clarified to state which of "first" or "second" are returned, and in which userverification scenarios related to the registration process.

(better yet, rename these from "first" and "second" to "default" and "verifiedonly"

It seems like you might be confusing the "two PRFs" with the two first and second extension output fields. Is that so? The first and second outputs are both from the same PRF, and which PRF is determined by whether UV was used:

f = if UV=1 { PRF1 } else { PRF2 }
output.first = f(input.first)
if input.second {
  output.second = f(input.second)
}

I thought this was unambiguously defined by the introduction:

[...] 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 user presence test is performed. [...]

and the definition of the results output:

The results of evaluating the PRF for the inputs given in eval or evalByCredential. Outputs may not be available during registration; see comments in eval.

How would you suggest clarifying it? Would a clarification also resolve your previous comment?

This introduction needs clarification. It does not clearly or accurately describe what this extension does. It appears to read as a "generate a random number on this device". It's also unclear if the operation is yielding the prf content, or is actually signing with hmac in the device, and I think this introduction clearly needs to introduce what the data operations are and what is happening here.

From the RP perspective, does it matter what the precise implementation is? The extension defines an abstraction - indeed "generate a random number on this device", except a repeatable one determined by the extension input - and the RP doesn't need to know the implementation details. But of course the details are needed for interoperability between clients and authenticators, and the extension does define the details by reference to the CTAP hmac-secret extension.

Sure, but at the moment it doesn't say that clearly. It doesn't make it clear it's deterministic.

As well, knowing what it's doing, is going to be important for people to assess if this is correct for their needs.

I realize now that you may not have noticed: there's a bot that adds to the top post a Preview link to the rendered spec. That preview is much easier to read, especially since it includes hyperlinks for [FIDO-CTAP] and other external references.

https://pr-preview.s3.amazonaws.com/agl/webauthn/pull/1424.html#prf-extension

Even with that, this whole extension is really unclear. Variables like "first" and "second". Which one is used from the statement: " 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 user presence test is performed."? It even mentions "key rollover" but without an example of the extension inputs you need to send to perform it or the steps required.

And as mentioned without knowing what it's doing (hmac, random number, ecdh etc) people aren't going to be able to assess if this is relevant.

I really really think this extension needs a great deal of work to clarify it's intent and what it's is meant to do.

I honestly have read it 6 times and I still am confused.

It doesn't make it clear it's deterministic.

The term "pseudo-random function" does include that... but I suppose this means we need to define or reference that term.

And as mentioned without knowing what it's doing (hmac, random number, ecdh etc) people aren't going to be able to assess if this is relevant.

To assess for relevance, it really is enough to know the abstraction: "a pseudo-random function (PRF) associated with a credential". That already tells you all you need to know to determine if it'll work for a given use case. On the other hand to assess for security, you'll need all the fine details anyway, not just a description, and all the details are there by reference to CTAP.

Yes, because today it looks like this is a random number generator function. But if someone is going to assess this, and you are linking to CTAP, why not just declare from the start that this is a Credential Related HMAC function, instead of this round-about language that just confuses people? What purpose does it serve to be so indirect about the function and behaviour of this extension?

It's worth pointing out that you as a specification author are very deep in this terminology and process, but many implementors of this standard as RP's are not as familiar. They don't have access to the meetings, the background and the history. As well, many of them may also be english-second language and that adds yet another barrier for communication. This is yet another reason why clear and accessible communication and language is so critical in a specification that will be assessed for and used in security related areas.

Believe it or not, I agree with you in principle. If readers don't understand the text, then the text needs to be improved. I agree. English is my second language, and I came to this working group as an RP implementer with no prior experience with any of these standards or of standards work. I agree we cannot expect readers to know everything about the field, but I think we should expect readers to read carefully and thoroughly.

Your comments do point out some improvements we need to make, and I appreciate that (although this is all probably moot in this particular case, as the PRF extension has since been dropped from the spec). But I don't agree that the primary focus on the PRF abstraction is a bad thing. It is arguably more direct, as it precisely and concisely states the offered capability without requiring prior knowledge of what HMAC is or what can be constructed with it. ​Another purpose is stated in the extension:

Note: this extension may be implemented for authenticators that do not use [FIDO-CTAP] so long as the behavior observed by a Relying Party is identical.

Still if one does want to know the (CTAP-specific) implementation, one can read on further - and in this case the implementation is even summarized in the first line of a paragraph, making it skim-friendly too. So I honestly cannot see what the improvement to that would be, but I would genuinely appreciate if you can offer a concrete suggestion. As for your other comments (#1424 (comment), #1424 (comment)), I am trying to help determine what exactly needs to be clarified and how best to do so. I apologize if I'm coming across as passive-aggressive, but I also request that others assume best intent as I do for them.

I agree we cannot expect readers to know everything about the field, but I think we should expect readers to read carefully and thoroughly.

Like I said - I have tried to read and understand this extension multiple times and I'm really still not getting it. :(

While I agree in principle people should be expected to read this carefully and thoroughly, it's still important that within this communication we are compassionate and empathetic to our readers and how we approach the language we choose.

I am trying to help determine what exactly needs to be clarified and how best to do so. I apologize if I'm coming across as passive-aggressive, but I also request that others assume best intent as I do for them.

No you aren't being passive aggressive - text is hard and it's always best to assume positive intent. Thank you for taking the time to engage in this discussion :)

Given that this extension has been dropped it is a bit moot and you are correct there, but it was brought up on #1595 . There is certainly some confusion there still about it, as can be seen by the comment:

It is key derivation. Based on a nonce as input you get back a key that you can use to directly encrypt/decrypt with or derive other keys from.

Because that doesn't seem to match the description or function as you/others have described it.

I think that for this to be clear about it's intent, rather than "Pseudo Random Function" which reads like a CSPRNG, it should be directly named based on it's function and intent:

• It's a Key Derivation / Key Retrieval function.

Meaning, that the use of this extension is a way to retrieve associated bytes from a server known/client known input that returns a set of bytes that can be used for other operations.

• OR it's an authenticator associated data verification function.

Meaning, that this authenticator/client, when it is interacted with is asserting that some input bytes are hashed and then signed by this extension. (given certain limitations of course)

Certainly, the second option of data verification would match the expectations people seem to want from #1595 here, allowing some input data to be verified during an assertion process.

Does that help?