Re: [Txauth] Client Registration (Was: Key handle vs client id & handle

Mike Varley <mike.varley@securekey.com> Wed, 15 July 2020 14:35 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 D00A43A0C13 for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 07:35:44 -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 0LmheoB3HxUU for <txauth@ietfa.amsl.com>; Wed, 15 Jul 2020 07:35:42 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670125.outbound.protection.outlook.com [40.107.67.125]) (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 A1BD33A0DCA for <txauth@ietf.org>; Wed, 15 Jul 2020 07:35:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=awCtqbAesEEtQ17blNi9mYAR0dRUvN2YfaPkqHrHGzDSTtmTfreCvs7ChCqz8Io4IBlwKf6padpiGB2/j+gMnBRf1EblZxPrEcDBUgAohG5XgPmtFAaIVStpjbbz9aemILmeIsXTwuPeuCkUwPa//yD92hbo8MnUKeMHM0OoaDMJnSrIeNt9TVPjrmUjul7aIvmZDRtKJDVrIev9/gz6jouk6gDltlam9PxDLXgENcAAwppZ+E+qCd+PedAsbtMcq/1ZK8BLpG4WWbGtz772XDa56ouSCG0K1dGCU6PIXDU4FysVDrpgHUQUGnyyS/O7hZG/MH/K5/bYEzVVCGyExQ==
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=hzxGUxqKWe9KOmXTaQv5J6jzYhPeLxmmmDsjRCLdY8s=; b=NtgleHTNzDu1x6Xe+/BmC/Y+0EPuHF9wKGs3oMKDolq4py6GeHL1QORYG1QBabP/dQgc5suT/TNSEOsqbILTgH+Ky0q1OeMD5twwy/2/q1inzKbShN8k85EHT7kivApsU34595XZi8Px0ryLe+hj23c92AsDORVABd/JVEqY40fXmpwpZRQdh8OOViWm+/AkCRCu0IZCTn9BHX0jtddC2xDw4ImquJHJgyD9+AVsTzYqxz5t8JBMYewvmdDrM7+JK9maQgCHzHUZBuFYoAxgMB7W3eZMMFhHETCi66PyLe0AmMVdVGjJEhyRp3HJJ2jkd6LIxqg6NqnhinBWW+E+Hw==
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=hzxGUxqKWe9KOmXTaQv5J6jzYhPeLxmmmDsjRCLdY8s=; b=nouAGZQvBonFloGfUdb3BGEHZqlkqWTlm2G+l7YF0LeZ4uYv2+cKuvtdJdVFwJa82WxYgx9g8CghLaKJMnoTOqkyHHmFIdWbSrH9aRIQw8pHFsQCDicebQS6X04GzYV85UJmLY/BESAtkYTlRaOUFjrGDIQclbR9a+f7UN3iORg=
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Wed, 15 Jul 2020 14:35:14 +0000
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3]) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3%5]) with mapi id 15.20.3174.025; Wed, 15 Jul 2020 14:35:14 +0000
From: Mike Varley <mike.varley@securekey.com>
To: Tom Jones <thomasclinganjones@gmail.com>, Dick Hardt <dick.hardt@gmail.com>
CC: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: [Txauth] Client Registration (Was: Key handle vs client id & handle
Thread-Index: AQHWWhDWyJ/zdl74zk6R5leJfCQDpqkHt/AAgAC7LQA=
Date: Wed, 15 Jul 2020 14:35:14 +0000
Message-ID: <A519897D-8BDA-420B-A8DF-0EB77E23E248@securekey.com>
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <CAD9ie-u8hT42pP0t2i=uuTt80fZA6ad03qGJnpWP79rGUcxR1w@mail.gmail.com> <CAK2Cwb68pUSY8kVYiSVF=i8HcaM+mMvu2gVyA4TjdnLh-i=Ehw@mail.gmail.com>
In-Reply-To: <CAK2Cwb68pUSY8kVYiSVF=i8HcaM+mMvu2gVyA4TjdnLh-i=Ehw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=securekey.com;
x-originating-ip: [50.101.239.135]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bf09c711-55cf-475b-a612-08d828cc49b4
x-ms-traffictypediagnostic: YTBPR01MB3966:
x-microsoft-antispam-prvs: <YTBPR01MB3966FF24CDF913B98266A80EE47E0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CVgc9xO3S6AAbAbeIb46L/jJ11rErCpoPBUI9OsFUQuXwT1KqFhb66gugeb8BAUIFSK6q7ZHnidQjVgLan9D6TRK4UPI6tCutkAkTuOVssDcayDgth7P6S8SZd9dhwZlwOqWJ618eQbHvQnYLg3GyvMPgHmhUKbASlSy+DxOCd2vgrXziGIepebHmnrZ3bckJPzC+DqM9bXWMakWQJc5NI0Hv3WYdQLC4Fu4ESbReiGncpows0sq/Xq6jtjL/NSDH/T2lfJyiSPlsPI6OW0M5u5DQr3xi5e3arx6uz9RsBTHNdA6GTLulaub1qgCHVz84maRItyNl15l0rNCXiJ0bcv3qeQbdiQ88dNGjuV/w47T8ZnbfuCoxPLyXsv+V3Wgin3tQFdy9fKp2xo3VsqO2g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(396003)(366004)(376002)(136003)(346002)(33656002)(45080400002)(2616005)(966005)(316002)(6506007)(9326002)(8676002)(5660300002)(53546011)(8936002)(66446008)(6512007)(66556008)(66946007)(83380400001)(36756003)(64756008)(66476007)(6486002)(76116006)(4326008)(71200400001)(86362001)(21615005)(26005)(44832011)(478600001)(54906003)(2906002)(166002)(110136005)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: wIClrvrIubU82oNoWnnD79+PkIQQWBwWzaN6kYosA7xOl3eEnSLqJm7ojPSBEmOaUl+PtapCiWToYvW6YelYtd6w24tBqGPBNrCH6EjZY1Z7se4Q62GuLFa/eFiPI7Q8HS0KfHnrvRuY9UVJLfzFkvLIYKJt81diigxDsK/+0rUxcMKaovRCwi7pSvhvcJIotrBxuSUII/GOeiDBKWK0rjKnWN1IZXTRLoLXBsVdnF3TO6t0vl1utGmOhRUN/TTXGmYI4AxyJBmH2uGv1VMkYWkrwLa1wuIIy6pPe51tBroYQTzA0M0B5Vw+/tLehMNfcrstSsIjtea0YXzCMUregoQex/QgvyyZzehiLvFWTi5dJAT1Fuw5TKO4vI7tic1nWJqUkHQ1PWEFCwtGpV4B9BhbgIXxPmtPpbehn+kw0xzNKC2N5BfOPETmkZbBDrhhBwsLT69l8jCLhiXNzuImfQrEREijPhVwcNO8c5AsOeqiCM1rPiILEqtBE/yKPX55
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_A519897D8BDA420BA8DF0EB77E23E248securekeycom_"
MIME-Version: 1.0
X-OriginatorOrg: securekey.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bf09c711-55cf-475b-a612-08d828cc49b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 14:35:14.6752 (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: JZhQlf/Zk1c0Z4IyZrGiedY9TubFQd/J2sLb0RridT3pXawi4ybsSnY8z4ohPbKHbAW9nhMkeTZd43OlrSic2uVEAr07t5RdOdyM0xJHBN4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3966
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/WJEnuhjf9GgJzoZHy1swnjNPKds>
Subject: Re: [Txauth] Client Registration (Was: Key handle vs client id & handle
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: Wed, 15 Jul 2020 14:35:45 -0000

Hi Tom,
I think the group is still aligning on the concept, and the entity statement is a mechanism (and likely an appropriate one) but we just haven’t gotten there yet.

I think the next question (once we agree there is a requirement for this type of assertion for clients) is what type of assertions may need to be supported…

MV

From: Tom Jones <thomasclinganjones@gmail.com>
Date: Tuesday, July 14, 2020 at 7:25 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Mike Varley <mike.varley@securekey.com>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Justin Richer <jricher@mit.edu>, "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Txauth] Client Registration (Was: Key handle vs client id & handle

I suggested earlier to use the entity statement of the Openid federation spec, but heard no feedback. Why not?
thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:00 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
(changing subject to reflect topic)

In my opinion, client registration is in scope.

In both XYZ and XAuth, the client can provide some information about itself, and get back an ID it can use in subsequent calls. No one has said that should NOT be in scope so far.

Myself, I do support adding other mechanisms for a Client to share information about itself with an AS such as software statements, or a URI that binds a URI to information retrieved from that URI, and to the Client.

I agree that we don't want to define software statements per se, but we should refer to some standards so that interop between clients and ASs.

/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley <mike.varley@securekey.com<mailto:mike.varley@securekey.com>> wrote:
Is client registration in scope for the protocol?

A generic way of handling clients (via ID or Handle or Key or whatever) is to have processing rule on the AS such as “if the AS recognizes the client ID (and authentication of that client ID) then it may process the request on behalf of that client. If the AS does not recognize the client ID, it must treat this as a new client registration and evaluate any authorization evidence the client provides before enabling the client and mapping policies to that client” (this means dynamic or automatic clients need to provide additional assertions / software statements whatever to register their ID.

Something like this allows for very flexible systems:
System A can be unknown to the AS but can dynamically registered each time with an appropriate software statement
System B can have a fairly stable client ID at the AS, but rotate that ID every month through automatic registration (with an assertion it got from the AS during a pre-registration for example)
System C can pre-register with the AS for a client ID because it doesn’t deal with software statements etc…
…
And even ‘StatelessAS’ can operate by never storing client IDs because it will always just rely on the software statements.

I think a client registration protocol that allows these scenarios would be very useful in GNAP, but hopefully avoiding having to define what ‘evidence’ the AS needs to accept for each scenario.

Thanks,

MV

From: Txauth <txauth-bounces@ietf.org<mailto:txauth-bounces@ietf.org>> on behalf of Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>>
Date: Tuesday, July 14, 2020 at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>, "txauth@ietf.org<mailto:txauth@ietf.org>" <txauth@ietf.org<mailto:txauth@ietf.org>>, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>>
Subject: Re: [Txauth] Key handle vs client id & handle

I agree that there are significant differences between statically and dynamically registered clients and that’s appropriate to be able to syntactically differentiate between them at runtime.  For one thing, the resource requirements at the authorization server can be very different.

We should also be thinking about how to include what the OpenID Connect Federation spec https://openid.net/specs/openid-connect-federation-1_0.html calls “Automatic Registration”.  This lets the client encode a registration request reference in the client ID, so no static or dynamic registration even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1.

                                                       -- Mike

From: Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>
Sent: Friday, July 10, 2020 1:17 PM
To: txauth@ietf..org<mailto:txauth@ietf.org>; Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>>; Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Subject: Key handle vs client id & handle

+ Mike as he had interest in this topic

My understanding is that an existing OAuth 2 client would use their current client id as their key handle, and a dynamic client (one that was not pre-registered) would be given a key handle by the AS.

There are potentially some significant differences between a registered client, and a dynamic client to an AS.

The AS is likely to know the identity of a registered client, and have different policies between the two types of clients. For example, a registered client may have access to a 'write" scope, while a dynamic client does not.

The AS may have 100s or 1000s of registered clients, but a dynamic client may have 10Ms or 100Ms of instances, which may dictate separate storage services. Additionally, internal to the AS, which systems can write to the registered client store is going to be different than the dynamic client store.

In XYZ, subsequent calls to the AS, both registered clients and dynamic clients pass a key handle, so there is no easy way to differentiate between the two.

While the AS could embed semantics in the key handle identifier to indicate which identifiers are pre-registered vs dynamic, there are many cases where the AS does need to know the difference, so making the difference a feature of GNAP seems like a better path.



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.
[Image removed by sender.]ᐧ
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth