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

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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Tschofenig, Hannes (NSN - FI/Espoo)
>> Sent: Thursday, March 15, 2012 4:47 AM
>> To: ext Blaine Cook; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of ext Blaine Cook
>>> Sent: Thursday, March 15, 2012 1:31 PM
>>> To: Hannes Tschofenig
>>> Cc: oauth@ietf.org WG
>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>
>>> On 14 March 2012 20:21, Hannes Tschofenig
>> <hannes.tschofenig@gmx.net>
>>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth