Thanks Blaine,
This is a good start. I have two suggestions and one request for an additional
paragraph/bullet:
(a) Openness to future items:
I would like to see language that is more open (ready) to accept future items
(ie. those on the horizon and those unforeseen).
For example, the Kerberos WG has just completed its re-charter recently and had
to address this same notion of limit/openness to future items. The language
that was finally chosen reflects this openness, I think. Here are two examples:
"Prepare and advance one or more standards-track specifications which...."
(does XYZ).
"Prepare, review, and advance standards-track and informational
specifications that..." (that does XYZ)
(b) Date for re-charter completion:
Should you perhaps add a date for the completion of the re-chartering. Say
March 2012 (to coincide with the March IETF). Otherwise re-chartering may drag
on for sometime -- which is known to happen in the IETF :-)
(c) Profiles of OAUTH2.0:
I know that some folks want to use OAUTH2.0 as is (just the one spec), but
other folks (including myself) see the need to build additional features on top
the single OAUTH2.0 spec to make OAUTH2.0 work in other scenarios. For lack of
a better term, I use the term "profile" (to mean clearly defined additions and
narrowings of aspects listed in the main OAUTH2.0 spec).
As such, I would like request the addition of the following paragraph to the
new charter:
Prepare, review, and advance standards-track and informational
specifications that define profiles of OAUTH2.0 for usage within certain
well-defined environments. These profiles are adjunct to the OAUTH2.0
specification, and add optional capabilities to those already defined in the
OAUTH2.0 main specification.
I will add more comments as we go along.
Thanks.
/thomas/
__________________________________________
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Blaine Cook
> Sent: Wednesday, April 27, 2011 5:37 PM
> To: oauth@ietf.org; oauth-...@tools.ietf.org
> Subject: [OAUTH-WG] Revised Charter
>
> Hi all,
>
> Now that the Easter holiday is over, please review the following
> revised OAuth charter and provide feedback by May 5th (one week from
> today). Thanks!
>
>
> Description of Working Group
>
> The Open Web Authentication (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.
>
> OAuth consists of
> * a mechanism for a user to authorize issuance of credentials that
> a third party can use to access resources on the user's behalf and
> * a mechanism for using the issued credentials to authenticate
> HTTP requests.
>
> In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work,
> was published as an informational document (RFC 5849). The working
> group has since been developing OAuth 2.0, a standards-track version
> that will reflect IETF consensus. Version 2.0 will consider the
> implementation experience with version 1.0, and will
> * improve the terminology used,
> * consider broader use cases,
> * embody good security practices,
> * improve interoperability, and
> * provide guidelines for extensibility.
>
> The working group will develop authentication schemes for peers/servers
> taking part in OAuth (accessing protected resources).
> This includes
>
> * an HMAC-based authentication mechanism [to the extent that the OAuth
> wg produces specifications that could be used more generally for HTTP
> authentication, the WG will work with the security and applications
> area directors to ensure that this work gets appropriate review, e.g.
> via additional last calls in other relevant working groups such as
> httpbis],
>
> * a specification for access protected by Transport Layer Security
> (bearer tokens),
>
> * an extension to OAuth 2.0 to allow access tokens to be
> requested when a client is in possession of a SAML assertion.
>
> A separate informational description will be produced to provide
> additional security analysis for audiences beyond the community
> protocol implementers.
>
> Milestones will be added for the later items after the near-term work
> has been completed.
>
> Goals and Milestones
> May 2011 Submit 'HTTP Authentication: MAC Authentication' as a
> working group item
>
> May 2011 Submit 'OAuth 2.0 Threat Model and Security Considerations'
> as a working group item
>
> Jul 2011 Submit 'The OAuth 2.0 Authorization Protocol' to the
> IESG for consideration as a Proposed Standard
>
> Jul 2011 Submit 'HTTP Authentication: MAC Authentication' to the
> IESG for consideration as a Proposed Standard
>
> Aug 2011 Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the
> IESG for consideration as a Proposed Standard
>
> Oct 2011 Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for
> OAuth 2.0' to the IESG for consideration as a Proposed Standard
>
> Nov 2011 Prepare re-chartering
> _______________________________________________
> 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
