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

[Torsten Lodderstedt <[e-mail]>]

Hi Paul,

for me, your proposal looks like the natural counterpart of JWT, as it 
standardizes the way to implement handle-based token designs (in 
contrast to self-contained tokens).

therefore +1 from my side.

regards,
Torsten.

Am 15.03.2012 11:35, schrieb Paul Madsen:
> +1 to defining RS-AS interactions. We've implemented such a 'token 
> introspection' endpoint in our AS and I'm be happy to no longer need 
> to explain to customers/partners why it's not part of the standard.
>
> As input, an (incomplete) spec for our endpoint enclosed. (we modeled 
> the verification as a new grant type, leveraging as much as possible 
> the existing token endpoint API)
>
> Wrt the 5 item limit
>
> 1) is this an arbitrary #? if people sign up to work on more items, 
> could it be extended?
> 2) the use cases document seems already well progressed (and 
> informational). Need it count against the 5?
>
> paul
>
> On 3/14/12 5:53 PM, Richer, Justin P. wrote:
>> 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 behttp://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 behttp://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 behttp://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 behttp://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 behttp://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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth