Re: [webauthn] WebAPI: FIDO Authenticator model - clarifications needed

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

-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/12#issuecomment-254382204 using
 your GitHub account

Received on Tuesday, 18 October 2016 01:33:19 UTC