credProps output directions contradict notes

[zacknewman]

credProps states the following for the output:

Client extension output
Set clientExtensionResults"[credProps"]["rk"] to the value of the requireResidentKey parameter that was used in the invocation of the authenticatorMakeCredential operation.

If this is true, then I don't see how rk is optional since per the above directive it will always be set since requireResidentKey is always set (it defaults to false when not present). Furthermore the notes about the extension later state that rk should only be set when the client platform knows definitively one way or the other; and if it does not know, then it should omit the property:

Note: some authenticators create discoverable credentials even when not requested by the client platform. Because of this, client platforms may be forced to omit the rk property because they lack the assurance to be able to set it to false. Relying Parties should assume that, if the credProps extension is supported, then client platforms will endeavour to populate the rk property. Therefore a missing rk indicates that the created credential is most likely a non-discoverable credential.

This justifies the reason rk is optional, but it clearly goes against the actual directive which is to always use requireResidentKey. I think the directive should be changed. I think it should state that rk should be set to true when requireResidentKey is true; however it should only set it to false when it knows for sure. This makes it align with the IDL which has rk as optional as well as the notes.

[zacknewman]

Here is a real-world example that is potentially caused from this directive. When an iPhone is used as an authenticator, it only creates client-side/"resident" credentials. If one uses Chromium on a separate device to register a credential on the iPhone using false for AuthenticatorSelectionCriteria.requireResidentKey and "discouraged" for AuthenticatorSelectionCriteria.residentKey and passes the credProps extension, Chromium outputs false for CredentialPropertiesOutput.rk.

This is clearly incorrect. Perhaps if the directive aligned with the notes, then Chromium would instead omit the property entirely rather than assign an incorrect value.

I also understand that credProps is largely useless since it's unlikely a client or user agent could ever know definitively if a client-side credential were created unless requireResidentKey is true making the only possible outputs true or missing; however that's better than giving a directive that causes the wrong value to be assigned sometimes. Perhaps the extension should be removed altogether; but until then, it's better for the notes, IDL and ouput directions to align.