To: Justin Richer <jricher@mit.edu>
References: <569E21DA.30002@gmx.net>
 <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56B3A313.9000006@gmx.net>
Date: Thu, 4 Feb 2016 20:14:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="WNWqvGqS01gSPNndq0lx24MEQrJJUjCaH"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/MUQDYKQGLPP2mKi9uC-YOj0uD1Q>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WNWqvGqS01gSPNndq0lx24MEQrJJUjCaH
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Justin,

you have not been removed from the author list of the HTTP signing
draft. Unfortunate wording in my mail below may have given you that
impression but I would like to bring some additional people on board who
expressed interest.

As you know, it is also great if we get new people to volunteer to do
work when we get stuck.

Since there needs to be "space" on the author list I would at least
remove myself from the author list of the HTTP signing document.

Ciao
Hannes

PS: I saw your post regarding the PoP implementation. Thanks for doing
that work. It is highly appreciated!

On 01/19/2016 05:34 PM, Justin Richer wrote:
> Well that=E2=80=99s interesting: I was unaware I was being removed as t=
he author
> of the HTTP signing draft. This is especially surprising after the
> presentation I gave at Yokohama about this topic. The draft hasn=E2=80=99=
t been
> updated because there=E2=80=99s not really been any discussion on it he=
re in the
> group to drive an update, and I=E2=80=99m not one to artificially publi=
sh a new
> draft with the same content and a new date just to avoid the =E2=80=9Ce=
xpired=E2=80=9D
> tag in the repository.=20
>=20
> To see the direction I proposed that we go in at Yokohama, check my
> slides here:
>=20
> https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf
>=20
> Again, I got no real feedback on this and there was no discussion on th=
e
> list. Even so, I=E2=80=99m implementing this in a Node.js application a=
nyway
> that I plan to post back to the group here when it=E2=80=99s done.=20
>=20
>  =E2=80=94 Justin
>=20
>> On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig
>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>
>> Hi all,
>>
>> I wanted to drop a high level message about possible next steps for th=
e
>> 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 ha=
d
>> asked Kathleen to delay the publication given that we ran into scoping=

>> issues, as discussed on the list. See
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>>
>> 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 case=
s
>> where an attacker can just obtain attack other parts of the system
>> instead (for example, by obtaining an bearer-based refresh token to th=
en
>> 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 securit=
y
>> 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 enti=
re
>> 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 expir=
ed
>> 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 jud=
ge
>> whether a newly developed application layer security solution is
>> promising. My impression is that it is a very difficult to come up wit=
h
>> 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
>> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>> 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 workin=
g
>> on that solution direction.
>>
>> Before making any changes to the PoP document set we would like to hea=
r
>> your thoughts.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--WNWqvGqS01gSPNndq0lx24MEQrJJUjCaH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJWs6MTAAoJEGhJURNOOiAtTkwH/1exUPyRdF4W6ADNJipMWfZ+
yZIbTQVxArNZHS19jYyAVwoLjIwVIJJVclc+034CR627jeDyaLFVVdrIE4zCVjyl
Zy5ghit64XRbflYzSZugR5iLAdMjDLZs/24sweKRkDukz9dLkHmsv9qfiVU1uKs2
HNRXYoS/EghgKxVBwadBitaZxyMSa83Y9zXsYK+pZD/dzKYSONbySDzyvXK2TUeE
DwmosCGBtLcTc3srDT1PmGDD8fYSa0Rywwa/sDdOqRSVTmQ9Q2xhjGgohSZwfepH
+cejFe0EQENV+3LHRsQO0iezGLkuhL7znNJMOiRrKDjlm9l/vJy/E1YZdPF0AV8=
=ouki
-----END PGP SIGNATURE-----

--WNWqvGqS01gSPNndq0lx24MEQrJJUjCaH--