1

When you register a Webauthn credential, the private key gets stored in the device(Platform Authenticator/Roaming authenticator). This credential is mapped to the domain(say, www.mydomain.com) of the Relaying Party(RP). When you decommission a credential, we can have the server deregister the credential, but how do we deregister the private key in the authenticator. Does it end up as an unused dangling reference and does the authenticator deregister it after a period of un-usage? What if the same RP now registers a new credential in the same device? At what point does the authenticator get exhausted with a proliferation of these dangling private keys pertaining to a domain? How does the same work with Passkeys?

Thanks!

Manoj Amalraj
  • 535
  • 1
  • 5
  • 14
  • 1
    Just like security key credentials today, or even password managers, the user manages them. There is no practical limit for passkeys in the platform authenticator (Windows Hello, iCloud Keychain, Google Password Manager). – Tim Dec 05 '22 at 20:48

1 Answers1

2

An authenticator only stores a single credential for an (RP ID, user ID) pair. So if the user creates another credential for the same user on that authenticator, it'll overwrite rather than duplicate.

(But RPs should set excludeCredentials and catch InvalidStateError in that case.)

When a passkey is removed on the site, it isn't removed from the authenticator. Like passwords in a password manager, the user manages their passkeys. There has been discussion of a "report" flow for WebAuthn that websites could use to to indicate things like "this passkey wasn't recognised" and thus hint to the user's device that perhaps it should be deleted, but that doesn't currently exist.

agl
  • 1,129
  • 5
  • 6
  • Thank you! If possible, can you please post the official sources for this. – Manoj Amalraj Dec 09 '22 at 19:50
  • 1
    The fact that authenticators model a map is mentioned at https://www.w3.org/TR/webauthn-2/#user-handle and required by https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#op-makecred-step-rk For InvalidStateError see step 3 here https://www.w3.org/TR/webauthn-2/#sctn-op-make-cred, although the fact that browsers make the UI look like a successful creation if attachment=platform for that case is just convention. – agl Dec 09 '22 at 23:12