From nobody Thu Aug 13 11:27:34 2020 Return-Path: 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 ; 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 ; 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 ; 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: To: "'Dick Hardt'" , "'Denis'" Cc: References: In-Reply-To: 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: Subject: Re: [GNAP] Support of FIDO X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:27:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_019C_01D67164.B85A6B10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable * Having said that, the Client could optionally use FIDO to authenticate = the User and somehow transmit that to the AS. =20 Agree, this can be done now, we are also looking at some delegation = mechanisms in WebAuthn to accomplish this=20 =20 From: TXAuth On Behalf Of Dick Hardt Sent: Thursday, August 13, 2020 11:21 AM To: Denis Cc: txauth@ietf.org Subject: Re: [GNAP] Support of FIDO =20 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. =20 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. =20 Having said that, the Client could optionally use FIDO to authenticate = the User and somehow transmit that to the AS. =20 = = =E1=90=A7 =20 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,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 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. =20 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)=20 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=20 (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.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible. =20 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 --=20 TXAuth mailing list TXAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/txauth ------=_NextPart_000_019C_01D67164.B85A6B10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
  • 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.

 

=E1= =90=A7

 

On = Thu, Aug 13, 2020 at 10:31 AM Denis <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
https://www.ietf.org/mailman/listinfo/txauth

------=_NextPart_000_019C_01D67164.B85A6B10--