Re: [OAUTH-WG] OAuth WG Re-Chartering

[Torsten Lodderstedt <[e-mail]>]

Hi John,

> I don't think dynamic registration completely removes the need for a
> public client, that can't keep secrets.

I don't get this argument. In my opinion, there are two use cases, 
which currently motivate usage of public clients and none of them is 
about "keeping secrets".

1) native apps - There is no mechanism for securely _provisioning_ 
those clients with client secrets. So it does not make sense to use 
secrets for authenticating them. Dynamic client registration would allow 
them to obtain client id and secret on activation/installation. The 
security of the respective secret is the same as for refresh tokens. So 
either both can be protected appropriately or none of them. Please note: 
I'm not talking about trust in the identity/authenticity of the 
particular app installation. I'm just talking about simplifying the 
OAuth flows and description. Today an AS needs to support the refresh 
tokens or resource owner grant type for both confidential and public 
clients in order to also support native apps.
2) implicit grant - here, public clients are used because the protocol 
design itself does not allows for validating client secrets. Obviously, 
digital signature would help but make the protocol more difficult to 
use.

Basically, dynamic client registration allows a client to bind to an AS 
at runtime. That's what it makes so valuable with respect to 
interoperatibility. Whether the client just registers meta data or also 
obtains a secret is another aspect but not the only one.

regards,
Torsten.

>
> While we did do dynamic client registration for Connect that is a
> more constrained use case.
> I would put JWT and AS-RS communication as higher priorities than
> dynamic registration.
> Partially because they are more self contained issues.
>
> John B.
> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>
>> In my opinion, dynamic client registration would allow us to drop 
>> public client thus simplifying the core spec.
>>
>> regards,
>> Torsten.
>>
>> Am 15.03.2012 16:00, schrieb Eran Hammer:
>>> I believe most do, except for the dynamic client registration. I 
>>> don't have strong objections to it, but it is the least important and 
>>> least defined / deployed proposal on the list. The AS->RS work is 
>>> probably simpler and more useful at this point.
>>>
>>> EH
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>> Behalf
>>>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Sent: Thursday, March 15, 2012 4:47 AM
>>>> To: ext Blaine Cook; Hannes Tschofenig
>>>> Cc: [e-mail]
>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>
>>>> Hi Blaine,
>>>>
>>>> These are indeed good requirements you stated below.
>>>>
>>>> When you look at the list of topics do you think that the proposed 
>>>> items
>>>> indeed fulfill them?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>>> Behalf
>>>>> Of ext Blaine Cook
>>>>> Sent: Thursday, March 15, 2012 1:31 PM
>>>>> To: Hannes Tschofenig
>>>>> Cc: [e-mail] WG
>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>
>>>>> On 14 March 2012 20:21, Hannes Tschofenig
>>>> <[e-mail]>
>>>>> wrote:
>>>>>> So, here is a proposal:
>>>>>>
>>>>>> [Editor's Note: New work for the group. 5 items maximum! ]
>>>>>>
>>>>>> Aug. 2012    Submit 'Token Revocation' to the IESG for 
>>>>>> consideration
>>>>> as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
>>>>> consideration as a Proposed Standard
>>>>>> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles 
>>>>>> for
>>>>> OAuth 2.0' to the IESG for consideration
>>>>>> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' 
>>>>>> to
>>>>> the IESG for consideration as a Proposed Standard
>>>>>> Sep. 2012    Submit 'OAuth Use Cases' to the IESG for 
>>>>>> consideration
>>>>> as an Informational RFC
>>>>>
>>>>> This looks great to me.
>>>>>
>>>>> I have serious concerns about feature-creep, and think that the 
>>>>> OAuth
>>>>> WG should strongly limit its purview to these issues. In general, 
>>>>> I
>>>>> think it prudent for this working group in particular to consider
>>>>> standardisation of work only under the following criteria:
>>>>>
>>>>> 1. Proposals must have a direct relationship to the mechanism of 
>>>>> OAuth
>>>>> (and not, specifically, bound to an application-level protocol).
>>>>> 2. Proposals must have significant adoption in both enterprise 
>>>>> and
>>>>> startup environments.
>>>>> 3. Any proposal must be driven based on a consideration of the
>>>>> different approaches, as adopted in the wild, and strive to be a
>>>>> better synthesis of those approaches, not a means to an end.
>>>>>
>>>>> These are the constraints with which I started the OAuth project, 
>>>>> and
>>>>> they're more relevant than ever. I'd hate to see OAuth fail in 
>>>>> the end
>>>>> because of a WS-*-like death by standards-pile-on.
>>>>>
>>>>> b.
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth