Re: [GNAP] Support of FIDO

Mike Varley <mike.varley@securekey.com> Fri, 14 August 2020 13:05 UTC

Return-Path: <mike.varley@securekey.com>
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 054383A10B3 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securekeytechnologies.onmicrosoft.com
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 iJhQR7D4a93T for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:05:00 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670107.outbound.protection.outlook.com [40.107.67.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEBC3A10B1 for <txauth@ietf.org>; Fri, 14 Aug 2020 06:05:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gFh52Eq3jB7ysgmUxCbrI2Sq19Cup9ZrUeY7rByYJy/icQKxkjOrZB3foyXlDqu88TLsp660jE4oP02caOalz42/rxf7NCsj82UWYUF5fLfKB3BffmtFEl41+o5ER7rO/50nYzWFlPj1UYnCiFS+gThNkaRculTTX+t5iru9Xahoh9ltlr7kkuPV6X/p9NwRTUDd83OVikQh1oChL6IA7fry1VUD6NF45PcNujAvOCiphvDLznXScSdoxAiOVjW12NaUTYpKYaj36OZNXI7cvTMDmKfhETFtcuC8JNOmAczX+IsXMSXOTeb+sQbNBxvEGDBbRHngbQ6B72BZ8zzJvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogC7VO4JX70qBoHG+npoDFQVFsW+aDlJyn85XL179/Y=; b=fte283M6toxGcsr1WpGu45ik60RekHWu26pEZYp/wdH2gVklzCSWI1rrIpLBaaAaFdV7MVFpKBQRorpVl7S6x0jkq2rd7OZ36oK7dBenTRXJFvNlbEDaj/su+HmUSWNttkXr7dxR/v3mWN6stMJ/W+JN34UGy6RtXw9Qn+MAR/g5pFlUp/H7xUjl5lUc7dbH5RwiCs2+6CkHZ7pdwQzbAd/fSrwsa3iHoyrEYzB610v+NS1CR9XIiFXPtPODKDDMyJUbut+t1+5gxy7qdiiBqfcRyros+tzlXaC0Wl57RkS+k+gLoTKH+SjDXBsrCjdoMZoc2KeDXiPex2SdVh7OWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogC7VO4JX70qBoHG+npoDFQVFsW+aDlJyn85XL179/Y=; b=VrjWCAfO3ikQ5L9VglIg00zMSSCGmLdc1kR6gQmTnVkX6KF9hdKHHiaQCNzYSi3mVfcjJRfasHznmpHVsBmHMjai3FNd2EJ65HJ/PO41uizxA0XzMTpHb0t9IOc8HcRfdFyst25ozsKKeFnwwb5ynjYOnhQz0Bwa7xAP91Iboc0=
Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8::32) by YTOPR0101MB1964.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:24::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Fri, 14 Aug 2020 13:04:52 +0000
Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::1cba:f8fa:84c4:a7ca]) by YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::1cba:f8fa:84c4:a7ca%7]) with mapi id 15.20.3261.025; Fri, 14 Aug 2020 13:04:52 +0000
From: Mike Varley <mike.varley@securekey.com>
To: Denis <denis.ietf@free.fr>, Dick Hardt <dick.hardt@gmail.com>
CC: "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: [GNAP] Support of FIDO
Thread-Index: AQHWcZeY9Pi2SFii40OWoJUpH3eW6Kk2Wd8AgAEH4oD//+7+AA==
Date: Fri, 14 Aug 2020 13:04:52 +0000
Message-ID: <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com>
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr> <CAD9ie-vbCKvEjtFEPguJmBNVRLZQTPLydjvjaFhkQAhNn3=_pw@mail.gmail.com> <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr>
In-Reply-To: <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=securekey.com;
x-originating-ip: [64.231.235.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 38f15b42-ea20-4b80-9901-08d84052a254
x-ms-traffictypediagnostic: YTOPR0101MB1964:
x-microsoft-antispam-prvs: <YTOPR0101MB19645211C25A0B7171A63442E4400@YTOPR0101MB1964.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:1247;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4HK3qUD5iPOVvNDbCSicmke+w7AtTJ613gczmWeP07NNXMYl5vpZ5UdMoOA7ssID8usSqpPhpTp19QkQtDgr4HCDtky7izF6qJG8IpUoZS52/fVA1oXeDBGP2ktdBoxyUVcgzhgQz5cV3anbILxt8k4qw2v4cdFz6Nn7MUqgPgzBzJQgtllNZOm+2on38qGVKHyEzX+VdhE5lqSq2SFoQM9SdvMbSphx0wrz8523uDzD2M1NvC5+YyMml6CZdOuGDFS4WToGb5Y91jMxZcbQLJUiLExg2tHA2JaN19d5EG8YM9kwyrCjIvUJOuQ3Hwgo6WHRCi9Hqq/d21aA1SCvshGZvRMmINcDKnOo0gBCoEHqKkxXD9eYd42BxVoKlbIzlstQ/bjK9/8S8jeLKr4m2AxSyyWaOZl+4fUXoMzatncr9v91u4YFlqk5lv7vUovyy+8i29eyHUPrKuyHIFKq9Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(136003)(39850400004)(366004)(8676002)(83380400001)(44832011)(2616005)(8936002)(166002)(26005)(6486002)(86362001)(186003)(478600001)(36756003)(6506007)(53546011)(5660300002)(110136005)(33656002)(316002)(2906002)(6512007)(64756008)(66446008)(66476007)(66556008)(4326008)(71200400001)(76116006)(966005)(66946007)(15866825006); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xR2LVJjNsITUz09SuhcwGwpnfTld1qtbahJI15shocOsFtMqpHAN0RYPcXqEBCVJt7/soj/PmmZffkafe+RRmVPB6mTx1nmvMumITAdzWjsxIz2C4UwgYIrwfH/suqo/W6E98C219NfhvXOjkP9AZSBBtNXeseT+PTV0PkmUvsecAIYIsDv+ECTT84iwuvytskRh9IjVgkCb8bGZjJoxQYBk332fOQGzQoKfvU71p1sY/PhPurnDEZOKfpQ22OOjTYvNNoWGLBRLbS3q7keckzm8jwt+bXw0NqIWlfxgi9lDsrF1Q4fOhQSpydsARnbC9g/lJiewymmAiXinf3opiEldMWmmSullBV4cOPf0zTEOyedYzwUiL/Je+BGruIb1qlv7ntUxzQw+01zeaNgS0bd3t97JV8x2r7ETt49xrD8AKmbaX98eY40Fwu2KasTag+d7PHB0wgJudhKSRqD59NHdqW/ljCKLYap8pnDStiiUqf+Xhsy3OAOIi0boVWXz9epaa2LImT2VpgmrDZs6rj52xyKlijKX+5oNynXEAqdd+Y5fQIOLQoQoekln8IYUW1jF5asoFUMCyOYPl1PScCOc44TZv0wHIcjmwVsPCfNclrE3GkvX5JhfHPiE+8QW0sBsV2JtZk05FeaqleCFEQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_75441F90C6A54BADB49EF4FCC2DE55C9securekeycom_"
MIME-Version: 1.0
X-OriginatorOrg: securekey.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 38f15b42-ea20-4b80-9901-08d84052a254
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 13:04:52.7084 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /bTpNPkNwdTAsVAbLZfKnAz6VaSlGFeNfSOtp1FKtW/ja5VQI3DaPbLDF/PR/iOHHB5VGmlMHM5/uILQt1gi9EyoGEe3mqQh5yz67W7WTlk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1964
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nXtATY9XYY2fxxzeoVgt-yEVju0>
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:05:03 -0000

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.