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] [mailto:[email protected]] 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] >>> 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] [mailto:[email protected]] On Behalf >>>> Of ext Blaine Cook >>>> Sent: Thursday, March 15, 2012 1:31 PM >>>> To: Hannes Tschofenig >>>> Cc: [email protected] WG >>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering >>>> >>>> On 14 March 2012 20:21, Hannes Tschofenig >>> <[email protected]> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
