W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2021

[webauthn] Questions about user handle when supporting usernameless (#1559)

From: Matthew Miller via GitHub <sysbot+gh@w3.org>
Date: Thu, 04 Feb 2021 06:57:42 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-800993492-1612421861-sysbot+gh@w3.org>
MasterKale has just created a new issue for https://github.com/w3c/webauthn:

== Questions about user handle when supporting usernameless ==
Can you help me understand the overall usernameless flow across attestation and assertion, especially in the context of maintaining user privacy? The main thing I'm trying to figure out is why `AuthenticatorAttestationResponse` doesn't include a `userHandle` property as in `AuthenticatorAssertionResponse`.

What started me down this path was how the [spec recommends for user handle contents](https://www.w3.org/TR/webauthn/#sctn-user-handle-privacy) that RP's...

> ...let the user handle be 64 random bytes, and store this value in the user’s account.

When talking about usernameless attestation, there's the case where no user account exists in the RP's database, as in when a user is registering an account for the first time. In this scenario the RP *must* generate a new value for `user.id` in `PublicKeyCredentialCreationOptions`; if it wishes to offer enhanced user privacy then the RP will generate a random 64-byte sequence for this value.

However, because no user handle exists in `AuthenticatorAttestationResponse` then the RP is burdened with needing to write logic to persist the "ephemeral" value of `user.id` in `PublicKeyCredentialCreationOptions` until the user completes attestation. Upon attestation verification the RP would then need to associate the user handle to a new user account after inserting a user row into its internal database and generating an internal DB ID to associate to the user handle.

**Could `AuthenticatorAttestationResponse` be updated to include `userHandle` the same way it's included in `AuthenticatorAssertionResponse`?**

This would help reduce the amount of data that needs to be tracked between attestation options generation and attestation verification, especially data that is only valid for `timeout` number of seconds (just like with `challenge`). Maybe the answer to this simply is, "the RP must persist the two values of `user.id` and `challenge` together after options generation if the RP wishes to support usernameless"...

------

And on the topic of user handle, I have another question about the user handle that I wasn't able to find a solid answer for in the spec:

**Should the unique user handle be a constant value for a user account across all attestations initiated by that user? Or should the user handle be unique per attestation even for the same user?**

If it's the former then it means RP's need only maintain a 1:1 relationship between internal DB user ID and user handle. If it's the latter then there are N number of possible user handles for an internal DB user ID which has a huge implication on database table structures. Would it make sense to clarify this in the spec, or is this an implementation detail better suited to the WACG's efforts?

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1559 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 February 2021 06:57:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 4 February 2021 06:57:44 UTC