-
Notifications
You must be signed in to change notification settings - Fork 180
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
Add clearer definition of API use cases to the spec #334
Comments
There is the case where Web Authentication will be used as the second factor, case for AWS SIGV2 where the user has logged in with SIGV2 and this SIGV2 authentication token needs to be bound to the second factor FIDO authentication, this is much like how PKI may be bound to Web Authentication |
Terminology. At this time positively identify user and device doesn't need to be positively identifyable are both used. I think we should always use a) as the authenticator positively identifies the user (or positively identifying authenticator). It is not that the device is not positively identifiable in some cases (so b is misleading IMHO). |
further terminology issues: We already have a term, roaming authenticator, for "portable" authnr. We already have a term, user verification, for what the above is terming (in @rlin1's parlance) "the authenticator positively identifies the user", i.e., we should say "the authenticator performs user verification". |
It seems to be: The RP can call getAssertion without CredentialID, but in makeCredential the RP cannot filter the authenticators to the ones suporting it. |
Seems to be 3 canonical characteristics:
for 1 only a limited memory space is required (e.g. store a PIN). For 3 the authenticator needs such. |
Let me also add some thoughts on user journeys as we're approaching the AMS plenary (where I'm hoping we can chat more about all of this): Re-Authentication During credential creation, the RP will explicitly ask for a UV=true, X-Plat=false authenticator, but note that the platform may, at its discretion, return an authenticator which is built-in, but also accessible from other devices. For this use case to work properly, RPs should tag the specific session on this device with the credentialId, so that only the valid, local credentialId is passed in on subsequent get requests. Bootstrapping Strictly non-Cross-Platform c) Using removable authenticator cross-platform (bootstrap) Note that when creating this credential as X-Plat=true, it might still be physically built in to a platform. It should just also be accessible remotely and will be indicated as such in the transports. d) Typeless bootstrapping To create this type of credential, X-Plat=true and UV=true is sent during credential creation. This flow today is restricted to wired authenticators: we’re not sure how to do this yet for wireless (without requiring system pairing). Summary Improving security |
@christiaanbrand Please review, if no longer needed we will close |
see also pr #956 |
Just to be clear: I don't quite care whether this goes into the main spec, or into an accompanying "implementation considerations" (editorial) doc. I actually think the latter might be better, as it could evolve more rapidly. |
see also the closed PR #1300 |
see also issue #1389
potentially addressed by PR #1300
@christiaanbrand's #334 (comment) is a build on the original post below:
The current use case section of the API has two main sections: registration and authentication. However, in reality, the API can be used for a number of means and uncertainty has led to confusion among developers we talked to. A clear definition would help us in guiding our work and give developers clear idea of what the API can do. I think the list below seems like a good starting point:
Two factor - first login (bootstrap)
Two factor - always
Password-less Re-auth
Password-free accounts, first login (bootstrap)
Sign in without user name
*: An example of a portable device would be a use key or a phone that the user can carry around and use to logs in to any place. An example of a built-in authenticator would be Windows Hello or Android fingerprint scanner. This is not to say they are always going to be entirely different devices.
**: There seems to be two category of devices: devices that can identify users through biometric means, such as fingerprint scanner, and devices that can’t, such as a number of Yubikeys that use the click of a physical button as confirmation of user intent without additional identification means. For now, I call devices of the former category as devices that are positively identifiable and the latter as devices that aren’t.
The text was updated successfully, but these errors were encountered: