Re: [GNAP] Support of FIDO

[Denis <[e-mail]>]

Hi Tony,
>
> Not quite Dennis, the U2F device does not store the private key, it 
> only creates the private key.
>
Please read the Client to Authenticator Protocol (CTAP) specification 
from the FIDO Alliance:

https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf

Extract:

      (...) the ASPSP  (Account Servicing Payment Service Providers)
    server sends a challenge message to the authenticator
    which is then cryptographically signed by a *private key stored in
    the authenticator.*

Denis

> *From:* TXAuth <[e-mail]> *On Behalf Of *Denis
> *Sent:* Friday, August 14, 2020 3:04 AM
> *To:* [e-mail]; [e-mail]
> *Subject:* Re: [GNAP] Support of FIDO
>
> 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]>
>     <mailto:[e-mail]> *On Behalf Of *Denis
>     *Sent:* Thursday, August 13, 2020 10:31 AM
>     *To:* [e-mail] <mailto:[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
>