I really like the 5 items limit. If people are uncomfortable about leaving so many items off the charter, the charter can have an explicit line item for further charter review once all work has been completed. This is the default process anyway, but people here tend to be over sensitive, you that's one way to address that concern.
Any item proposed must be supported by an existing I-D used as the basis for WG work, at least one editor with the capacity to see this work through, and sufficient WG interest to do the work. It must also be 100% relevant to OAuth and belong in a security area working group. I strongly believe that suggesting charter items without an existing draft is counter productive. If the work exists elsewhere, it must first be submitted as an I-D before we discuss it. EH From: Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> Date: Thu, 22 Mar 2012 09:24:37 -0700 To: Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering 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<http://www.independentid.com> phil.h...@oracle.com<mailto: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> [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<mailto: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> [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<mailto: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> [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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
