Require non-null userHandle when allowCredentials is empty?

[emlun]

Proposed Change

Add language to §6.3.3. The authenticatorGetAssertion Operation to require the authenticator to return a non-null userHandle when allowCredentials is empty.

Background

This was originally reported by @ionelMihai in Yubico/java-webauthn-server#94 (comment):

We have a case where a user is using Mac Studio (Ventura 13.3.1 ), and for the authentication where options.allowCredentials is empty his request is failing because it looks like Mac Studio is not setting the userHandle on the response either. So the validation [as implemented in Yubico/java-webauthn-server] is failing.

As far as I can tell, this authenticator implementation is against the spirit of the spec but I don't think it's against the letter of the spec. Step 15 of authenticatorGetAssertion just reads:

15. Return to the user agent:

• [...]
• selectedCredential.userHandle

Note: the returned userHandle value may be null, see: userHandleResult.

I didn't find any actual requirement to return a non-null userHandle when allowCredentials is empty, only that the authenticator is allowed to return null if it needs to.

As noted when the user handle was introduced, the purpose of the user handle is to enable the RP to have control of how it structures its database. This purpose is undermined if some authenticators don't return a userHandle when allowCredentials is empty - the authenticator cannot know which RPs need the user handle and which don't.

Therefore I believe it was intended to be a requirement that userHandle is non-null when allowCredentials is empty, in which case we should make the requirement explicit. Right now this seems to be only an implicitly understood convention.

[MasterKale]

What might the utility be of the client-side userHandle if the successful verification of an auth response for a given credential ID can be linked back on the backend to the user's ID?

[emlun]

@MasterKale see #558 (comment) and the answer: #558 (comment) 🙂

[MasterKale]

@MasterKale see #558 (comment) and the answer: #558 (comment) 🙂

I'm going to pull those comments into here for sake of readability into conversations from 2017:

Why is the user ID necessary for getAssertion? Even for the single factor use case, isn't it possible for the RP to identify the user from only the credential ID even with no allowCredentials? For example:

1. Setup: The RP has an internal table linking credential IDs to public keys and internal user IDs, and the user has previously registered a credential with the RP
2. The user initiates an authentication ritual (providing no additional info at this point)
3. The RP generates a challenge and sends a PublicKeyCredentialRequest (with no allowCredentials) to the client
4. The authenticator chooses a credential and generate an assertion
5. The RP receives the PublicKeyCredential with an AuthenticatorAssertionResponse containing a credential ID and a signature by that credential
6. The RP looks up the public key from its table using the credential ID and verifies the challenge signature
7. If (6) fails, the RP asks the user to try again with a different credential
8. If (6) succeeds, the RP looks up the user ID from its table using the credential ID and initiates an authenticated session for that user

Shouldn't that work?

And @christiaanbrand's response:

It's a bad idea to have some external system with limited context responsible for generating unique indices for a database. We really need to key off something we control, not the authenticator.

I'm not sure I understand Christiaan's response, is the "external system with limited context" the RP's back end? I don't get how it would have "limited context" here, it's the one with the source of truth as to which credentials belong to which users. The mention of "generating unique indices" in particular doesn't make sense to me since we're talking auth, after the RP has generated the various DB indices and user ID's.

[emlun]

What Christiaan means is that the credential ID is chosen by the authenticator, not the RP. The authenticator is the "external system with limited context", not the RP. So if the credential ID is the only identifier the RP can use to look up a credential, then the RP is not in control of that primary lookup index.

[Kieun]

Adding non-null constraints for userHandle when allowCredentials is empty is not sufficient. As far as I remember, Safari sometimes returns empty string for userHandle. This breaks some implementation since the server checks userHandle nullity and if it is not null, the server tries to compare the given userHandle and the identified user id from the database.

So, I think it would be better to explicitly indicate that userHandle is not zero-length if the allowCredential is empty.

Also, there are some descriptions about the requirements.

A user handle is an identifier for a user account, specified by the Relying Party as user.id during registration. Discoverable credentials store this identifier and return it as response.userHandle in authentication ceremonies started with an empty allowCredentials argument.

[ndpar]

What Christiaan means is that the credential ID is chosen by the authenticator, not the RP. The authenticator is the "external system with limited context", not the RP. So if the credential ID is the only identifier the RP can use to look up a credential, then the RP is not in control of that primary lookup index.

I still don't get what exactly the problem is. Regardless of how you look up the credential record, you have to verify credentialId. I would argue that look up by credentialId, which is unique, is better from the performance perspective.

Although RP doesn't generate credentialId, it inserts it in its database and checks the integrity. It has the ultimate say about credentialId and the credential record. From that perspective it is "in control of that primary lookup index".

[arianvp]

primary lookup index is often bound to a specific format; say a UUID. And you can't choose what the credential id format is. Especially in NoSQL databases like Cassandra or DynamoDB where the generation for the IDs need to be tightly controlled such that partitions don't create hotspots having an external system be able to generate IDs for your is bound to cause trouble.

[emlun]

@arianvp also notes in #1909 (comment) :

The spec also says:

Discoverable credentials store this identifier and return it as response.userHandle in authentication ceremonies started with an empty allowCredentials argument.

Which kind of implies that a Discoverable credential should return userHandle

It makes sense that it is non-required in the authenticatorAssertionResponse as non-discoverable credentials can not return a userHandle

We can make the spec more clear maybe. But I think "Discoverable Credentials return userHandle when allowedCredentials is empty" is something that the spec currently (kind of in a round-about way) mandates

So it looks like there's a slight mismatch between the User Handle definition (which says it's required) and the formal authenticatorGetAssertion algorithm (which doesn't explicitly say it's required).