Re: [GNAP] Support of FIDO

Hi Dick,

> OAuth 2.0 goal was not to get rid of usernames and passwords. It was 
> to stop site A from asking for the user's username and password at 
> site B so that site A could access resources at site B.
>
> How the AS authenticates the User is out of scope, and I think should 
> be out of scope.

Maybe, may be not. Some means of authentication between a User and an AS 
could be recommended and documented.

However, how the RS authenticates the User should be within the scope.

> There are a plethora of authentication mechanisms, and standardizing 
> how the user authenticates is not required for interop.
> Sharing the "quality" of the authentication is an area of 
> standardization that has been done in OpenID Connect, and I think 
> should be included in GNAP.
>
> Having said that, the Client could optionally use FIDO to authenticate 
> the User and somehow transmit that to the AS.

No. The RS Client could optionally use FIDO to authenticate the User. 
Since FIDO does not mandate any AS, there is no interaction with any AS 
at that stage.

Denis

> ᐧ
>
> On Thu, Aug 13, 2020 at 10:31 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     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
>
>     -- 
>     TXAuth mailing list
>     TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/txauth
>