- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Feb 2021 09:06:46 +0000
- To: public-webauthn@w3.org
> 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. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1559#issuecomment-773149837 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 09:06:48 UTC