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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Paul, 

 

Interesting stuff. Thanks for sharing your draft writeup with us. 

 

Could you submit the document as Internet Draft when the submission
gates open again? 

The I-D submission tool will be reopened at 00h UTC, 2012-03-26.

 

>From the current list of items what do you consider less important?

 

Ciao

Hannes

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of ext Paul Madsen
Sent: Thursday, March 15, 2012 12:35 PM
To: Richer, Justin P.
Cc: [e-mail] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

 

+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 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