Comments (4)
@smachani1 wrote:
webauthn Authenticator model You may want to explain and/or clarify in this section if:
a) More than 1 webauthn credentials on the same authenticator can be associated with a single account at the Relying party? e.g. a privileged shared account that is accessed from the same desktop station with an embedded webauthn authenticator. Each one of the users of the shared account may use their own Biometric gestures to unlock their own credential for identification.
I think the combination of makeCredential()'s excludeList
and getAssertion()'s allowList
address this use case -- i.e., the RP would not use excludeList
at registration time, thus allowing for the creation of multiple creds mapped to the same accountInformation.id
value.
However, there apparently is no guarantee that multiple creds mapped to the same accountInformation.id
would be presented at getAssertion() time, even if listed in the allowList
-- see second subbullet under first bullet near beginning of {#makeCredential}.
b) One webauthn credential can be associated with more than one user accounts with the same Relying Party?
I believe the answer is "no", because the authenticatorMakeCredential operation generates a new credential by default and does not re-use any other credential data associated with the given RP ID hash that already exists on the authenticator.
If not and a webauthn credential must be unique per-user account/identity per-RP then it needs to be stated.
Hm, perhaps we can illustrate these cred-to-account mapping permutation possibilities in a table...
c) A user could register more than one authenticator (a mix of embedded and external authenticator) with the same Relying party and associated with the same user account?
Yes -- that is up to the RP to manage.
d) Cloned webauthn credentials are allowed? I assume not, but how would the RP ensure that the webauthn credential is bound to one authenticator?
detecting and handling cloned credentials (e.g., purloined credential private keys) is up to the RPs. sudden odd changes in the returned value of the signature counter may help with this. of course RPs can bring other client-recognizing techniques to bear, such as an absence or change in the cookies they have set on the client system.
conclusion: I think we can close this other than perhaps figuring out a way to depict the various cred-to-account mapping permutation possibilities.
from webauthn.
Isn't (b) implied already by the various flows? For instance the processing step that was cited in #234 requires the RP to be able to look up an account/identity using a credential ID. There is no way to do this unambiguously if you allow a single credential ID to map to multiple accounts.
That said, I don't see why this is a requirement of the API. If an RP wants to do this and make their own life difficult, more power to them. Maybe they are going to use it as a way to provide redundancy between two equivalent accounts, I don't know. If we say nothing more on this topic, what would be the harm?
from webauthn.
@vijaybh wrote:
Isn't (b) implied already by the various flows? For instance the processing step that was cited in #234 requires the RP to be able to look up an account/identity using a credential ID. There is no way to do this unambiguously if you allow a single credential ID to map to multiple accounts.
sure, tho note that that processing step is just an example of how an RP might structure their use of the webauthn api.
That said, I don't see why this is a requirement of the API. If an RP wants to do this and make their own life difficult, more power to them. Maybe they are going to use it as a way to provide redundancy between two equivalent accounts, I don't know. If we say nothing more on this topic, what would be the harm?
I suspect what @smachani1 was originally soliciting is more "implementation guidance" wrt the various possibilities of cred-to-account mapping permutations.
I'll leave open, add to the set of "impl considerations" issues, and punt this to CR milestone for now.
from webauthn.
this is relevant to "relying party deployment considerations" (nee implementation considerations)
from webauthn.
Related Issues (20)
- Proposal for password-only authentication using ES256 HOT 10
- [[Create]] should not access the global object directly HOT 1
- Define `TypeError` behavior during `.get()` HOT 3
- Return more nuanced errors HOT 3
- Does Related Origins introduce a need for "Related RP IDs" support in `.get()`? HOT 1
- UTF-8 decode should not be required for response.clientDataJSON and cData HOT 2
- CollectedClientData fields are not ordered correctly and crossOrigin should be required HOT 3
- Add `topOrigin` to the limited verification algorithm HOT 2
- Use URI instead of URL for related origins HOT 2
- Add `publicKey` and `publicKeyAlgorithm` to `AuthenticatorAssertionResponseJSON` HOT 3
- Make `AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` optional HOT 2
- Rename PublicKeyCredentialHints to PublicKeyCredentialHint? HOT 1
- CollectedClientData.crossOrigin not referenced in RP ops HOT 1
- Cross-window `Virtual Authenticator Database` HOT 2
- Make `Credential.id` a `DOMString` HOT 2
- Remove `RegistrationResponseJSON.id` and `AuthenticationResponseJSON.id` HOT 10
- Remove rp.name HOT 3
- `options.mediation` should be called something else in step 14 of Registering a New Credential HOT 2
- Add `mediation` to `PublicKeyCredentialJSON` HOT 2
- Add links where non-members can make patent licensing committments to `CONTRIBUTING.md` HOT 1
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.