[OAUTH-WG] Rechartering OAuth: New Charter Text

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 15 January 2016 20:15 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C5CBA1B321C for <oauth@ietfa.amsl.com>; Fri, 15 Jan 2016 12:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IOQ0TkHbVbY0 for <oauth@ietfa.amsl.com>; Fri, 15 Jan 2016 12:15:40 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9E51B3215 for <oauth@ietf.org>; Fri, 15 Jan 2016 12:15:39 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1a5Psi2jxC-016zHz; Fri, 15 Jan 2016 21:15:34 +0100
To: Barry Leiba <barryleiba@computer.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56995365.6030401@gmx.net>
Date: Fri, 15 Jan 2016 21:15:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="w8hCb33IUcEwp9215TInMBjr0c7taxRUr"
X-Provags-ID: V03:K0:H14bu2JcnClFFcc6XLRO4hB11H6Nr8EdeADjogkqKlU/fdEWOU/ A1/YXlfBiX8TnbwXmzT/UO24doQL5Kvdek10g7/I5o1KHIxZ2fd19PD1aiNjgXehudgOfQP BvTK/Dsty2/gLfvq60ke+WTRswXvE0bQDexvy3poXz6VVPv4uE7FSfWzFYxtOD8LjCObiOg ZMq8cAXB2QpCjmOzWNLEg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:cZvrWyPaU+0=:RmZRXJtUnSB29c8E60uRLl FlyZ8E3VpKsIpLrh/Xs+IU6jNLWSIxXzBvneN9AG+HLm9027EVQfIwmfIoNtj/XxkmUso+J+U lhyC/o0Dt94Q7AVCrUoklRmt65l07Ccz6LlE667RMsSnVRh6g440U965ZZ99WjmQMw7DrriOc igFOiZ0TmH3e+rEZdjkJGfJ3VYPw4hjIcd+90siMnb3wnZBPsbNY5ij4ByYNLAUlMCVqmcDM6 Y3/xB0SqNguG+DyKyEz9d6RniLi/sbMwgXxv7QNHGnMjf/1lK13mWSxoXIFy7O5NIoRp/JV3a wYIohud7gv3CcD30NtMnQiqjLxYtfKR9Xm/qn7MsfqDZn4rnIGLcNGsmYbzxufCBvLjvjaiZc xpiWSfGX9FtejBh1O4DPOCF+fG0+aaqOUgZTTD72oA7doy6dMud4rlTJmablpMgw8FSANR+YK 27Drcv1dNAHKWRvzBUc8SWIsrhwNr6JhsFMuxzqFEnuG6eKqk3glNAUZOX4nEzPM5oXicjGFd 1DRygFmXgzjdsryEFNjgbcZbtAzmFszAVJV4UJgDfnh+RLJPJ648IJh3fOt5wDsP32S45K6oR GjmkYfKfp1YmD6q+HC9WvDOwqDDFJtl2v45vvsz1rfFIvTDcVsY1zixNR1xyaaYhsd7dYjAK4 Ysjst5+ujw7I+/IVu/rbOVAKElTVwB0ySPO4qJ58nTnQez1JpR+5DXi5TVBlHg/LG1fuTN6ss O5kIOPfTpCHnOyzcWELoOpIognKKcC7Iawz0cW8oeM2dIx1BA6SNfsyo22M=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/5AP1hPpw_QtDmjkmKZAyjlWIyB4>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] Rechartering OAuth: New Charter Text
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 15 Jan 2016 20:15:41 -0000

Hi Barry,

as discussed today I am forwarding you the new charter text for the
OAuth working group.

In parallel to the IESG processing this re-chartering request we will
run a call for adoption to also update the milestone list at the same time.

Hannes & Derek


Charter Text

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 share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite already includes

* a procedure for enabling a client to register with an authorization
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent, and
* protocols for presenting these authorization tokens to protected
resources for access to a resource.

This protocol suite has been enhanced with functionality for
interworking with legacy identity infrastructure (e.g., SAML), token
revocation, token exchange, dynamic client registration, token
introspection, a standardized token format with the JSON Web Token, and
specifications that mitigate security attacks, such as Proof Key for
Code Exchange.

The ongoing standardization efforts within the OAuth working group
focus on increasing interoperability of OAuth deployments and to
improve security. More specifically, the working group is defining proof
of possession tokens, developing a discovery mechanism, providing
guidance for the use of OAuth with native apps, re-introducing
the device flow used by devices with limited user interfaces, additional
security enhancements for clients communicating with multiple service
providers, definition of claims used with JSON Web Tokens, techniques to
mitigate open redirector attacks, as well as guidance on encoding state

For feedback and discussion about our specifications please
subscribe to our public mailing list at <oauth AT ietf.org>.

For security related bug reports that relate to our specifications
please contact <oauth-security-reports AT ietf.org>. If the reported
bug report turns out to be implementation-specific we will attempt
to forward it to the appropriate developers.