eclipse-vertx / eclipse-vertx/vertx-auth
WebAuthn: createCredentialOptions() uses a random UUID as user handle always
- Dominant language
- Java
- Stars
- 175
- Forks
- 159
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 3
Description
### 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](https://heycam.github.io/webidl/#BufferSource)
> The [user handle](https://www.w3.org/TR/webauthn/#user-handle) of the user account entity. A [user handle](https://www.w3.org/TR/webauthn/#user-handle) is an opaque [byte sequence](https://infra.spec.whatwg.org/#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](https://www.w3.org/TR/webauthn/#dom-publickeycredentialuserentity-id) member, not the [displayName](https://www.w3.org/TR/webauthn/#dom-publickeycredentialuserentity-displayname) nor [name](https://www.w3.org/TR/webauthn/#dom-publickeycredentialentity-name) members. See Section 6.1 of [[RFC8266]](https://www.w3.org/TR/webauthn/#biblio-rfc8266).
>
> The [user handle](https://www.w3.org/TR/webauthn/#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](https://www.w3.org/TR/webauthn/#sctn-user-handle-privacy) for details. The [user handle](https://www.w3.org/TR/webauthn/#user-handle) MUST NOT be empty, though it MAY be null.
>
> Note: the [user handle](https://www.w3.org/TR/webauthn/#user-handle) ought not be a constant value across different accounts, even for [non-discoverable credentials](https://www.w3.org/TR/webauthn/#non-discoverable-credential), because some authenticators always create [discoverable credentials](https://www.w3.org/TR/webauthn/#discoverable-credential). Thus a constant [user handle](https://www.w3.org/TR/webauthn/#user-handle) would prevent a user from using such an authenticator with more than one account at the [Relying Party](https://www.w3.org/TR/webauthn/#relying-party).
Contributor guide
Assessment
This issue has not been assessed yet.