Re: [GNAP] Support of FIDO

Denis <> Fri, 14 August 2020 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 058253A10F0 for <>; Fri, 14 Aug 2020 06:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bAUgYS2eHLDq for <>; Fri, 14 Aug 2020 06:14:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F4833A10EC for <>; Fri, 14 Aug 2020 06:14:42 -0700 (PDT)
Received: from [] ([]) by mwinf5d66 with ME id FREf230042bcEcA03REfFc; Fri, 14 Aug 2020 15:14:40 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 14 Aug 2020 15:14:40 +0200
To: Mike Varley <>
Cc: "" <>
References: <> <> <> <>
From: Denis <>
Message-ID: <>
Date: Fri, 14 Aug 2020 15:14:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------105B4C19080E0A5385E09546"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [GNAP] Support of FIDO
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Aug 2020 13:14:45 -0000


Please open a new thread if you want to discuss this topic as it is 
unrelated to FIDO.


> I think allowing a trusted Client to authN the end user and have the 
> AS trust that authentication is an important feature, especially for 
> mobile client or in the example of FIDO/WebAuthN.
> I have captured the use case here:
> MV
> *From: *TXAuth <> on behalf of Denis 
> <>
> *Date: *Friday, August 14, 2020 at 6:05 AM
> *To: *Dick Hardt <>
> *Cc: *"" <>
> *Subject: *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
>     Image removed by sender.ᐧ
>     On Thu, Aug 13, 2020 at 10:31 AM Denis <
>     <>> 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
> <>
> This email and any attachments are for the sole use of the intended 
> recipients and may be privileged, confidential or otherwise exempt 
> from disclosure under law. Any distribution, printing or other use by 
> anyone other than the intended recipient is prohibited. If you are not 
> an intended recipient, please contact the sender immediately, and 
> permanently delete this email and its attachments.