Re: [webauthn] Personal information updates & webauthn (#1456)

> I don’t quite understand why “this is problematic for non-discoverable” would also have to mean “so it can’t be done for discoverable creds, either”. Even if there’s a future where a solution is found for updating or support-checking of non-discoverable creds, is there a problem with throwing for those cases in the mean time, unlocking the capabilities for discoverable creds?

Non-discoverable credentials are often immutable, and store information within the credential handle. They also are allowed to not save/return metadata like display names, as their use case is usually done after selection (via a first factor).

Since they are immutable, they wouldn't be so much an update as a replace.

Separate from that is the issue that the credential may in a significant number of cases not be passively addressable when such a store or replace was attempted by a site - even immediately after authentication, as the communication channel may be part of the user presence check (e.g. NFC tap to log in).

That is the primary conflict:
1. Credentials in general may not be updatable without the client taking over UX and pushing the user to go through a presence ceremony
2. Credentials may not be available, e.g. I don't have the Authenticator on me or have a USB-C to A or USB-A to lightning adapter with me
3. In all existing authenticators AFAIK, credentials are not updatable, rather you create a new credential which may or may not invalidate the ability to use the old credential.
4. Thus if replacing a credential fails in its transaction between the authenticator and the RP back-end systems, you may have just lost the ability to authenticate

So it could be that the ability to update be limited to a small subset of cases, e.g. credentials on currently connected authenticators, via a credential handle, on authenticators capable of doing a best-effort update vs a credential (without underlying public key or credential handle replacement), confirmed by the user via client UX to prevent abuse scenarios.

If any of this wasn't true, various steps would need to be taken to make the different failure cases not leak information to the RP, which may have negative UX impact - e.g. user prompt to attempt to insert authenticators to see if they support the RP request, user error dismissal so that the RP cannot determine from error messaging or timing if the user rejected the request or if the request was simply responsible to perform, etc.

The RP would not be able to have heuristics to guess if the request would work or not except through attestationsor user-agent guessing on underlying platform authenticators.

What would mostly work (today) would be a user-driven flow e.g. management screen "your displayed name recently changed, would you like to update what is displayed during authentication?" The user would do two user presence checks twice - first to confirm it is the existing credential, then again to register a credential with updated information. This would be treated as a new credential registration in terms of acceptance processing (e.g. attestation checks, etc), with the added bookkeeping step of deleting the old discoverable credential public key and handle.

The act of creating a new discoverable credential with the same underlying user identifier will replace the prior credential per CTAP. On some authenticators, you may see them replace regardless of underlying user identifier (e.g. one discoverable credential per site). Note this still has the 4th concern above - if a transient network failure causes the new credential not to be stored by the RP, you may have disrupted the ability of the user to authenticate.

-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1456#issuecomment-873216916 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 July 2021 19:31:12 UTC