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

Mike Jones <Michael.Jones@microsoft.com> Wed, 14 March 2012 20:54 UTC

Return-Path: <Michael.Jones@microsoft.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 A6ABC21F879B for <oauth@ietfa.amsl.com>; Wed, 14 Mar 2012 13:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 bEwuyhvNZCXu for <oauth@ietfa.amsl.com>; Wed, 14 Mar 2012 13:54:55 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id B77AD21F8760 for <oauth@ietf.org>; Wed, 14 Mar 2012 13:54:54 -0700 (PDT)
Received: from mail50-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 20:54:55 +0000
Received: from mail50-am1 (localhost [127.0.0.1]) by mail50-am1-R.bigfish.com (Postfix) with ESMTP id E4A722405D6; Wed, 14 Mar 2012 20:54:54 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VS-33(zzbb2dI9371Ic85fh4015I199bRzz1202hzz1033IL8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail50-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail50-am1 (localhost.localdomain [127.0.0.1]) by mail50-am1 (MessageSwitch) id 1331758492916029_17968; Wed, 14 Mar 2012 20:54:52 +0000 (UTC)
Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.237]) by mail50-am1.bigfish.com (Postfix) with ESMTP id D3A9E4E0046; Wed, 14 Mar 2012 20:54:52 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 20:54:50 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.237]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Wed, 14 Mar 2012 20:54:44 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org WG" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] OAuth WG Re-Chartering
Thread-Index: AQHNAiAMCRIf4APwgUm5DSot8V56SZZqRR3K
Date: Wed, 14 Mar 2012 20:54:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436641D81E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <B327D847-B059-41D7-A468-8B8A5DB8BFCE@gmx.net>
In-Reply-To: <B327D847-B059-41D7-A468-8B8A5DB8BFCE@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436641D81ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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: Wed, 14 Mar 2012 20:54:56 -0000

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 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
https://www.ietf.org/mailman/listinfo/oauth