Unique Account Registration for Authenticator in Specific RP

[MarklearnML]

Hi, I would like to know if there is a method to ensure that an authenticator can only register one account for a specific RP. Is there a way to obtain the unique identifier of an authenticator (reject registration from server) or for the authenticator to reject registration of a new account if it detects that the RP already exists?

[emlun]

Hi! No, there is no such capability in WebAuthn. There is no unique identifier¹ since that would enable tracking, and there is no API to probe for whether any credential already exists. For an extended discussion of why, see: w3c/webauthn#1915 .

What you can do is use excludeCredentials to prevent creating multiple credentials for the same account on an authenticator. The RelyingParty.startRegistration() method sets excludeCredentials automatically by querying the CredentialRepository. In theory you could set excludeCredentials to include all credentials in all accounts, but this obviously doesn't scale if there are more than maybe 20-50 accounts in your service - certainly not if there are thousands.

Depending on what you want to accomplish, you might be able to use conditional UI instead. This enables discoverable credentials (passkeys) to show up as autofill options in a text field (typically a username or password field) instead of interrupting the UI with the modal WebAuthn popup. If the user selects a passkey from the autofill options, then that passkey is used to authenticate. If you do this in a registration form, you can guide users to log in if they already have an account instead of creating a new one. A demo of this kind of flow is available on passkey.org . But note that this does not prevent registering multiple accounts, it just helps nudge users into a different flow.

Does that help?

Footnotes

1. Except for enterprise attestation, but that is not available in consumer-grade authenticators. ↩

[MarklearnML]

Thank you for your quick response. Your answer was very helpful to me.

…

On Wed, Mar 13, 2024 at 9:21 PM Emil Lundberg ***@***.***> wrote: Hi! No, there is no such capability in WebAuthn. There is no unique identifier1 <#m_6021912288726526662_user-content-fn-1-61c1821f4c6879bdc680b238f3e5651e> since that would enable tracking, and there is no API to probe for whether any credential already exists. For an extended discussion of why, see: w3c/webauthn#1915 <w3c/webauthn#1915> . What you can do is use excludeCredentials <https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-excludecredentials> to prevent creating multiple credentials for the *same account* on an authenticator. The RelyingParty.startRegistration() <https://developers.yubico.com/java-webauthn-server/JavaDoc/webauthn-server-core/2.5.1/com/yubico/webauthn/RelyingParty.html#startRegistration(com.yubico.webauthn.StartRegistrationOptions)> method sets excludeCredentials automatically by querying the CredentialRepository <https://developers.yubico.com/java-webauthn-server/JavaDoc/webauthn-server-core/2.5.1/com/yubico/webauthn/CredentialRepository.html#getCredentialIdsForUsername(java.lang.String)>. In theory you could set excludeCredentials to include *all* credentials in all accounts, but this obviously doesn't scale if there are more than maybe 20-50 accounts in your service - certainly not if there are thousands. Depending on what you want to accomplish, you might be able to use conditional UI <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI> instead. This enables discoverable credentials (passkeys) to show up as autofill options in a text field (typically a username or password field) instead of interrupting the UI with the modal WebAuthn popup. If the user selects a passkey from the autofill options, then that passkey is used to authenticate. If you do this in a registration form, you can guide users to log in if they already have an account instead of creating a new one. A demo of this kind of flow is available on passkey.org . But note that this does not *prevent* registering multiple accounts, it just helps nudge users into a different flow. Does that help? Footnotes 1. Except for enterprise attestation <https://w3c.github.io/webauthn/#dom-attestationconveyancepreference-enterprise>, but that is not available in consumer-grade authenticators. ↩ <#m_6021912288726526662_user-content-fnref-1-61c1821f4c6879bdc680b238f3e5651e> — Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZIPDTGOVUBGKXYG55XB3CTYYBHD3AVCNFSM6AAAAABETKLRYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJUGM4TENRWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>