Re: [GNAP] Support of FIDO

nadalin@prodigy.net Thu, 13 August 2020 18:27 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 EA8C43A0F98 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=0.001, 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 8bxeHF-aBaz0 for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:27:31 -0700 (PDT)
Received: from sonic314-19.consmr.mail.bf2.yahoo.com (sonic314-19.consmr.mail.bf2.yahoo.com [74.6.132.193]) (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 F0BE63A0F96 for <txauth@ietf.org>; Thu, 13 Aug 2020 11:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597343248; bh=m0Stcz7kVcXhvcBi5G5dWwJuFL+r/dCB3gNMmgnQBsY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject; b=DLkv5CJR9xLZcv9RSHww+DLi2hgoPP3nrMwbSR6pxm92guRjSyT0ZV1ditSFI0+hk375XfwdQgzRnNZo06gCCCQMBrcWKDOFYknGGuA8pSao929pP4h/95ceSB19Q9JSHRx1OcCfdM86NRTusNeIJFNcBwN2DiR78S3V0NxujyQGMTU9NUDXZoKH3bkPxYPStIZUOJTg/OWvJNk5LRXNnj1W8HzZ81sTTfb6YCeEPfalXMtPPG8tirEB2TAzF1VWgkQUQEXAkqedko8Ml0sVANXavDFpwMyqdGgfEglBy1pWCx76WU72MGXPJwtVFIQtOXA7ZBsbri1lFNncb35uag==
X-YMail-OSG: xyvRa0EVM1mjIBhN.bJ631EZvT60AGFylZkC.xHWykeODsi52fBoEhmloOssVqK K4Fsq5KPJoqlBX10s.rJfm9keHkUMYTJbBXuqbSo5OWOrVQiljWH7L1yXI4ZaqBrcvbZFoKzHJAQ JpPfJT.rldwe5XnUBGs2sBvhTT3QXvASUWzg.qk9nwSlYAC.neQBket_zt4QG9uM_LKpIW2i9ou5 2lfgrrShaR8Wgc3g6Ln.PPfX0th0XSloIHp2fscNBwXT85wbXBJZ9X2GF6zI1oa5xWzPc6gjw08P xWG5RP6g..ghfY66wEQYwy0wZ0CDv7KEXFCu0OnNoY1qg5lRxMwBwj6IWNSp5l3fvNHu5miLpS.7 ecse8qa7qEbP8q6cmcSliRgh3889KudY..87PwGTNFUFOTzgP24Ekw4TwIAreawqRzbs96iKXOet ZfnYQ7144S5Em2GwDTzc69THBFPfjLZeGilfoLfjobhXQLT.7WcUDbihtMhkl7SZ.R7cpJlw_aNd 4U9DpTIbUYQmOBTzydruEamdGru9tZBDhB7hShf3nzGD0ZD8In14uxEEAFxb._LxNlWuE1b0VtdA 9eSMXzW1By6jZqLaRkmzLovRb8O9iWEiFIBTcLomCFKywGhjAple8sVeHWei21pX9c2weBxBcqJu tRgW8PWgM3uHzcNRxHrKz_vQn6G45ebdLAVYiv3I_KTkYXEwWOmaIS1yED.t_wggldaLRg_m6KUx tMHskWT960l5OOHGo.wc9SromjewBloGx_aQQeKbd7p0AJfffYEZcVYjItf22nhfKlAu_znZikEl rZMu_C9QqKMcSLBB4dS85z5KWPRRu1d2eFwKal6jiNw7OPTlHqSg1UV4X264Zy1Xp91YfI541spX b2zz2mYgSAnvx1bwAoAZSCvknrr36wqVTTl3BYlPvhQ_2lI6W4tipCm7GZn7DlHpAS8H3lYUkerR 6kuc9raIJgwVT4AHOrpJncaKMTqxQBMjIj6wijX10ZvposJvVGdm82fej_BQY4G_UlNHqOP9l02i m2wRcRznj5uADzjR6y3FYlxGVXeIKag73fJOWVLp0JiF4_er.NFEeTAPUrk0b0XAl6RT5UR86D2z Fgzln72E5arssRTXatmXNAyTLY4W0RRipGuaDJ3mZTeNut6jMhPpABUU7aMKHD1vtUs9HWKImesR yAw5KZzw4QhlhvKIZBAupp82Dtmk.70OuuIVnqjBrwJwblXSs.BUZme.KXp0sMh_bseeMd0Mkoem Lm7OOIz8AqeQ.nLRY7x8dFKtwbmfXRrwlOQ6RfUJe7H0xA05wTTz.8Bre6gm8yxx7Q.XVdFdGf9e OQpDw1io2smOsFTAvkJw06qqZXx_s3P.WE1rEIS_Ok96nfjWLPZrfyPEpc4K0vQq63C5MzLj2nU6 KkTsGpVpua7RU7sPTNYbbCcf3lYmuCKT3ymPquvWfHYyzMSdCLCPIXKqJpgl90NjP_nX88XXoJLf j0l806x8E9Nu5eRUfCE8P
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 13 Aug 2020 18:27:28 +0000
Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d8e4a64036633f4ad9e4407abe0cdd41; Thu, 13 Aug 2020 18:27:27 +0000 (UTC)
From: <nadalin@prodigy.net>
To: "'Dick Hardt'" <dick.hardt@gmail.com>, "'Denis'" <denis.ietf@free.fr>
Cc: <txauth@ietf.org>
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr> <CAD9ie-vbCKvEjtFEPguJmBNVRLZQTPLydjvjaFhkQAhNn3=_pw@mail.gmail.com>
In-Reply-To: <CAD9ie-vbCKvEjtFEPguJmBNVRLZQTPLydjvjaFhkQAhNn3=_pw@mail.gmail.com>
Date: Thu, 13 Aug 2020 11:27:24 -0700
Message-ID: <019b01d6719f$64b76e50$2e264af0$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_019C_01D67164.B85A6B10"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAKhMFgtqWojPCA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/otI-cb01B6Nc7Pyxxk6XVQyBrcA>
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: Thu, 13 Aug 2020 18:27:33 -0000

*	Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

 

Agree, this can be done now, we are also looking at some delegation mechanisms in WebAuthn to accomplish this 

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Thursday, August 13, 2020 11:21 AM
To: Denis <denis.ietf@free.fr>
Cc: txauth@ietf.org
Subject: Re: [GNAP] Support of FIDO

 

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. 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.

 

  <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=fcbd933e-899b-44eb-a8d8-b2330c4868e7> ᐧ

 

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