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

[John Bradley <[e-mail]>]

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

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