Re: [OAUTH-WG] OAuth Recharting

"Kepeng Li" <> Fri, 18 December 2015 00:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03D821B3191 for <>; Thu, 17 Dec 2015 16:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.249
X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EWD21pNoBTlr for <>; Thu, 17 Dec 2015 16:59:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F1AF01B318D for <>; Thu, 17 Dec 2015 16:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1450400394; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=qYBdC/MWyd9ydP1+JpzJfQ5sgaRIJlehROMPEax7Umg=; b=m0mlwYplZeJZ10OonU+6vEmarn4ya8ZIsO2KWLYxVwZdaHJoJtGC9aTxYJlvoCJON6dg2m6+A6VKdoJKfv4SO6tosTet/vRn8Yf9+FdtZM2wg9VWoGxM343sjXlVSLrpx1dF1Jqa0EOZM5Mw5S7yTa3gNxMyINeVo4PWXz8Jy5Q=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R931e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301;; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----4McmtFq_1450400383;
Received: from ip: by; Fri, 18 Dec 2015 08:59:49 +0800
User-Agent: Microsoft-MacOutlook/
Date: Fri, 18 Dec 2015 08:59:44 +0800
From: "Kepeng Li" <>
To: Hannes Tschofenig <>, "" <>
Message-ID: <>
Thread-Topic: [OAUTH-WG] OAuth Recharting
References: <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth Recharting
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2015 00:59:59 -0000

Hi Hannes,

Thanks for putting this together.

>and specifications that mitigate security attacks, such as Proof Key for
>Code Exchange.

I propose to change it to:

and specifications that mitigate security attacks, such as Proof Key for
Code Exchange, and Sender Constraint JSON Web Token.

Sender Constaint JWT is mentioned in PoP architecture document, but it is
specified in detail. That is why we provided a separate draft for that.


Kind Regards

在 17/12/15 11:59 pm, "Hannes Tschofenig" <> 写入:

>Hi all,
>at the last IETF meeting in Yokohama we had a rechartering discussion
>and below is proposed text for the new charter. Please take a look at it
>and tell me whether it appropriately covers the discussions from our
>last meeting.
>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.
>For security related bug reports that relate to our specifications
>please contact <<TBD>>. If the reported bug
>report turns out to be implementation-specific we will
>attempt to forward it to the appropriate developers.
>OAuth mailing list