Re: [GNAP] Support of FIDO
nadalin@prodigy.net Fri, 14 August 2020 14:15 UTC
Return-Path: <nadalin@prodigy.net>
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 4BD383A112F for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=prodigy.net
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 PUE7ZU_GH-GY for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:15:06 -0700 (PDT)
Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DB83A0C5E for <txauth@ietf.org>; Fri, 14 Aug 2020 07:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597414505; bh=kBSEtcoyS3Xoy9t5c1mVzGEGjE4HWjkveK+BUiNGuTU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject; b=VpZr1cmimNr9DOrbdWl5AgutMqQJU5qcCI2tXEuhxQEghzj6OOBTOOvcFxj1pN7fZrniqx01oaqH5dWHDbGBsc8PcRKY9b8yOcJwdp3dOjJI1Gia2nxluAT0clGP8iHORQGc//kFaPIx/6n75JCyhhKzmlRhKpg+qkM+Xo6SDwLyT1S78X752/5pe9zXRn8EJHXFb2nFeNwsSosGxyEeol+ztnNOOpofAAsuuVgBKiFIzLOz7xhx6cacjYMVjTzNS4BylHLUgQmvC2SUGsIXA0P2FiV3Lg8NgdKCDFlwtHW1C4anCyGAGuENWtdtRPkbxRViCFGt4yhBQXmVr3bouA==
X-YMail-OSG: G2q0ddIVM1nW2HR1QgnOTtdlhBU95pKFoujDU6_IS72DmfoJLosaKdbR2Mlh9Bk DxrijoX_CV3C1BC3fmcwQm0q.Kzmip0lhjuSVWN.SzVrft0iOecDNmdOTVyQeopE695tIcRljpHK 291CR8CfMa7FH6CoGGqaszhMb1NXX5Opz3CVjmdA7rmcMPPYIOBW1E2dJaD9ul4q9SI2VmXAsCMY huTqY8QlA8J2hU8GlOkBoc5iXeOIY5lDPxvKRpzBugk1NWdKRlnNG1_fJDjTmHqlCBjXuOFfmG5t 14Hg7_1nThh056kOk3TSFa3nMK0FCHc80K1jeRVaQjbV5fL48BhMAvwZoaJiogj1mhRGTpI8ut1E sqQqIjSKcx5ykz9gLagM2WgfsOyoSBl.F5Lj6O4YOBllqVII6rYmhPpTpxIArskroFMh8C88qq9n qx_tgr7DNzRMx86WpO2HHkXKuBcG2N0KSnVjY5s7wF.ykGZR_YOH4uVTmff58XbaS95miWe3hxWz WvU3xCufLfvVgSWDqwh67pPI9kxzvub8ZiLadH75TxStoo4VVdK7KgZgkSvx9XOutTWYayJnp1Dn xaWvJ5P6NAgDkOMifxsWuqpmp3ZjDkc_KFqX2ePCROULcnlbbqohKnBMambDYmCkP9kWvq1BMiUM Y3wW91mdb5GaDOQjN.e1cvLxCWpSiklJVYrnkyPVAitLqBuEGVcH4RcaG5sk8qAChr79AmK_XCMA RQgobO5yIGmmqAl68URirX6rVa6H0pAbV.VtBQc2rLPxDreZqmVq2enVFTeWtmxNaMJLRsSP4iUp hMCZZcS7PKqzdC2A029xYD_EH1_10HwqgRtgktz7DE5FijJD3r7Vw6KAwDusuGxCkmbkvhltlZQ1 REczFjsRcIUpDfxyfFZ2yvqsgn7gPaSl.6JlshR3TbDxN4OcXFaNFSbrFqFAwJmOT40uXIyyaULK WHAvKmJt2GEgpwWKBuIRLRli0rk8mFu9Q3wxWU5YWSiulSuLtcVi1BFW6xJmxYLiRLkvvpketpA9 88C75hCQavPY0hsdZ34sz3P9D44bpKxiHdqIeTRG5nGuT9TzaptsBkydNtwYeUtWPDsONuShvmhs eV.o7qgichl1MNgwZv1pcO4FLDABZwtE1t1eBOFk4KVJTICtqnbKQk_woxqtvD45ouWxeyEXeSTb x.8htVX2q_bW6_c9gKM0G4Gggqa4E1PQjalXOTsMqSPTz4MoEkScDsUCa0GxIh5jGTNPtE74bhKk YlWA4bFki.rOuMD0500OyAqG561SJduzdh24zBy6YagtS1BQDnTYzVr35IGDzGKF_5rWDHE07jg_ vuphq1p.M0kI_0iFwJ40MAS6Kn2tf1OwPFKk87r8i_4PDqA7bjWvHQpyTPXNJf3TQbOIvn4EgtfG PeOmlIncDNzOqWLbBjLzJfDu0xS0qnUGrHtWRs_3bprs7nKyOyYiNXearw57xKCyWKVTTuVVXd8o 2.pSijS31c7qdXQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 14 Aug 2020 14:15:05 +0000
Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ce8af68f0e3c19c33fc7ee939b1bfb4; Fri, 14 Aug 2020 14:15:00 +0000 (UTC)
From: nadalin@prodigy.net
To: 'Steinar Noem' <steinar@udelt.no>, 'Denis' <denis.ietf@free.fr>
Cc: txauth@ietf.org
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr> <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <CAHsNOKeqMhnL639v3DrfL9mG6Tsjunk8tq5QSV513ECRHVVyhA@mail.gmail.com>
In-Reply-To: <CAHsNOKeqMhnL639v3DrfL9mG6Tsjunk8tq5QSV513ECRHVVyhA@mail.gmail.com>
Date: Fri, 14 Aug 2020 07:14:58 -0700
Message-ID: <014601d67245$4b4066b0$e1c13410$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01D6720A.9EE22AF0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6cCNKqjJKlKPBFA
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BTlEcoSmJM3fSi20hu0vBiZheks>
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 14:15:08 -0000
Correct U2F is not passwordless like FIDO2 or UAF From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Steinar Noem Sent: Friday, August 14, 2020 6:24 AM To: Denis <denis.ietf@free.fr> Cc: txauth@ietf.org; nadalin@prodigy.net Subject: Re: [GNAP] Support of FIDO Hi Denis, I have always perceived U2F (which I think has been replaced by FIDO2/CTAP/WebAuthn) as just a pure second factor and not an authentication in itself. I may be wrong, but from my understanding U2F makes sense in combination with user authentication, but not as a stand-alone solution. <mvh>Steinar</mvh> fre. 14. aug. 2020 kl. 12:04 skrev Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr> >: 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 <mailto:txauth-bounces@ietf.org> <txauth-bounces@ietf.org> On Behalf Of Denis Sent: Thursday, August 13, 2020 10:31 AM To: txauth@ietf.org <mailto:txauth@ietf.org> 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 -- TXAuth mailing list TXAuth@ietf.org <mailto:TXAuth@ietf.org> https://www.ietf.org/mailman/listinfo/txauth -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | <mailto:steinar@udelt.no> steinar@udelt.no | <mailto:hei@udelt.no> hei@udelt.no | +47 955 21 620 | <http://www.udelt.no/> www.udelt.no |
- 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