The best way is to get some drafts going and then revisit after the proposed charter is completed. I think the 5 new items limit along with the existing work is as much as this WG can take for the time being.
Getting some market experience would be great too. EH > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Wednesday, March 14, 2012 2:54 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering > > Methods of connecting the PR to the AS are something that several groups > have invented outside of the OAuth WG, and I think we should try to pull > some of this work together. OAuth2 gives us a logical separation of the > concerns but not a way to knit them back together. > > Proposals for inclusion in the discussion include UMA's Step 3, OpenID > Connect's CheckID, and several "token introspection" endpoints in various > implementations. > > -- Justin > > On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote: > > > So, here is a proposal: > > > > ------- > > > > Web Authorization Protocol (oauth) > > > > Description of Working Group > > > > The Web Authorization (OAuth) protocol allows a user to grant a > > third-party Web site or application access to the user's protected > > resources, without necessarily revealing their long-term credentials, > > or even their identity. For example, a photo-sharing site that > > supports OAuth could allow its users to use a third-party printing Web > > site to print their private pictures, without allowing the printing > > site to gain full control of the user's account and without having the > > user sharing his or her photo-sharing sites' long-term credential with > > the printing site. > > > > The OAuth protocol suite encompasses > > * a procedure for allowing a client to discover a resource server, > > * a protocol for obtaining authorization tokens from an authorization > > server with the resource owner's consent, > > * protocols for presenting these authorization tokens to protected > > resources for access to a resource, and > > * consequently for sharing data in a security and privacy respective way. > > > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, > > was published as an informational document (RFC 5849). With the > > completion of OAuth 1.0 the working group started their work on OAuth > > 2.0 to incorporate implementation experience with version 1.0, > > additional use cases, and various other security, readability, and > > interoperability improvements. An extensive security analysis was > > conducted and the result is available as a stand-alone document > > offering guidance for audiences beyond the community of protocol > implementers. > > > > The working group also developed security schemes for presenting > > authorization tokens to access a protected resource. This led to the > > publication of the bearer token as well as the message authentication > > code (MAC) access authentication specification. > > > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH > > token with the SAML 2.0 bearer assertion profile. This offers > > interworking with existing identity management solutions, in particular > SAML based deployments. > > > > OAuth has enjoyed widespread adoption by the Internet application > > service provider community. To build on this success we aim for > > nothing more than to make OAuth the authorization framework of choice > > for any Internet protocol. Consequently, the ongoing standardization > > effort within the OAuth working group is focused on enhancing > > interoperability of OAuth deployments. While the core OAuth > > specification truly is an important building block it relies on other > > specifications in order to claim completeness. Luckily, these > > components already exist and have been deployed on the Internet. > Through the IETF standards process they will be improved in quality and will > undergo a rigorous review process. > > > > Goals and Milestones > > > > [Editor's Note: Here are the completed items.] > > > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' > as a working group item > > Done Submit 'HTTP Authentication: MAC Authentication' as a > working group item > > Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG > for consideration as a Proposed Standard > > Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for > consideration as a Proposed Standard > > > > [Editor's Note: Finishing existing work. Double-check the proposed > > dates - are they realistic?] > > > > Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the > IESG for consideration as a Proposed Standard > > Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to > the IESG for consideration as a Proposed Standard > > Apr. 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for > > consideration as a Proposed Standard Apr. 2012 Submit 'An IETF URN Sub- > Namespace for OAuth' to the IESG for consideration as a Proposed Standard > > May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to > the IESG for consideration as an Informational RFC > > > > [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 > > > > [Starting point for the work will be > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > > > Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration > as a Proposed Standard > > > > [Starting point for the work will be > > http://tools.ietf.org/html/draft-jones-json-web-token] > > > > Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for > OAuth 2.0' to the IESG for consideration as a Proposed Standard > > > > [Starting point for the work will be > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > > > Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG > for consideration as a Proposed Standard > > > > [Starting point for the work will be > > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > > Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an > Informational RFC > > > > [Starting point for the work will be > > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > > > > > > > _______________________________________________ > > 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
