Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
In-Reply-To: <56995365.6030401@gmx.net>
Date: Fri, 15 Jan 2016 12:37:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <14B41AE0-E8B6-4710-86D2-651E781B96F5@oracle.com>
References: <56995365.6030401@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/6HqLfH8mnDumv6-QcArYkgWwICA>
Cc: Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rechartering OAuth: New Charter Text
Precedence: list

Hannes

I would like to propose a brief presentation on "events". While this might n=
ot end up being oauth wg activity, I think a lot of attendees may be interes=
ted.=20

We might make this one of those if we have time topics.=20

Phil

> On Jan 15, 2016, at 12:15, Hannes Tschofenig <hannes.tschofenig@gmx.net> w=
rote:
>=20
> Hi Barry,
>=20
> as discussed today I am forwarding you the new charter text for the
> OAuth working group.
>=20
> 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=
.
>=20
> Ciao
> Hannes & Derek
>=20
> --------------------------
>=20
> Charter Text
>=20
> 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.
>=20
> The OAuth 2.0 protocol suite already includes
>=20
> * a procedure for enabling a client to register with an authorization
> server,
> * 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.
>=20
> 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.
>=20
> 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
> information.
>=20
> For feedback and discussion about our specifications please
> subscribe to our public mailing list at <oauth AT ietf.org>.
>=20
> 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.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth