Re: [OAUTH-WG] Future of PoP Work

Justin Richer <jricher@mit.edu> Mon, 24 October 2016 21:58 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C076129A87 for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2016 14:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Level:
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSlwvQEuArw3 for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2016 14:58:24 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56F0129A82 for <oauth@ietf.org>; Mon, 24 Oct 2016 14:58:23 -0700 (PDT)
X-AuditID: 12074424-067ff70000003994-a0-580e83fd1b45
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C3.50.14740.DF38E085; Mon, 24 Oct 2016 17:58:22 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u9OLwK4x004825; Mon, 24 Oct 2016 17:58:21 -0400
Received: from [10.1.150.149] ([208.91.2.4]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u9OLwHBN026462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2016 17:58:19 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_A972F2B0-30A4-4C4B-ADAC-83BCEAFCD372"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <F441C93D-64F4-4D48-8E67-0A6E940C9A21@oracle.com>
Date: Mon, 24 Oct 2016 14:58:16 -0700
Message-Id: <96CE138B-D02A-491F-BEF4-7800201C3CA2@mit.edu>
References: <ef15c42a-e233-e148-4f38-ef7f75333c76@gmx.net> <72315511-98C7-4881-B349-CA32DACA9E96@mit.edu> <CAF2hCbZh2jhVCBBqKexgcNyPj+fBMH5txoQz_7PY9FaY5nXF4w@mail.gmail.com> <4158ACB0-929A-4DDC-B483-3D07D9AA7A5C@oracle.com> <35529A23-97AC-4B69-9544-90E2E8C53755@mit.edu> <F441C93D-64F4-4D48-8E67-0A6E940C9A21@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrvuvmS/CYNFnEYuTb1+xWSyY38hu 8X/pKSYHZo8X//YweixZ8pPJ4+PTWywBzFFcNimpOZllqUX6dglcGXN6JrIV3GphrFi27hp7 A+Otwi5GTg4JAROJHVN2sHYxcnEICbQxSaw4eYMZwtnIKDFzxhx2CGclk8TxWc+ZQVqYBRIk thw4xgRi8wroSWxa/xbMFhbQktg05RwjiM0moCoxfU0LWJxTwE7i0LUFYHEWoPiMvX3sEHO8 Jb68uAk1x0pi4fU/UMsOMkmcnfMOrEFEQEXi29XrjBC3yko8ObmIZQIj/ywkd8xCcgdEXFti 2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopea UrqJERzyLio7GLt7vA8xCnAwKvHwMhjwRQixJpYVV+YeYpTkYFIS5X3aCBTiS8pPqcxILM6I LyrNSS0+xCjBwawkwru3CSjHm5JYWZValA+TkuZgURLnZXD/Gi4kkJ5YkpqdmlqQWgSTleHg UJLgfQvSKFiUmp5akZaZU4KQZuLgBBnOAzSctxlkeHFBYm5xZjpE/hSjLsexuTfWMgmx5OXn pUqJ83qADBIAKcoozYObA0pVF6KZWF4xigO9JcxrBDKKB5jm4Ca9AlrCBLREMJ4HZElJIkJK qoHR9xHLs4CeP3JZ4stC761dI/Jdi1PorsWLh6aqy1ZbNi4sl7B7+zZt22GJ6QfP63gcyTpz 9U9ubdLyPS93lDU+Din0iA2Mz+7UPjWnPVmse2X1lM+XFk42afz0J7Dt9Y518SGf/BefbWfi vG36oHnpg+jgZJvA5fUPCrKtVR9VLPc2uyDKFfFWiaU4I9FQi7moOBEAGPixzTADAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/H2eTMI7UvEC92VLW6bR0zUFWIDQ>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Future of PoP Work
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 24 Oct 2016 21:58:27 -0000

The reason that there’s a lot of discussion on headers and query parameters and not a lot of discussion on the content is that there’s nothing special for signing the body whether it’s XML or JSON or HTML: it’s just a hash of the entity body, sent as the “b” parameter in the JWS. The body is less likely to be transformed than the headers or parameters, and getting into “how to sign XML” or “how to sign JSON” beyond “just take the body as a byte array and hash it” is problematic. I don’t think we want to get into the business of normalization or canonicalization of the message body. 

Keep in mind that this is all for the HTTP *request* from the client and not the HTTP *response* from the RS.

 — Justin

> On Oct 24, 2016, at 1:27 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> Rather than focus on headers and URL param signing, focus on specifying how content is signed in the context of PoP.
> 
> I think there might be a clearer path for example if we new that signing for application/json and application/xml worked well. 
> 
> As we’ve been discussing signing headers and URL params is theoretically do-able, but it probably has more limited use and would remain experimental.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
> 
> 
> 
> 
>> On Oct 24, 2016, at 1:06 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> 
>> You can already sign arbitrary content using a body hash with the current spec.
>> 
>>  — Justin
>> 
>>> On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>> Maybe if we reworked the signing doc so content types like xml and json could be signed?  
>>> 
>>> This would cover for the majority of web api cases. 
>>> 
>>> Wonder what the advice of the http wg would be on this. 
>>> 
>>> Phil
>>> 
>>> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman <samuel@erdtman.se <mailto:samuel@erdtman.se>> wrote:
>>> 
>>>> +1 on doing PoP work in this working group, including HTTP signing/MACing, I don´t think the old HTTP signature document was that far from useful.
>>>> 
>>>> With the ACE work I like when it is possible to just map work done in the OAuth and other working groups to the more optimized protocols. Some would maybe say that it is sub-optimal that the protocol was not initially designed for the constrained environment but I think the benefit of concept validation from web is a bigger plus.
>>>> 
>>>> //Samuel
>>>> 
>>>> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>> I believe that the PoP work should stay in the working group, and that without a usable presentation mechanism such as an HTTP message signature the whole work is pointless. I agree with Mike that we should learn from our own mistakes — and that is precisely the direction that the current HTTP signing draft took. As a result, the base level of functionality is signing the token itself (with a timestamp/nonce) using the key. All of the fiddly HTTP bits that trip people up? Not only are they optional, but it’s explicitly declared what’s covered. Why? Because we’re learning from past mistakes.
>>>> 
>>>> I think that token binding is relying on a lot of “ifs” that aren’t real yet, and if those “ifs” become reality then it will be to the benefit of large internet companies over everyone else. Additionally, token binding in OAuth is far from the simple solution that it’s being sold as. The very nature of an access token goes against the original purpose of tying an artifact to a single presentation channel. OAuth clients in the real world need to be able to deal with multiple resource servers and dynamically deployed APIs, and the token binding protocol fundamentally assumes a world where two machines are talking directly to each other.
>>>> 
>>>> All that said, this working group has consistently shown resistance to solving this problem for many years, so the results of this query don’t at all surprise me.
>>>> 
>>>>  — Justin
>>>> 
>>>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > two questions surfaced at the last IETF meeting, namely
>>>> >
>>>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>>>> > alternatively, do we want to move it over to the ACE working group?
>>>> >
>>>> > 2) Do we want to continue the work on HTTP signing?
>>>> >
>>>> > We would appreciate your input on these two questions.
>>>> >
>>>> > Ciao
>>>> > Hannes & Derek
>>>> >
>>>> > _______________________________________________
>>>> > OAuth mailing list
>>>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>