I was about to say this can in theory be derived from trust in the attestation statement and thus trust that the authenticator obeys the parameter - but since requireResidentKey is actually not included in CollectedClientData, it is indeed not possible for the RP to verify that the option was respected (other than performing a successful authentication ceremony with no allowCredentials).

This issue is related to #889 and #991.

I think we may use RFU bit of flags in authenticator data without breaking changes for requireResidentKey state.

It would be a breaking change for authenticator vendors, who would have to implement that flag.

@emlun yeah, you are right. I have just considered RP side.

@Kieun Is there a reason why RP needs to know if it RK? The client will anyway reject if Authr does not support RK

@herrjemand the requireResidentKey parameter is not signed over, so it's not possible for the RP to verify that the client passed the intended value through to the authenticator. But it's probably not a huge deal since a malicious client could do way worse things anyway.

@herrjemand I'm not sure about the current authenticator's implementation. But, what if the authenticator only supports device resident key feature and the server set requireResidentKey as false or let it as default value?
With current approach, there is no way for RP to check whether the credential is located in the client side or not. Also, such information should be singed over to provide the integrity.

@Kieun FIDO2 authenticator can not be RK only. RK is an optional feature. The core MakeCred and GetAssertion are mandatory. Additionally for RP there is no difference to have RK cred returned or not RK cred returned. For RK it is the same assertion.

@herrjemand Without the authenticator support resident key, RP cannot provide username-less UX flow. So, from the RP perspective, RP should have that kind information.
Regarding the optional feature, would you point out it? I could find the spec says the requireResidentKey and rk is optional parameters for the operation and not for the authenticator type.
I think almost of platform authenticators only support client side residential key.

@Kieun RP can get this information by calling MakeCred with RK and see if the call fails or succeeds.

@Kieun You can refer to CTAP2 protocol https://drafts.fidoalliance.org/fido-2/stable-links-to-latest/fido-client-to-authenticator-protocol.html

I think issue #991 would be something good for you to look

@herrjemand Thanks for pointing out the related docs.
When I tried to test requrieResident key feature with Edge and Windows Hello (PIN), I can create the key with default value (false) and the generated key can be used in username-less flow (empty allowCredentials).
So, I am thinking that browsers do not filter out the authenticator that only supports RK when requireResidentKey is false and the authenticator maintains the credential in the client side.
So, for supporting this, RP should set requireResidentKey is true for the creation and handle error than try with requireResidenKey as false. This is very bad UX for the user and it is hard to handle.
If RP wants support various scenarios (username-less, first-factor, second-factor and etc) depending on the authenticator types, it is better for RP to get the authenticator types (rk, uv, up and etc) during the registration process.

requireResidentKey: false does not mean the authenticator must not create a resident key. It only means that a resident key is not required, so the authenticator is free to choose which kind of key to create.

FIDO authenticators may be required to support non-resident credentials, but I don't think the abstract authenticator model in WebAuthn forbids authenticators that only support resident keys.

Yes, @emlun is correct about it.

So, my suggestion is that RP should have knowledge whether the key is resided in the client side or not during the registration process without trial and error. Such information should be delivered to the RP server so that RP can decide UX flow for the authentication.

@emlun wrote:

requireResidentKey: false does not mean the authenticator must not create a resident key. It only means that a resident key is not required, so the authenticator is free to choose which kind of key to create.

Agreed, that is my understanding per webauthn & CTAP specs.

note that the werbauthn language for requireResidentKey says only this:

"If the parameter is set to true, the authenticator MUST create a client-side-resident public key credential source when creating a public key credential."

Note also the "credential storage modality" section here: http://w3c.github.io/webauthn/#sctn-credential-storage-modality, ..whose last paragraph says:

Note that a resident credential capable authenticator MAY support both storage strategies. In this case, the authenticator MAY at its discretion use different storage strategies for different credentials, though subject to the requireResidentKey option of create().

It seems to me @Kieun has a valid point here (#1060 (comment))

cc: @christiaanbrand

To me this original requirement seems well aligned with issue #991

Handled by PR #1191

#1191 was merged, closing this...