Would the plan be for the Connect Registration spec to be submitted to IETF so they can become WG drafts?
The spec seems like a good starting point. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-03-22, at 8:34 AM, Mike Jones wrote: > FYI, the OpenID Connect dynamic client registration spec is at > http://openid.net/specs/openid-connect-registration-1_0.html. You can find > points to all the Connect specs at http://openid.net/connect/. > > -- Mike > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > George Fletcher > Sent: Thursday, March 22, 2012 6:28 AM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering > > Hi Torsten, > > I guess I worry that trying to solve all the use cases that get pulled in > with dynamic client registration will take a long time. I've been involved > with both the UMA work and the OpenID Connect work regarding dynamic client > registration and some reasonable constraints and expectations need to be set > in order to reach consensus. > > And what John said... since he beat my response:) > > Thanks, > George > > On 3/22/12 4:40 AM, Torsten Lodderstedt wrote: > 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-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org [mailto:oauth-boun...@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 > > 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 > _______________________________________________ > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
