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

Hi George, 

I see two distinct areas of interoperability, which
are Client-AS and AS-RS. Dynamic client registration belongs to
Client-AS whereas JWT & AS-RS communication belong to the later area.

OAuth 2.0 currently (not fully) covers Client-AS and does not address
AS-RS. In my opinion, the WG should decide whether we first complete
Client-AS and address AS-RS later on or vice versa. 

I'm in favour of
completing Client-AS first and consider client registration a major
missing piece. Why? Because otherwise clients cannot dynamically bind to
any OAuth-AS at runtime but have to pre-register (with any?) :-(.

regards,
Torsten. 

Am 21.03.2012 21:50, schrieb George Fletcher: 

>
+1 to JWT and AS-RS communication over dynamic registration
> 
> On
3/21/12 3:52 PM, John Bradley wrote: 
> 
>> 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: oauth-bounces@ietf.org [6]
[mailto:oauth-bounces@ietf.org [7]] 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
[8]
>>>>> 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 [1] [mailto:oauth-bounces@ietf.org [2]] On
Behalf
>>>>>> Of ext Blaine Cook
>>>>>> Sent: Thursday, March 15, 2012
1:31 PM
>>>>>> To: Hannes Tschofenig
>>>>>> Cc: oauth@ietf.org [3]
WG
>>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>>>>>> 
>>>>>>
On 14 March 2012 20:21, Hannes Tschofenig
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> 2.0' to the IESG for consideration
>>>>>>
er-left:#1010ff 2px solid; margin-left:5px; width:100%"> 
>>>>>> 
>>>>>>
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to
>>>>>>

>>>>>> the IESG for considerat> solid; margin-left:5px; width:100%">

>>>>>>> 
>>>>>>> Sep. 2012 Submit 'OAuth Use Cases' to
>>>>>>
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. > y under the following criteria: 1.
Proposals must have a direct relationship to t
>>>>>> 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 [4]
https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>> 
>>>>>
_______________________________________________
>>>>> OAuth mailing
list
>>>>> OAuth@ietf.org [9]
>>>>>
https://www.ietf.org/mailman/listinfo/oauth [10]
>>>> 
>>>>
_______________________________________________
>>>> OAuth mailing
list
>>>> OAuth@ietf.org [11]
>>>>
https://www.ietf.org/mailman/listinfo/oauth [12]
>>> 
>>>
_______________________________________________
>>> OAuth mailing
list
>>> OAuth@ietf.org [13]
>>>
https://www.ietf.org/mailman/listinfo/oauth [14]
>> 
>>
_______________________________________________
>> OAuth mailing list
>>
OAuth@ietf.org [15]
>> https://www.ietf.org/mailman/listinfo/oauth
[16]

Links:
------
[1] mailto:oauth-bounces@ietf.org
[2]
mailto:oauth-bounces@ietf.org
[3] mailto:oauth@ietf.org
[4]
mailto:OAuth@ietf.org
[5]
https://www.ietf.org/mailman/listinfo/oauth
[6]
mailto:oauth-bounces@ietf.org
[7] mailto:oauth-bounces@ietf.org
[8]
mailto:oauth@ietf.org
[9] mailto:OAuth@ietf.org
[10]
https://www.ietf.org/mailman/listinfo/oauth
[11]
mailto:OAuth@ietf.org
[12]
https://www.ietf.org/mailman/listinfo/oauth
[13]
mailto:OAuth@ietf.org
[14]
https://www.ietf.org/mailman/listinfo/oauth
[15]
mailto:OAuth@ietf.org
[16] https://www.ietf.org/mailman/listinfo/oauth