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: [email protected] [6] [mailto:[email protected] [7]] On Behalf >>>>> Of Tschofenig, Hannes (NSN - FI/Espoo) >>>>> Sent: Thursday, March 15, 2012 4:47 AM >>>>> To: ext Blaine Cook; Hannes Tschofenig >>>>> Cc: [email protected] [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: [email protected] [1] [mailto:[email protected] [2]] On Behalf >>>>>> Of ext Blaine Cook >>>>>> Sent: Thursday, March 15, 2012 1:31 PM >>>>>> To: Hannes Tschofenig >>>>>> Cc: [email protected] [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 [email protected] [4] https://www.ietf.org/mailman/listinfo/oauth [5] >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] [9] >>>>> https://www.ietf.org/mailman/listinfo/oauth [10] >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] [11] >>>> https://www.ietf.org/mailman/listinfo/oauth [12] >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] [13] >>> https://www.ietf.org/mailman/listinfo/oauth [14] >> >> _______________________________________________ >> OAuth mailing list >> [email protected] [15] >> https://www.ietf.org/mailman/listinfo/oauth [16] Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] mailto:[email protected] [4] mailto:[email protected] [5] https://www.ietf.org/mailman/listinfo/oauth [6] mailto:[email protected] [7] mailto:[email protected] [8] mailto:[email protected] [9] mailto:[email protected] [10] https://www.ietf.org/mailman/listinfo/oauth [11] mailto:[email protected] [12] https://www.ietf.org/mailman/listinfo/oauth [13] mailto:[email protected] [14] https://www.ietf.org/mailman/listinfo/oauth [15] mailto:[email protected] [16] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
