Re: [GNAP] Support of FIDO

[Denis <[e-mail]>]

Hi Tony,
>
> Dennis, not all the way correct
>
>   * It is also possible to get rid of IDs and passwords using FIDO.
>     FIDO discloses no private information at all about the user
>     and no trust relationships need to be defined since there is no AS
>
> Depends on if you only consider “private information” PII, there can 
> be all sorts of information passed in ClientData field of the FIDO 
> response, not desirable but perfectly OK
>
>   * None of these two semantics fit with the FIDO use case where the
>     subject value is scoped to be locally unique in the context of one
>     RS.
>     Hence, the linkage of users between two RSs (or between one RS and
>     any other server) becomes impossible
>
> There is nothing that prohibits the RS from sharing registration 
> information between RS
>
I am speaking of FIDO U2F where there are two main phases: registration 
and authentication.

    The U2F device gives the public key and a Key Handle to the origin
    online service or website during the user registration step.
    Later, when the user performs an authentication, the origin online
    service or website sends the Key Handle back to the U2F device
    via the browser. The U2F device uses the Key Handle to identify the
    user's private key, and creates a signature which is sent back
    to the origin to verify the presence of the U2F device. Thus, the
    Key Handle is simply an identifier of a particular key on the U2F
    device.

There is no other registration information needed. Sharing such an 
information between RSs does not allow to link user accounts.

Denis

> *From:* TXAuth <[e-mail]> *On Behalf Of *Denis
> *Sent:* Thursday, August 13, 2020 10:31 AM
> *To:* [e-mail]
> *Subject:* [GNAP] Support of FIDO
>
> This topic has already been tackled on the list, but I open a new 
> thread for it.
>
> In OAuth 2.0, one of the goals was to get rid of IDs and passwords. 
> Since the solution in OAuth 2.0 was to use access tokens,
> there have been used everywhere, even when they were not strictly needed.
>
> It is also possible to get rid of IDs and passwords using FIDO. FIDO 
> discloses no private information at all about the user
> and no trust relationships need to be defined since there is no AS.
>
> FIDO should be one allowed possibility for the user authentication. In 
> the case of FIDO, the user is authenticated under a pseudonym
> specific to the RS. It may observed that there is no equivalent in 
> OAuth because of the two different semantics of the subject claim.
>
> RFC 7519 states:
>
>     The "sub" (subject) claim identifies the principal that is the
>     subject of the JWT.  The claims in a JWT are normally statements
>     about the subject.
>     The subject value MUST either be scoped to be locally unique in
>     the context of the issuer or be globally unique.
>
> In one case, it is possible to link the subject claim of two users 
> between two RSs (i.e. using a locally unique identifier in the context 
> of the issuer)
> while in the other case (i.e. using a globally unique identifier) it 
> is possible, in addition, to link the subject claim between one RS and 
> any other server
> (i.e. not supporting OAuth) that is using the same globally unique 
> identifier.
>
> None of these two semantics fit with the FIDO use case where the 
> subject value is scoped to be locally unique in the context of one RS.
>
> Hence, the linkage of users between two RSs (or between one RS and any 
> other server) becomes impossible.
>
> There are cases where a user would like to enjoy the unlinkeability 
> properties of FIDO which cannot be met using the claims currently 
> defined in OAuth.
>
> Denis
>