Comments (8)
What Christiaan means is that the credential ID is chosen by the authenticator, not the RP. The authenticator is the "external system with limited context", not the RP. So if the credential ID is the only identifier the RP can use to look up a credential, then the RP is not in control of that primary lookup index.
from webauthn.
What might the utility be of the client-side userHandle
if the successful verification of an auth response for a given credential ID can be linked back on the backend to the user's ID?
from webauthn.
@MasterKale see #558 (comment) and the answer: #558 (comment) 🙂
from webauthn.
@MasterKale see #558 (comment) and the answer: #558 (comment) 🙂
I'm going to pull those comments into here for sake of readability into conversations from 2017:
Why is the user ID necessary for getAssertion? Even for the single factor use case, isn't it possible for the RP to identify the user from only the credential ID even with no allowCredentials? For example:
- Setup: The RP has an internal table linking credential IDs to public keys and internal user IDs, and the user has previously registered a credential with the RP
- The user initiates an authentication ritual (providing no additional info at this point)
- The RP generates a challenge and sends a PublicKeyCredentialRequest (with no allowCredentials) to the client
- The authenticator chooses a credential and generate an assertion
- The RP receives the PublicKeyCredential with an AuthenticatorAssertionResponse containing a credential ID and a signature by that credential
- The RP looks up the public key from its table using the credential ID and verifies the challenge signature
- If (6) fails, the RP asks the user to try again with a different credential
- If (6) succeeds, the RP looks up the user ID from its table using the credential ID and initiates an authenticated session for that user
Shouldn't that work?
And @christiaanbrand's response:
It's a bad idea to have some external system with limited context responsible for generating unique indices for a database. We really need to key off something we control, not the authenticator.
I'm not sure I understand Christiaan's response, is the "external system with limited context" the RP's back end? I don't get how it would have "limited context" here, it's the one with the source of truth as to which credentials belong to which users. The mention of "generating unique indices" in particular doesn't make sense to me since we're talking auth, after the RP has generated the various DB indices and user ID's.
from webauthn.
Adding non-null constraints for userHandle
when allowCredentials is empty is not sufficient. As far as I remember, Safari sometimes returns empty string for userHandle
. This breaks some implementation since the server checks userHandle
nullity and if it is not null, the server tries to compare the given userHandle
and the identified user id from the database.
So, I think it would be better to explicitly indicate that userHandle
is not zero-length if the allowCredential is empty.
Also, there are some descriptions about the requirements.
A user handle is an identifier for a user account, specified by the Relying Party as user.id during registration. Discoverable credentials store this identifier and return it as response.userHandle in authentication ceremonies started with an empty allowCredentials argument.
from webauthn.
What Christiaan means is that the credential ID is chosen by the authenticator, not the RP. The authenticator is the "external system with limited context", not the RP. So if the credential ID is the only identifier the RP can use to look up a credential, then the RP is not in control of that primary lookup index.
I still don't get what exactly the problem is. Regardless of how you look up the credential record, you have to verify credentialId. I would argue that look up by credentialId, which is unique, is better from the performance perspective.
Although RP doesn't generate credentialId, it inserts it in its database and checks the integrity. It has the ultimate say about credentialId and the credential record. From that perspective it is "in control of that primary lookup index".
from webauthn.
primary lookup index is often bound to a specific format; say a UUID. And you can't choose what the credential id format is. Especially in NoSQL databases like Cassandra or DynamoDB where the generation for the IDs need to be tightly controlled such that partitions don't create hotspots having an external system be able to generate IDs for your is bound to cause trouble.
from webauthn.
@arianvp also notes in #1909 (comment) :
The spec also says:
Discoverable credentials store this identifier and return it as response.userHandle in authentication ceremonies started with an empty allowCredentials argument.
Which kind of implies that a Discoverable credential should return
userHandle
It makes sense that it is non-required in the
authenticatorAssertionResponse
as non-discoverable credentials can not return auserHandle
We can make the spec more clear maybe. But I think "Discoverable Credentials return
userHandle
whenallowedCredentials
is empty" is something that the spec currently (kind of in a round-about way) mandates
So it looks like there's a slight mismatch between the User Handle definition (which says it's required) and the formal authenticatorGetAssertion algorithm (which doesn't explicitly say it's required).
from webauthn.
Related Issues (20)
- Extensions should specify partial dictionaries that modify AuthenticationExtensionsClient{Inputs, Outputs}JSON
- The bike shed build is broken with the newest version
- Provide a way for Web Extensions to hook into browser's Passkey autofill UI HOT 4
- Remove the [SameObject] attribute from PublicKeyCredential::authenticatorAttachment HOT 1
- Are notes in webauthn normative or informative? HOT 1
- Ambiguous instructions in the Android Key Attestation Statement Format verification procedure HOT 6
- Spec is not specific enough about order of conditional UI autofill tokens HOT 1
- create() and get() return an algorithm, not a credential HOT 1
- Virtual Authenticator API does not expose a way to set backup-eligible or backup-status flags HOT 9
- Deprecation warning for fido-u2f, apple, and android-safetynet? HOT 6
- > HOT 1
- Inconsistent Passkey Authentication in Google Chrome HOT 5
- rp.name, user.name and user.displayName length limit does not state binary encoding HOT 2
- How is an RP to know if a packed attestation root certificate is used for multiple authenticator models? HOT 2
- Wrong type of encrypted content specified for credentialId under "Credential Storage Modality" section HOT 1
- Cambios por abuso HOT 2
- Consider replacing "Github" with "GitHub" HOT 2
- Conditional UI support by WebAuthn WebDriver Extension HOT 2
- Refine JSON serialization to use UTF-8 encoding for `user.id` and `userHandle` HOT 10
- Clarify usage of credentialRecord.transports HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webauthn.