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

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

Makes sense to limit the scope within this WG and try to spin new ones where appropriate for other work (or find homes in others). We wouldn't want the OAuth WG to just be a convenient hanging-point for vaguely related things. That said, the AS-PR connection is a real and present known gap introduced in OAuth2 (since OAuth1 didn't even think of them as separate entities) and *somebody* should be trying to codify the best ways to fill that gap and I think this is a good place to do it.

Along those lines, I don't think that SWD really belongs in the OAuth group either *except* for the fact that there's a Discovery mandate below that nobody's contesting. It's arguable that this simply covers the WWW-Authenticate header and its value in different contexts, but we all know this is incomplete discovery at best. JWT also doesn't feel like it really belongs here, but since JOSE won't have it, it's a fairly important orphan that's already seeing deployment experience.

Add to all of this that I have two other drafts that I'd like to see dusted off and moved forward through some process -- alternate encoding (XML and Form parameters) from the token endpoint, and the UX/dynreg related "instance information" draft. I'll have versions of both of these uploaded once the IETF tracker takes the locks off at the end of the month. Neither of these saw much WG feedback or support before, though, so I'm open to suggestions of what a better home for them might be, if there is one. Or maybe we should make a new group for all the orphaned open web specs?

 -- Justin

On Mar 14, 2012, at 6:02 PM, Eran Hammer wrote:

> 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