Some suggestions on the residentKey

[dc-choi]

We developed Server using simpleWebAuthn(5.4.5) library. Test by FIDO Conformance Tools 1.7.2

Currently, SimpleWebAuthn is importing the requireResidentKey using the value of the residentKey, as shown in the example below.

This is in line with Level 2 recommendations.
https://www.w3.org/TR/webauthn/#dictdef-authenticatorselectioncriteria

However, we are trying to get Level1 certification. So I don't use the residentKey.

So, try to get the residentKey, the value comes in undefined.

I thought like the next picture to solve this problem.

I thought that the compatibility with Level1 would be guaranteed to some extent if it was solved like the picture.

Can you give some suggestions to solve this?

[MasterKale]

I'm not sure I follow what the issue is with requireResidentKey always being returned out of generateRegistrationOptions(). How is that failing your efforts in passing FIDO Conformance tests?

Is there a specific FIDO Conformance test I can run locally to confirm the issue you're seeing?

[dc-choi]

There is no problem with the test. I just have a question about the code, so I'd like to discuss it.

The code determines the value of 'requireResidentKey' through the current 'ResidentKey'.

In Level 1, the value can be set to 'requireResidentKey' because there is no 'ResidentKey' field.

However, if you insert the values 'ResidentKey = undefiend' and 'requireResidentKey = true' through the current library, the value will be 'requireResidentKey = false'.

If you look at the Level 2 documentation, it says:

If no value is given then the effective value is required if requireResidentKey is true or discouraged if it is false or absent.

In other words, I thought that 'ResidentKey' was considered the first priority, but if this value did not exist, the value 'ResidentKey' was determined through the value 'RequiredResidentNetKey'.

In conclusion, I thought about changing the current code like this.

I wanted to suggest that if you change this part to something like this, it will be a more flexible code that passes through both Level 2 and Level 1.

[MasterKale]

There is no problem with the test. I just have a question about the code, so I'd like to discuss it.

Ah, I understand now, thanks for the extra context.

Re-reading the definitions of residentKey and requireResidentKey in the L2 spec, I think your interpretation is probably the best way to accommodate both the sentence you highlighted...

residentKey, of type DOMString

Specifies the extent to which the Relying Party desires to create a client-side discoverable credential. For historical reasons the naming retains the deprecated “resident” terminology. The value SHOULD be a member of ResidentKeyRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. If no value is given then the effective value is required if requireResidentKey is true or discouraged if it is false or absent.

...and the bit in requireResidentKey about defaulting to false but being set to true when residentKey is required:

requireResidentKey, of type boolean, defaulting to false

This member is retained for backwards compatibility with WebAuthn Level 1 and, for historical reasons, its naming retains the deprecated “resident” terminology for discoverable credentials. Relying Parties SHOULD set it to true if, and only if, residentKey is set to required.

(Emphasis mine)

In conclusion, I thought about changing the current code like this.

I wanted to suggest that if you change this part to something like this, it will be a more flexible code that passes through both Level 2 and Level 1.

Thank you for taking the time to think up alternative logic for requireResidentKey and residentKey. I was satisfied enough with your explanation that I created #259 to incorporate these changes.

Note that I wasn't able to initialize residentKey to "discouraged" when absent and requireResidentKey is false because when I did so FIDO Conformance v1.7.2 failed the very first test:

AssertionError: Response.authenticatorSelection MUST be set to the requested authenticatorSelection!

Expected
"{"requireResidentKey":false,"userVerification":"preferred","residentKey":"discouraged"}"
to equal
"{"requireResidentKey":false,"userVerification":"preferred"}":

If I left out just that one branch of logic then FIDO Conformance tests remain passing.

[MasterKale]

@dc-choi This improvement to the interplay between requireResidentKey and residentKey is live in @simplewebauthn/[email protected]