WebAPI: FIDO Authenticator model - clarifications needed about webauthn

[equalsJeffH]

@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.

[vijaybh]

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?

[equalsJeffH]

@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.

[equalsJeffH]

this is relevant to "relying party deployment considerations" (nee implementation considerations)