[OAUTH-WG] Proof of Possession Tokens: Next Steps

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 19 January 2016 11:45 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 79F521B2C9C for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 03:45:35 -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 GIq068H7OZGm for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 03:45:33 -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 630A01B2C91 for <oauth@ietf.org>; Tue, 19 Jan 2016 03:45:33 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSduu-1akpcF1a3Y-00RcAm for <oauth@ietf.org>; Tue, 19 Jan 2016 12:45:31 +0100
To: "oauth@ietf.org" <oauth@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <569E21DA.30002@gmx.net>
Date: Tue, 19 Jan 2016 12:45:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="KpnuaGWIJkFDPQ3hsROfdMSaRJWpo6sS6"
X-Provags-ID: V03:K0:CSMyLyJS3samXTQbg7IMAmaoKUhxPN8qYzReOd9WPQWg4bbN6RZ f2eMedRqSb0EuEzkIrAcgYh9YUMPFdG7FuDR29lJTLbSHnA+hUipvv6YYMPLHQsj3Rbdu+D 89GzAHsiE80XHqCJBJdA3agqnjwU1rmYNCUiPtkW2cYnAqto0Ly/XZW9kTS3/RtlgofhIWn MUhoK1W/hYKz/MbLmwFiQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:poJBHBYV794=:79l2vXdB78NL2/LObPY2uR sJAl6vcyZ9rd4TDC2iJF4+yMD5g+LNzgSkn2zCwqEDpjVjraFgP5wrjsNJEN5MTWklqodaErf l6V3oxPQ0eqJ/4zxenEhF6/lre1EiNF1E/FGdyRgIwBNGV2p3RpRVfS6v8ImeCmA1y5E+YdyY ysjK//FHHUTzsEqcqWbWXE7Pnh+ZsgDu7RIC2OC3TwM++k6ssu0nCsknVUKc4/pxMC//1UoFX I9DmXBgWVTARto+dX2Oqv2tDjaAY/r1KJmFr+tOPsojEYXo+Uf+M8xxosQdVPolafpkRVZVfq /ZX9AgE5ZutUd618ftq0Opx0laIm954UdXXoTOrBWWutIR8Tg5qoP85wE3V7oHYoLs66HDC9c xiKnO0qBUzSdosQCZcBBsNBHl4ETjkKt3Ln/hLoAxEZDJhURoVMpE031NsltE5KjetE9G7ps3 Ju3Iu3T2OYgTBmEfU8wmTR5KsacN51Run5D06XoRVUELlD3GMJ0bRpbKviUfX7WyLNuVTU6kk 3BrGwulxV+mZwbHj0kO7eIIJzBDd7RJubCqv3wMnTRwaEGTZSHdwc3APCLSOEHPZRZ7Ewp1gJ rqImPdAgWzJBET0Yh4ud2URZIyWzoMxqwBo5duqorTmKehXhvVEVSBTmMSGKVAIa4P2OmOXgD vJ4Qfdkj4M6oDZ/k42EP8jWYo4bVvfReC6KGmgokvIXRSgTH1LV1FYkA/5rP7rI5tw6lrYj+2 mtnz/7LO8YkUsW6YumIaZwIFNytxmNVKk94+FozbshUnFMcUHmGCAitZpaY=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/oZr60LV3NTfdRMvii-KdsA3t0a0>
Subject: [OAUTH-WG] Proof of Possession Tokens: Next Steps
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: Tue, 19 Jan 2016 11:45:35 -0000

Hi all,

I wanted to drop a high level message about possible next steps for the
PoP work.

As you have seen from my status update, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
PoP architecture document was already in IESG processing but I have had
asked Kathleen to delay the publication given that we ran into scoping
issues, as discussed on the list. See

The change of scope related to desire to not just binding a key to the
access token but also to other parts of the OAuth system to avoid cases
where an attacker can just obtain attack other parts of the system
instead (for example, by obtaining an bearer-based refresh token to then
obtain a new PoP access token).

The recently discovered security problems tell us that we need to
simplify our solutions a bit as well to ensure that we get the security
analysed properly. More options means more time to analyse all the
different options.

What does this mean to simplify when I talk about expanding the scope in
the earlier paragraph?

I am suggesting to

* to consider focusing on a public key-based only solution for the
web/smart phone app space. (The ACE working group will have to develop a
symmetric key-based version on their own, if desired.)

* to extend the support of PoP token functionality throughout the entire
solution. This means that we have to include support for a asymmetric
version of PKCE into account (which had been discussed in the group
already earlier already).

* to define at least a TLS-based security security solution for the
communication between the client and the resource server.

* to rethink the work on the application layer security solution. The
HTTP signing draft, which defines the application layer security
solution for use between the client and the resource server, has expired
and we will have to find new authors. I believe we got stuck a bit.
Luckily new persons came along and volunteered to help, namely Fredrik
Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
whether a newly developed application layer security solution is
promising. My impression is that it is a very difficult to come up with
a solution that satisfies the security requirements and, at the same
time, also takes the deployment status of proxies and other middleware
into account.

* to make a decision about other extensions. Nat and Kepeng submitted
the Sender Constrained JWT for OAuth2 2.0 document, see
We asked the working group for feedback during IETF #93 and we couldn't
get enough feedback at that time. Please give us feedback whether you
are interested in exploring that solution direction as part of this
process. Today, we don't have enough indication of interest for working
on that solution direction.

Before making any changes to the PoP document set we would like to hear
your thoughts.