Hi Mike, Hi Justin, it would be important to point to a document or some other write-up so that everyone in the group understands the scope of the work you are proposing to do.
Ciao Hannes Sent from my Windows Phone -----Original Message----- From: ext Justin Richer Sent: 4/13/2012 9:32 PM To: Mike Jones Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? -- Justin On 04/13/2012 01:10 PM, Mike Jones wrote: > Yes, there was an explicit decision in that regard. My sense was that the WG > did think they're important but they only wanted to take on a manageable > number of tasks at once. > > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Justin Richer > Sent: Friday, April 13, 2012 10:02 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) > > Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS" > get dropped? There seemed to be interest in the list in coming up with a > generally applicable scheme, or set of schemes, to do this, and there are > certainly no shortage of starting points. Both AOL and Ping have their own > token introspection drafts that got put to the list, we've developed our own > internal approach here, UMA has an alternative approach, and OpenID Connect > has invented its own approach for ID Tokens. > > I just want to make sure that this was an explicit decision of it being out > of scope here and not an inadvertent omission. > > -- Justin > > On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: >> Hey guys >> >> based on the discussion before, during, and after the Paris IETF meeting I >> am going to send the following updated charter / milestones to the IESG. >> Please have a quick look (till the end of the week) to double-check the >> content (particularly the suggested milestone dates): >> >> ---------- >> >> >> 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?] >> >> 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 >> >> [Editor's Note: New work for the group] >> >> Nov. 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/] >> >> 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] >> >> Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration >> as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-simple-web-discovery] >> >> Mar. 2013 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] >> >> Mar. 2013 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] >> >> 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] >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
