How to guarantee created resident key is actually received by RP in adverse networking conditions? about webauthn

[timcappalli]

This should be addressed by https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Report-API-explainer

I'd also add that the RP should be using the same user handle which will prevent multiple credentials for the same account in the same authenticator.

[arianvp]

Oh good point about making sure the same userHandle is reused! I implemented a user registration page rather naively. I guess it would make sense to write some more guidance for RPs here.

This is what I implemented:

1. I have a registration page where people can register an account by creating a passkey
2. On page load of /register I generated a fresh userHandle and challenge . People then register by picking a userName and creating a passkey.
3. If then due to networking conditions this step fails the user tries again. they refresh the page. Which causes a new userHandle and challenge to be allocated.
4. now the user has two passkeys in their keychain, with different userHandle's but same userNames. Only one of them work.

I guess I should fix this as an RP by:

1. On the register page generate a userHandle just once and save it in the session cookie.
2. If person aborts the registration (e.g. due to networking errors) and reloads the page they use the same userHandle
3. If I understand correctly the new passkey then overrides the old passkey in the UI (Due to having the same userHandle ?)

[timcappalli]

Authenticators and clients are expected to be spec compliant. There is only so much that can be done at a spec level.

Please ask these authenticator-specific questions via a developer/deployment channel (FIDO-DEV, Passkeys Developer, etc).

[timcappalli]

If I understand correctly the new passkey then overrides the old passkey in the UI (Due to having the same userHandle ?)

Yes, that's correct

[arianvp]

Related to this problem -- at least Safari seems to completely ignore excludeCredentials. This means users of our RP end up with multiple iCloud passkeys in their account and there is nothing stopping them from registering with the same authenticator multiple times. They then don't know which one is the "Active" passkey and when they delete the wrong one they get locked out of their account forever. As Safari will delete the old passkey as soon as you register the new one.

Edit: Issue is tracked here: https://bugs.webkit.org/show_bug.cgi?id=270553

[arianvp]

How can I protect myself against a misbehaving authenticator that ignores excludeCredentials like Safari?

Now the following scenario can happen which is even worse than the original issue. Namely account lockout for existing accounts:

1. Register passkey
2. Log in
3. Click register passkey button again. Safari overrides the passkey in your keychain in-place.
4. Network is lost and the response from navigator.credentials.create() doesn't arrive at the RP
5. You're now completely locked out of your account as the first Passkey doesn't work anymore as it's not in your keychain anymore

[arianvp]

To make a concrete proposal to The spec:

The spec currently reads

excludeCredentialDescriptorList
An OPTIONAL list of PublicKeyCredentialDescriptor objects provided by the Relying Party with the intention that, if any of these are known to the authenticator, it SHOULD NOT create a new credential. excludeCredentialDescriptorList contains a list of known credentials.

Which gives the impression that implementing excludeCredentials is optional for authenticators. But I'd say it should be mandatory for client side discoverable credentials.

Given that this overrides discoverable credentials that can lead to user lockout I think we should change the wording to SHALL NOT or MUST NOT.

We should also make it clear that calling create without excludeCredentials can lead to lockout. Calling this an OPTIONAL list is maybe a bit too weak too?

I think both the sections for RPs and for Authenticators could use a bit more guidance on this