Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

[Phil Hunt <[e-mail]>]

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new model proposes quasi-confidential characteristics but in some respects is missing key information from the public model.  Namely that a group of clients are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far. But certainly what we define here can open that door. 

Phil

On 2013-05-21, at 8:43, Justin Richer <[e-mail]> wrote:

> Phil, 
> 
> I am considering the knowledge model. You could say that we're "throwing away" a shared client_id in one case, because now public clients don't have to be public clients anymore in many cases. Native apps that used to have to be public clients (because they would otherwise all be shipped with the same client_secret) are no longer forced to do that. Each copy can register itself independently. Most of the time this means that the app will just present its pre-configured set of metadata to the AS, and get back a client_id and client_secret all for its own. I don't see how it's possible for an AS to know a client is a member of a "class" or running a particular copy (or version, or instance, etc.) of a piece of code without specifying a large amount of other mechanisms. 
> 
> However, you can still do public clients with a shared client id if you do some kind of manual registration. You don't need dynamic registration for this case because it's easy to just bake the client_id into all of your clients. The "class" of public clients is "tied together" in the manual registration case because the developer went to the AS's webpage and got a client_id to bake into their clients. That doesn't go away. 
> 
> But if you want all copies of your public clients to get the same client_id at all AS's they talk to (or otherwise be linked together), then you're going to need do specify a *whole* lot more than just registration. And it's not at all needed for what I (and others) see as the "normal" case for registration. This is why I want to leave it out of the registration spec and let it get the attention it deserves on its own.
> 
>  -- Justin
> 
> On 05/21/2013 10:26 AM, Phil Hunt wrote:
>> Justin,
>> 
>> Please re-consider what I was saying. You are not cnsidering what was known without reg and what is known after dyn reg. 
>> 
>> In public clients, you are changing the meaning of client_id. 
>> 
>> You are throwing away what was shared among all public clients (a client id) running the same software. 
>> 
>> When you issue a separate id you need to retain what was known before which was critically important-a set of clients share the same software and thus behave in certain ways. 
>> 
>> Gaining a unique cred while losing information about what the software is makes dyn reg's value dramatically reduced. 
>> 
>> Phil
>> 
>> On 2013-05-21, at 6:46, Justin Richer <[e-mail]> wrote:
>> 
>>> 
>>> On 05/21/2013 02:01 AM, Phil Hunt             wrote:
>>>> 
>>>> 
>>>> Phil
>>>> 
>>>> On 2013-05-20, at 8:35, Justin Richer <[e-mail]> wrote:
>>>> 
>>>>> 
>>>>> On 05/17/2013 05:27 PM, Phil Hunt wrote:
>>>>>> Mike,
>>>>>> 
>>>>>> Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.
>>>>>> 
>>>>>> I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications.
>>>>> 
>>>>> I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that.
>>>> <Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly.
>>> 
>>> [JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!". 
>>> 
>>> The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth. 
>>> 
>>>>> 
>>>>> From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
>>>> <ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!
>>> [JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options. 
>>> 
>>> Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.
>>> 
>>>> 
>>>> 
>>>>> A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:
>>>>> 
>>>>>  - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id. 
>>>>>  - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id. 
>>>>> 
>>>>> Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.
>>>>> 
>>>>>> 
>>>>>> Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue                     Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked. 
>>>>> While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the                 BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches                 to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.
>>>>> 
>>>>>> 
>>>>>> Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.
>>>>> That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a                 work-in-progress found here:
>>>> <ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop.
>>> [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network. 
>>> 
>>> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them. 
>>> 
>>> If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, genera