It is a OIDF spec at the moment. We don't have any plan to submit it currently.
If there is a WG desire for that to happen the OIDF board would have to discuss making a submission. All in all I don't know that it is worth the IPR Lawyer time, as Thomas has a quite similar ID Submission. Anything is possible however. John B. On 2012-03-22, at 1:24 PM, Phil Hunt wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
