WebAuthn: createCredentialOptions() uses a random UUID as user handle always

[mnylen]

Version

4.3.2

Context

The documentation at https://vertx.io/docs/vertx-auth-webauthn/java/#_registration suggests adding id in the user object. This is, to my best understanding, supposed to be the Relying Party's unique identifier for the user, or the user handle.

In the implementation, however, the user.id in the PublicKeyCredentialCreationOptions generated does not use the given user id information. Instead, it always generates a random UUID there.

The implication of this is that when browsers or applications use the PublicKeyCredentialCreationOptions in navigator.credentials.create call, it is possible to create and store multiple credentials for the same user (as the user id is now completely random) on the authenticator. This is confusing for the users.

Only work around this issue is to override the user.id path from the JsonObject returned, which feels somewhat dirty.

How to fix:

• If id is present in the user object, base64 url encode that as user.id (makes it easier for most use cases, because in most cases the user ID will have a simple String representation (such as a number or String)).

• Or if rawId is present in the user object, use that directly as user.id

Extra

According to WebAuthn spec level 2, the user.id (or user handle) is (https://www.w3.org/TR/webauthn/#dom-publickeycredentialuserentity-id):

id, of type BufferSource
The user handle of the user account entity. A user handle is an opaque byte sequence with a maximum size of 64 bytes, and is not meant to be displayed to the user.

To ensure secure operation, authentication and authorization decisions MUST be made on the basis of this id member, not the displayName nor name members. See Section 6.1 of [RFC8266].

The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address; see § 14.6.1 User Handle Contents for details. The user handle MUST NOT be empty, though it MAY be null.

Note: the user handle ought not be a constant value across different accounts, even for non-discoverable credentials, because some authenticators always create discoverable credentials. Thus a constant user handle would prevent a user from using such an authenticator with more than one account at the Relying Party.