Re: [OAUTH-WG] OAuth WG Re-Chartering

["Richer, Justin P." <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth