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 <jric...@mitre.org> 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 <jric...@mitre.org> wrote: >> >>> >>> On 05/21/2013 02:01 AM, Phil Hunt wrote: >>>> >>>> >>>> Phil >>>> >>>> On 2013-05-20, at 8:35, Justin Richer <jric...@mitre.org> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
