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 <ve7...@ve7jtb.com> 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 <michael.jo...@microsoft.com> 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, oauth@ietf.org WG
>>
>> Mike,
>>
>> There is an operational loss of information in the dynamic registration spec.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 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
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
