I am strongly opposed to SWD being part of *this* working group. My objection is based on:
1. This is clearly an APP area document, not a SEC area document. Getting this work done through the OAuth WG will skip the most relevant audience for this document as a general purpose tool. 2. This has nothing to do with OAuth directly. It has the same "enabling" relationship to OAuth as HTTP or JSON. 3. This work overlaps with other efforts at the IETF, W3C, and OASIS. If there is strong interest in this work, it should first be coordinated with the other groups and organizations. 4. The APPs AD should look into creating a new WG for this if there is strong interest, but I believe this belongs on the APPs General WG. 5. The OpenID Foundation is free to standardize this within its own process as it chose to do with many other documents related to OpenID. I would assume the OpenID Foundation values their work and reputation enough to stand behind this if they require it for other foundation work. This is not an objection to SWD in general (nor an endorsement), just an objection to this work belonging in the OAuth working group. Btw, there is existing history here. XRD, JRD, host-meta, and well-known URIs were all initiated originally as part of OAuth 1.0 Discovery, but no one working on these efforts suggested they belonged in the OAuth WG. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, March 14, 2012 1:55 PM To: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering This is missing Simple Web Discovery, which there was substantial support for including during the rechartering discussion in Taipei. Considering OpenID Connect as a motivating use case for OAuth, SWD is the one spec that would then be missing for this OAuth use case. Please add it to the list. Thanks, -- Mike ________________________________ From: Hannes Tschofenig Sent: 3/14/2012 1:21 PM To: oauth@ietf.org<mailto:oauth@ietf.org> WG Subject: [OAUTH-WG] OAuth WG Re-Chartering 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
