Nisha,
One design pattern we have successfully employed in FIDO-enabled
web-applications is to have the Application Administrator (or Help Desk
Support) be able to send out unique, time-bound links over e-mail (or
SMS) to users, to register an Authenticator to an account. This can be
easily accomplished with new (for invitation only access) or existing
users (for Account Recovery). This will allow multiple users who don't
know each other to be able to register their unique Authenticators to
the account.
However, you might want to consider how you design the FIDO Key
Management (FKM) on the application, depending on whether the different
users are from the same company (they will be guided by the same
security policy of the company) or are from different companies (your
agreement with those companies/individuals will guide their actions on
the app).
Some considerations you might incorporate into the web-app's FKM page are:
1) To NOT allow them to see all the registered Authenticators within the
account - but just their own (even this can be optional since you may
choose to control disabling Authenticators based on some other policy);
2) To NOT allow them to register additional Authenticators within the
account, unless they receive a link from the Administrator - otherwise,
you'll lose control of the account;
3) Register ONLY biometric-enabled (mandatory user verification)
Authenticators to control (to some extent) sharing of physical
Authenticators - although you really can't prevent it since almost every
biometric Authenticator I've seen enables registering multiple biometric
templates, which need not be from the same person;
4) If you give Application Administrators/Help Desk Support the
privilege to e-mail registration links to users, make sure that you're
authenticating the privileged users also with FIDO (with a similar or
stronger security policy than the users who use those accounts);
otherwise, you'll end up weakening the end-user authentication security
policy with weaker Administrator authentication.
While FIDO protocols permit registering unlimited number of
Authenticators to an account (in theory), this use-case has consequences
on security policy and account management that are likely more
important, IMO.
Arshad Noor
StrongKey
On 7/2/21 2:17 AM, Nisha Vashisht wrote:
> no there is no specific need to differentiate the users. I just require
> that both the users should be allowed to access the same login account.
> We can add the FIDO device, but the authenticating party will be
> different for each user. Like Device 1 is authenticated by UserA and
> Device 2 is authenticated by UserB.
> So, in case of registration, both the users will utilize their own
> devices to register at the service, and it will allow usage of either of
> two devices to login successfully, right ?
>
> On Friday, July 2, 2021 at 1:23:45 PM UTC+5:30 My1 wrote:
>
> Is there a specific need to differentiate between users in an account?
>
> Most sites nowadays already allow you to register multiple FIDO
> devices to have a backup function when one breaks or gets lost, and
> if all users are the same in an account, you can just add the FIDO
> devices as needed, although services might have an upper limit on
> the number of FIDO devices per account.
>
> Regards
>
> My1
>
> Am Fr., 2. Juli 2021 um 09:26 Uhr schrieb Nisha Vashisht
> <
nish...@gmail.com>:
>
> My requirement is that I have a shared account for which I need
> to register more than one user. So it means I need to have
> multiple FIDO2 accounts associated with the same login account
> but each authenticator is valid with different user.
>
> *Example - >*
> The Login site is
xyz.com <
http://xyz.com> and the user
> account name is - JohnA.
>
> Now, User A has a FIDO2 authenticator registered with it, which
> the UserA uses to login into the account - JohnA.
>
> User B also has a different FIDO2 authenticator registered
> against the same account - JohnA, and he/she also uses the
> mentioned authenticator to login into the same account.
>
> So, both users login into the same account JohnA as provided by
> the login site
xyz.com <
http://xyz.com> using the FIDO2 framework.
> <
https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/305a5353-260b-4c5c-8473-49bf1ce6f30bn%40fidoalliance.org?utm_medium=email&utm_source=footer>.