Re: [OAUTH-WG] Motivation for OAuth 2.0 Dynamic Client Registration Protocol

[Justin Richer <[e-mail]>]

Right, everything from a client needs to be taken with a grain of salt, it’s the nature of the protocol.

 — Justin

> On Mar 11, 2015, at 9:59 AM, John Bradley <[e-mail]> wrote:
> 
> The other thing to consider is that software statements in native apps are only a hint from "good" clients.
> 
> To know for sure that it is a instance of some software you need a agent on the device to check the signature and bundle_id,  otherwise anyone could extract the software statement and put it in some other client.
> 
> The NAAPS work in the OIDF is looking at how some of that can work.
> 
> John B.
> 
>> On Mar 11, 2015, at 9:04 AM, Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Adam,
>> 
>> Yes, in fact that use case is the motivation behind allowing the initial access token mechanism, where the developer goes and gets a pre-registration token and passes that in through the application itself:
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2 <https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#appendix-A.1.2>
>> 
>> What we don’t specify is *how* the deployment organization finds out about the client developer, since that’s so far been something that’s pretty tightly tied in to deployments. In BlueButton+ we used a combination of a structured initial access tokens and a registry service (think of it like a trust root with discovery components) to get this kind of information across the wire. Within your deployment umbrella you could do something similar, or use the software statement mechanism to carry similar information. Nobody’s sought to have that specific part standardized yet, but you can absolutely deploy it within the Dynamic Client Registration spec.
>> 
>>  — Justin
>> 
>>> On Mar 11, 2015, at 1:26 AM, Adam Lewis <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am curious about the use cases that inspired this draft, as the terminology that is defined within fits like a glove a use case that I have, though the draft doesn't solve it it completely.
>>> 
>>> Namely the use case as I have is for the "client developer" to be able to create a developer account with the "software API publisher" via  developer portal, and to then make their client available for download on an app store (e.g. Google Play), where it would be downloaded by a "deployment organization" and finally run the client registration protocol.  This fits our use case 90%, but we have a further use case that the "software API deployment" is able to identify the "client developer" of the application when executing in a "deployment organization."
>>> 
>>> I'm curious if that last part was ever identified as a use case for the draft?
>>> 
>>> 
>>> 
>>> tx
>>> adam
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>