Re: [GNAP] Support of FIDO
Denis <denis.ietf@free.fr> Fri, 14 August 2020 13:14 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058253A10F0 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAUgYS2eHLDq for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:14:43 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4833A10EC for <txauth@ietf.org>; Fri, 14 Aug 2020 06:14:42 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d66 with ME id FREf230042bcEcA03REfFc; Fri, 14 Aug 2020 15:14:40 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 14 Aug 2020 15:14:40 +0200
X-ME-IP: 90.79.51.120
To: Mike Varley <mike.varley@securekey.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr> <CAD9ie-vbCKvEjtFEPguJmBNVRLZQTPLydjvjaFhkQAhNn3=_pw@mail.gmail.com> <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr> <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <df1ac60f-94ca-88ba-b0ef-ee070d985a0a@free.fr>
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: <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com>
Content-Type: multipart/alternative; boundary="------------105B4C19080E0A5385E09546"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/uYuc30BZZlKkrXKBTrxQw3BUKR4>
Subject: Re: [GNAP] Support of FIDO
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2020 13:14:45 -0000
Mike, Please open a new thread if you want to discuss this topic as it is unrelated to FIDO. Denis > 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: > > https://github.com/ietf-wg-gnap/general/wiki/Client-can-AuthN-End-User > > MV > > *From: *TXAuth <txauth-bounces@ietf.org> on behalf of Denis > <denis.ietf@free.fr> > *Date: *Friday, August 14, 2020 at 6:05 AM > *To: *Dick Hardt <dick.hardt@gmail.com> > *Cc: *"txauth@ietf.org" <txauth@ietf.org> > *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 <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 > > 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. >
- Re: [GNAP] Support of FIDO Denis
- [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO Dick Hardt
- Re: [GNAP] Support of FIDO nadalin
- Re: [GNAP] Support of FIDO nadalin
- Re: [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO Mike Varley
- Re: [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO Steinar Noem
- Re: [GNAP] Support of FIDO nadalin
- Re: [GNAP] Support of FIDO nadalin
- Re: [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO David
- Re: [GNAP] Support of FIDO nadalin
- Re: [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO Denis
- Re: [GNAP] Support of FIDO Steinar Noem
- Re: [GNAP] Support of FIDO David Waite