Questions about user handle when supporting usernameless

[MasterKale]

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 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?

[dwaite]

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.

The user handle is a value meant for the authenticator. Some authenticators will only allow a single discoverable credential per domain, others will allow multiple as long as there are different user handles. Creating a new credential on a RP using the same user.id should always eject the first one (which is also how you change properties and metadata on a credential - just replace it).

Some RPs can efficiently look up credential public key and associated account using just the credential handle. These do not need the returned value of user.id (but still may want to perform a sanity check using it).

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.

Is the ability to present an authenticator with a usable attestation the sole requirement of your registration process? Usually there would be other data collected at this point, and the same persistence mechanism (even "in javascript variables") could be applied.

[Kieun]

The user.id is the value provided (and assigned) by RP. The way to generate such value is up to RPs. Some RPs just generate hash value of username of the account. Whether the user account is already created or not, the RP should assign user.id before calling create call. And, the RP should somehow track the challenge/response. I don't think any value for adding userHandle for the attestation response. RP can maintain user.id just like other values for the attestation request.

[MasterKale]

I'm closing this out, there's no action to be taken.