Re: [Txauth] Key handle vs client id & handle

Justin Richer <jricher@mit.edu> Thu, 16 July 2020 20:08 UTC

Return-Path: <jricher@mit.edu>
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 9A99C3A0C0D for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 v-Ykq9phq4-h for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:08:09 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8856D3A0C0E for <txauth@ietf.org>; Thu, 16 Jul 2020 13:08:09 -0700 (PDT)
Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06GK85BG008163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jul 2020 16:08:06 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0E167B3-6ABE-4799-B8EA-627E991D582E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 16 Jul 2020 16:08:05 -0400
In-Reply-To: <CAD9ie-vUn=7rwiMJSJrMdQ=3aeNnhs200eD5dxjgc03OPKdyMw@mail.gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Mike Varley <mike.varley@securekey.com>, "txauth@ietf.org" <txauth@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
To: Dick Hardt <dick.hardt@gmail.com>
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu> <CAM8feuR=jEoUWY7XHYdBtV1xQL3VBmKYffuS1zTF3hkmNUCr_Q@mail.gmail.com> <BFABF236-006A-4627-9219-3D96AA828610@mit.edu> <CAD9ie-vUn=7rwiMJSJrMdQ=3aeNnhs200eD5dxjgc03OPKdyMw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9dKOETrsQnAQxf_OfCHrzUhl7Yc>
Subject: Re: [Txauth] 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: Thu, 16 Jul 2020 20:08:13 -0000

I think that the cross-organizational trust model is an interesting one, and in fact it’s one of the things that’s pushed me away from a client_id. In the scenario that you describe, “client_id” is used to represent something that it was never meant to represent: the organization running the software, not the software itself. It isn’t a client_id, and while in OAuth 2 the client_id could be co-opted to carry that information, it’s considered bad practice to share client_ids between multiple pieces of software. 

I would argue that to address this use case properly, there should be another level of identifier to bridge that trust that the software can present, showing that it is a part of Organization A, and not Organization C. This isn’t a client identifier, it’s an organization identifier, and it should be separate. You might want to identify both the client instance as well as the organization it’s a part of, for example. This is part of the motivation behind putting “organizational data” within scope for the client to send to the AS, after all.

Therefore, I strongly disagree that this scenario “requires” a client_id to be solved. In fact, I think that solving this scenario with a client_id is an anti-pattern that stems from OAuth 2’s over-reliance on client_id as a persistent identifier within the protocol, and we can and should do better with GNAP. It’s very similar to Mike Jones’s referenced federation document, where the client_id is co-opted as a means of bootstrapping client registration and discovery, or in the Solid Authentication specification which stuffs a WebID into the client_id field.

With OAuth 2’s ecosystem, we’ve used the tools that we had to solve our problems, and come up with some very clever solutions. What I’m trying to argue to this community is that we are in a position to create our own, better tools. 

 — Justin

> On Jul 16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> Justin, 
> 
> While I agree that the assumption in OAuth 2 that all Clients have a client_id is problematic, the requirement for a client_id in many use cases is still there, and it does not represent a piece of software, but a relationship between parties.
> 
> Organization A writes client software that calls resources managed by the AS in Organization B. The client_id represents Organization A to Organization B. Organization B does not care what software Organization A is running, and there may be numerous pieces of software at Organization A that use the same client_id. The access granted by Organization B to Organization A needs to be able to be different than the rights granted to Organization C. 
> 
> I agree that we don't want to force all clients to have a client_id, and as discussed, there are a variety of inputs for an AS to accept calls from a piece of software, and often, that will be a particular instance of the software, but we also don't want to force clients to all be treated the same, because they are not. 
> 
> 
> 
> 
> 
> 
> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> Exactly — when we start to look at it as managing the lifecycle of a piece of software, instead of a registration at the AS, we can start thinking in different terms what “trusting” the client means in the context of what the client is doing. That trust could come from some kind of signed attestation about the software (like the OAuth 2 DynReg software statement), or it could come from some externally fetchable item (like a Solid WebID, a DID, or the OIDC Federation extension), or it could come from someone sitting at a console and typing in information and getting back an identifier. And none of these need to pretend to be a global “client id” for it to work. The world of clients is much more diverse than OAuth 2 likes to admit, and we see that with trying to nail down a “confidential” vs. “public” vs. “dynamic” vs. “static” vs. “automatic” vs. “ephemeral” vs. … any number of other things. 
> 
> OAuth 2 only needs client IDs because the front channel needs a way to pass client identifiers when the client can’t authenticate itself directly. We tried to get rid of this restriction with PAR and JAR together, but there turned out to be corner cases in OAuth 2’s world that still needed client_id, and implementations assumed it would be there anyway. 
> 
> In GNAP, we can avoid that problem from the beginning by looking at the model differently and understanding where we’re coming from, and why.
> 
>  — Justin
> 
>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote:
>> 
>> +1 on that.
>> 
>> We can then see it more as life cycle management of the client than registration per say, and this comes with many benefits compared to the current client_id.
>> 
>> Fabien
>> 
>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> I not only agree with Mike Jones that “automatic registration” should be part of the process, but I would argue that that kind of model should be a default mode of operation. If you have an identifier that you can send to short-circuit that, great! But we should focus on having the capability of inlining a lot of this information wherever possible. This is already the direction that the input proposals are heading.
>> 
>> So I kind-of agree that “registration” is in scope for the protocol in general, and since both XYZ and Xauth have mechanisms that allow the client to present a key and get back an identifier that it can use in the future we have something equivalent. 
>> 
>> But I think there’s a little more to it than that: Ultimately, I think we should question thinking in terms of “registration”, a model which has hampered the OAuth 2 model in a lot of use cases. For example, the federation draft Mike Jones references below hacks the “client_id” parameter and makes it point to a document that the AS has to fetch. This construct is done for two reasons: (1) Oauth requires a “client_id” in the request and (2) it’s difficult to pass information by value to the AS due to front-channel restrictions. Since we’re defining a new protocol, we don’t need to hack that functionality into a “client ID” or equivalent and instead we can pass that information directly in the protocol. If we don’t assume that the client *has* to have a client ID equivalent, but it *can* have one in a set of defined circumstances, then I think we are in a much better spot. This is the reasoning for XYZ’s model of having clients identified by the key, and that key can potentially be passed by a reference identifier.
>> 
>> I think all of the use cases that Mike Varley presents below are all valid directions, with the caveat that we shouldn’t assume a client should be presenting an ID at all steps. Mechanisms like software statements should be presentable apart from a client ID, as should on-device keys. We’re probably going to want extensions for device posture and other forms of attestation as well.
>> 
>> This is one of the domains that I think we can clearly surpass OAuth 2’s flexibility and capabilities if we are willing to look past OAuth 2’s assumptions of what’s needed inline in the protocol. 
>> 
>>  — Justin
>> 
>>> On Jul 14, 2020, at 1:54 PM, 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:Michael.Jones=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 <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 <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.
>>> 
>> 
>> -- 
>> Txauth mailing list
>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>