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

[Eve Maler <[e-mail]>]

Coming in late to this thread: I agree broadly with Justin, Mike, and John. Having an in-band just-in-time registration capability is valuable. By analogy with user identifiers, it's useful for client identifiers to be issued for the asking as the first rung of an assurance (real-world identification/strong ongoing correlation) ladder. UMA definitely needs this because it requires further, finer-grained authorization to assign any significant access rights to clients and their wielders ("requesting parties") -- getting a token is, by itself, not very meaningful. If you want, you can consider this approach a mitigation of the risks in issuing client IDs for the asking...

	Eve

On 21 May 2013, at 1:28 PM, John Bradley <[e-mail]> wrote:

> I agree with Mike, I don't think we are loosing anything, only gaining.
> 
> I think it is a false statement to say that having multiple client instances with the same client_id and secret is a feature.
> 
> In reality with public clients or public clients masquerading as private ones the only real way for the AS to tell them apart in OAuth is by redirect_uri.  We are not changing that, though we are perhaps making it cleaner that client_id for public clients can't be relied upon in any way.   Previously we had what was more or less assumed to be a one to one mapping of client_id to redirect for native clients.
> 
> Once we start assigning unique client_id to instances of clients that are all going to be using the same redirect_uri there are a lot of question a AS has to decide, such as can two client_id register the same redirect_uri?  That could well cause all sorts of race conditions on the device if you have two apps fighting over the same custom scheme.
> 
> So I think in reality the piece of information that a registration server that is going to need to look at is the custom url scheme for apps,  probably disallowing multiple anonymous registrations for the same custom scheme.  
> 
> Getting into the details of how app stores allocate schemes to developers etc is out of scope for this spec.  Someone can build something more sophisticated on top of dynamic registration, but there are a lot of issues outside of the simple how is a client registering for a client_id and secret without forcing a manual step through a web portal.
> 
> I honestly don't think adding some new application identifier solves the problem.  That information is in the redirect_uri for native apps, and the problem doesn't exist for web server clients.
> 
> John B.
> 
> On 2013-05-21, at 2:28 PM, Mike Jones <[e-mail]> wrote:
> 
>> What is the loss of information that you’re concerned about?  It seems odd to me that you’re asserting that there's information loss when the operations performed by Dynamic Client Registration are equivalent to those that are performed by out-of-band OAuth developer portals today.  It’s just automating a formerly manual process.
>>  
>> -- Mike
>>  
>>  
>> From: Phil Hunt
>> Sent: ‎Tuesday‎, ‎May‎ ‎21‎, ‎2013 ‎11‎:‎20‎ ‎AM
>> To: Mike Jones
>> Cc: Justin P. Richer, [e-mail] WG
>>  
>> Mike,
>> 
>> There is an operational loss of information in the dynamic registration spec.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [e-mail]
>> On 2013-05-21, at 10:52 AM, Mike Jones wrote:
>> 
>> No information is being thrown away.  Developers can use dynamic registration to obtain a client_id and then have all the client instances use that client_id if they choose - just like they can do when doing out-of-band registration with a site’s developer portal.  The only difference is that they don’t have to do out-of-band registration anymore!
>>  
>> -- Mike
>> 


Eve Maler                                  http://www.xmlgrrl.com/blog
[phone]                         http://www.twitter.com/xmlgrrl