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

Nat Sakimura <sakimura@gmail.com> Thu, 15 March 2012 08:46 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7421F8683 for <oauth@ietfa.amsl.com>; Thu, 15 Mar 2012 01:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level:
X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS2t8nJS7m7d for <oauth@ietfa.amsl.com>; Thu, 15 Mar 2012 01:46:41 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2821F867C for <oauth@ietf.org>; Thu, 15 Mar 2012 01:46:41 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2249300bku.31 for <oauth@ietf.org>; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HDWkOAXHHu0GCAqy/AOcMotd5SRpjJ3Zp/qhI2AuWKE=; b=PcIRA7iJRFNDYg6UBLg3YkDYBw+Kv3Pvwp2N5mD8RKxckIRacCO++smaF5ikSk7DFD tDZuVUiX4FSqRwPZCQHkIaldlkkvtRXSrlCGyycX+/8S1wMKAPPamU1Tem0GZGfCoZYk y8DLrgObCQ4jYCe/gwqg2anLXEb2tRX178Go0Eji5iwGz4MZk72Ri4zNQQvANvg9zMwt liqlThcU44NA96YwdlKOgX+bgbb7Qz9JQiDKOyP+s6P02PDVaTb+4/CW5qCuekfI+9UK jfoVrsm/qz3QVGYeN98dh05B41d7YDzH370r9Jk4WYqABAiqTBiKouoMhisKOHJboJ4k SdFA==
MIME-Version: 1.0
Received: by 10.204.130.81 with SMTP id r17mr2167733bks.118.1331801200179; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
Received: by 10.204.232.203 with HTTP; Thu, 15 Mar 2012 01:46:40 -0700 (PDT)
In-Reply-To: <B26C1EF377CB694EAB6BDDC8E624B6E73C081C3D@BL2PRD0310MB362.namprd03.prod.outlook.com>
References: <B327D847-B059-41D7-A468-8B8A5DB8BFCE@gmx.net> <4F60FEDF.1030600@alcatel-lucent.com> <B26C1EF377CB694EAB6BDDC8E624B6E73C081C3D@BL2PRD0310MB362.namprd03.prod.outlook.com>
Date: Thu, 15 Mar 2012 17:46:40 +0900
Message-ID: <CABzCy2DRThEaT=RN+0dn5taZ_OVdtnwKWgd3SEJ3NGH9Miwn6Q@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Anthony Nadalin <tonynad@microsoft.com>
Content-Type: multipart/alternative; boundary="00151747805c72b92604bb44210a"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2012 08:46:43 -0000

Looks good but I would like the group to consider the capability of signing
the request to be added.

See  http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

It basically adds capability of signing the request in the form of JWS.


=nat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin <tonynad@microsoft.com>wrote:

>   Agree contents looks good
>
> Sent from my Windows Phone
>  ------------------------------
> From: Igor Faynberg
> Sent: 3/14/2012 4:26 PM
> To: oauth@ietf.org
>
> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
>
>  Looks good and comprehensive to me.
>
> Igor
>
> On 3/14/2012 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
> > 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
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en