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

[Eran Hammer <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Richer, Justin P.
> Sent: Wednesday, March 14, 2012 2:54 PM
> To: Hannes Tschofenig
> Cc: [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth