Subject: Re: [OAUTH-WG] Internal WG Review: Recharter of Web Authorization Protocol (oauth)

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 May 2012 15:27:02 +0100

Hi,

There's been a bit of IESG comment on the proposed new
charter resulting in a few editorial changes. So just
in case, the text below is what I'd like to propose for
approval on Thursday.

Let me know if there's anything substantively wrong
here, in which case, we'll probably want to re-spin
the text and I'll put it back for consideration on
the following IESG meeting (another two weeks).

Thanks,
Stephen.

> ------------------------------------------
> Web Authorization Protocol (oauth)
> ------------------------------------------
> Current Status: Active
> Last updated: 2012-05-03
>
> Chairs:
>  Hannes Tschofenig <[email-masked]>
>  Derek Atkins <[email-masked]>
>
> Security Area Directors:
>  Stephen Farrell <[email-masked]>
>  Sean Turner <[email-masked]>
>
> Security Area Advisor:
>  Stephen Farrell <[email-masked]>
>
> Technical Advisor:
>  Peter Saint-Andre <[email-masked]>
>
> Mailing Lists:
>  Address:      [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/oauth
>  Archive:      http://www.ietf.org/mail-archive/web/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 authorization 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.
>
> 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 work that remains to be
> completed on message authentication code (MAC) access
> authentication and SAML assertions to interwork with existing
> identity management solutions.  The working group will complete
> those remaining documents, and will also complete documentation
> of the OAuth threat model that was started under the previous charter.
>
> The ongoing standardization effort within the OAuth working group
> will focus on enhancing interoperability of OAuth deployments.  A
> standard for a token revocation service, which can be separated from
> the existing web tokens to the token repertoire will enable wider
> deployment of OAuth.  Extended documentation of OAuth use cases
> will enhance the understanding of the OAuth framework and provide
> assistance to implementors.  And dynamic client registration will make
> it easier to broadly deploy OAuth clients (performing services to users).
>
> Goals and Milestones
>
> 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
>
> May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
>          the IESG for consideration as a Proposed Standard
> May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
>          consideration as a Proposed Standard
> May  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
> Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG
>          for consideration as a Proposed Standard
>
> 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]
>
> Dec. 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]
>
> Jul. 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]
> ------------------------------------------

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2012 17:41:50 +0000

Looks pretty good to me.  I might consider adding a sentence in the paragraph that motivates the new work items (that starts with "The ongoing standardization effort") to motivate the JWT work items.  For instance "Having a standard JSON-based assertion format and a profile for using it with OAuth will both improve interoperability among selected OAuth deployments and facilitate deployments."  (All the other new work items are already motivated in that paragraph.)

Typo:  Change "a authorization" to "an authorization".

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Wednesday, May 09, 2012 7:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Internal WG Review: Recharter of Web Authorization Protocol (oauth)

Hi,

There's been a bit of IESG comment on the proposed new charter resulting in a few editorial changes. So just in case, the text below is what I'd like to propose for approval on Thursday.

Let me know if there's anything substantively wrong here, in which case, we'll probably want to re-spin the text and I'll put it back for consideration on the following IESG meeting (another two weeks).

Thanks,
Stephen.

>  Hannes Tschofenig <[email-masked]>  Derek Atkins 
> <[email-masked]>
>
> Security Area Directors:
>  Stephen Farrell <[email-masked]>  Sean Turner 
> <[email-masked]>
>
> Security Area Advisor:
> The Web Authorization (OAuth) protocol allows a user to grant a 
> third-party Web site or application access to the user's protected 
> 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.
>
> completed on message authentication code (MAC) access authentication 
> and SAML assertions to interwork with existing identity management 
> solutions.  The working group will complete those remaining documents, 
> and will also complete documentation of the OAuth threat model that 
> was started under the previous charter.
>
> The ongoing standardization effort within the OAuth working group will 
> focus on enhancing interoperability of OAuth deployments.  A standard 
> for a token revocation service, which can be separated from the 
> existing web tokens to the token repertoire will enable wider 
> deployment of OAuth.  Extended documentation of OAuth use cases will 
> enhance the understanding of the OAuth framework and provide 
>     consideration as a Proposed Standard Done  Submit 'The OAuth 2.0 
> Authorization Protocol' to the IESG for
>          the IESG for consideration as a Proposed Standard May  2012  
> Submit 'OAuth 2.0 Assertion Profile' to the IESG for
>          consideration as a Proposed Standard May  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 Dec. 
> 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG
>          IESG for consideration as a Proposed Standard [Starting point 
> for the work will be 
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 May 2012 01:45:07 +0100

Hi Mike,

> Looks pretty good to me.  I might consider adding a sentence in the paragraph that motivates the new work items (that starts with "The ongoing standardization effort") to motivate the JWT work item…

I'm not sufficiently familiar with the current state of
play to include "JSON-based" so I've left that out.

> Typo:  Change "a authorization" to "an authorization".

Ta,
S.