-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebAPI: FIDO Authenticator model - clarifications needed #12
Comments
@smachani1 wrote:
I think the combination of makeCredential()'s However, there apparently is no guarantee that multiple creds mapped to the same
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.
Hm, perhaps we can illustrate these cred-to-account mapping permutation possibilities in a table...
Yes -- that is up to the RP to manage.
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. |
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? |
@vijaybh wrote:
sure, tho note that that processing step is just an example of how an RP might structure their use of the webauthn api.
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. |
Refactor the attestation section to clean up exposition. Separated out signature verification (per format) from trust chaining (done at higher layer). Created a separate section for specifying key RP operations. Fixes #88. RP registration section defines binding of credentials to user accounts. Fixes #13. RP registration section also defines options in case of registering the same credential to different users. Fixes #12. Cleans up and completes defining the process for verifying assertions, which had already been largely done by @rlin1. Fixes #102. Completes drawing the distinction between assertion and attestation certificates. Fixes #118. Replace "client platform" with "client" in signature format section to avoid confusion. Fixes #209.
this is relevant to "relying party deployment considerations" (nee implementation considerations) |
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.
b) One webauthn credential can be associated with more than one user accounts with the same Relying Party? If so we will have to revisit the registration flow. If not and a webauthn credential must be unique per-user account/identity per-RP then it needs to be stated.
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?
d) Cloned webauthn credentials are allowed? I assume not, but how would the RP ensure that the webauthn credential is bound to one authenticator?
The text was updated successfully, but these errors were encountered: