I've been told recently that they have to be published as I-Ds to be considered. The secretariat even clamped down on referencing external blog posts never-mind external specs. :-) The new SCIM BoF which hopes to get a WG formed had to arrange to get the simplecloud.info specs submitted as I-Ds requiring the AD had to open a special window to allow the specs to be submitted during the closed period (which re-opens Mar 26).
I think dynamic registration should become part of the IETF (as opposed to OIDF) because there is a broad issue with software that is installed in many locations running the same service APIs that clients can reach. The OpenID Connect scenario demonstrates one possible case of many to come - particularly with the same software running in the cloud and private infrastructure. SCIM (simplecloud.info) is another example. Not only did they have the same IPR issue, but they have the same dynamic registration issue since the idea is that application service providers implement a common RESTful service API for provisioning. I suspect that since the OIDF would have to decide this, it might not be able to happen in time for the charter. I support this happening after, as long as it is fairly soon --> I have to agree with Eran's practical assertion that charter items should be supported by an existing I-D as a starting point. Phil @independentid www.independentid.com [email protected] On 2012-03-22, at 9:43 AM, John Bradley wrote: > 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 >> [email protected] >> >> >> >> >> >> 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: [email protected] [mailto:[email protected]] On Behalf Of >>> George Fletcher >>> Sent: Thursday, March 22, 2012 6:28 AM >>> To: Torsten Lodderstedt >>> Cc: [email protected] >>> 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: [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 >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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
