Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt

Bill Mills <> Mon, 22 December 2014 17:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 04A0F1A1B67 for <>; Mon, 22 Dec 2014 09:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8DAbUlS5Ywkv for <>; Mon, 22 Dec 2014 09:21:35 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 595471A1B63 for <>; Mon, 22 Dec 2014 09:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1419268894; bh=PkjwcduW2PXU9h8WMnmqxRrChNfajgOJqjYSiHdO7sM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=X+rv3cn9cO1JiKeJJihgABxMs3sYOI/QTFF0dAnX3wjuqNIe4d05HF4smY6CokPoO6YPE2FAlszleZR4mOFEyHsuctTx+4tzu2EBlodK7amgzA/eS4w7kTlm7So3Id9NVXMeuvn3oV93O4+jIZuhVF1oWpCEvGRyo0XpLzq7E3t0vDjYLkiT754vsbHpmIexvnyvV1R/ErrCBP4zAy+FCEGrQo0Z8ptxleWS3nScyAMVPg+W2nxD/MCT54d2GlFANql1v2zibcnJhv0wRTciQ01XZTtzKTTLxL1HWq+jYEYp/nuDQ9OeRj0EgY53NWULMz2Xpv3Y3yEVlFI0BBRLsQ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;; b=tQFMtYcHqTwC6uN6Tec1R16CL9jaObWMNj5jWo1eIOgc6hQJno25WpQr78df9R7W8h0z0BTTgbRD8WmUS8c7ouO5WvwjoRDBiMbIlxO6ASVlboDqEvTDfCSxp75PxU6PswM+HoHA915hbnIRn3/WmUkHH0sQ1kFatKdCRnqjB4027CPKfWfH4te+vk/VzVKzSbNz6p29b0X6W4gf//qTzGlrgGZA17yr2zg4QPfdTFCEZHPpbvta1WYtW3UR4b2Sbq/xZFtPqATKivtkCBnKFTk+b6GyPaaEMafVZhnqc75tap4g8CDfcmI8az7AJcCswWscIIqFDD88lM9JpIZKtw==;
Received: from [] by with NNFMP; 22 Dec 2014 17:21:34 -0000
Received: from [] by with NNFMP; 22 Dec 2014 17:21:34 -0000
Received: from [] by with NNFMP; 22 Dec 2014 17:21:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: K_DUKL4VM1m3mE2lkWUNtGCwPYsC7tRTRXWvgMsovkpR0Lb7bzeQ9owzrRrnzXn HGHoZLOUut5u7OtHJaEpSbYUub32fXQ2OSlS7ELTozVy3.j.TVguitoRfVh_OqGrFdvfeKL2bsGE r5oblUY3Tru5SPpMFnbRIIV6n_IXrx4bg1LG30HDO50XZTmkybkyczfGHQ3Ps.ceR.3f0jrqTBA5 oGgxGuCLKKZ3yoqraCC7VHFvT2OMsyhDRhxlhjiEKtmetvrXATG1sNvAWprH_hjyY565fuu91NU1 IpK.Mf1ivWZ7F3DEwPCNGaD2FAGnlGhyOTecZ6g54bUeqdIkVaRZBhGXOQEu9mlxMuUD0jeZZzY2 FGOU4uoA2kmWeKP0OZfIyyB0p0nfrx3z_M4f83xCvYnH82hYzqRaXFwGShwK28fampG14plVbQ7i W.udh7YmWq.sjnclULZz5zIfq7mWijBV6dKoxaK_M6qWYpejhb_VraR.Zz8EJeqQv.DJRr2n7soq Vshy64ZjC
Received: by; Mon, 22 Dec 2014 17:21:34 +0000
Date: Mon, 22 Dec 2014 17:21:33 +0000
From: Bill Mills <>
To: "Richer, Justin P." <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_255966_803108743.1419268893759"
Cc: "" <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Dec 2014 17:21:47 -0000

Ah yes, I am remembering vague snatches of that Sunday meeting we had in London.
In 3.1 it states you have to use a hash function of equal size to the JWT wrapper's.  Why don't we just specify that the same function must be used?
Why include a timestamp explicitly here when we could use the Date header?
There's no nonce included in anything here, was that an explicit decision?
How is line continuation handled for header values?  This should probably be explicit about that.
Repeated headers...  "Repeated header names are processed separately with no special handling." this wants to be clearer.  Does this mean you repeated a header name in the list?  (which explicitly should not be allowed).  I think this needs to explicitly say "If a header name is specified then all headers with the same name must be processed for that header.".  The next question is ordering, will any frameworks or proxies re-order headers of the same name?  If so then we probably have to produce a sorted list of headers.  
Do we need to handle repeated parameter values explicitly?  

     On Monday, December 22, 2014 8:26 AM, "Richer, Justin P." <> wrote:

 Yes it did, as part of the PoP suite. It's the current stab at an HTTP presentation mechanism for PoP tokens.
 -- Justin
On Dec 22, 2014, at 11:21 AM, Bill Mills <> wrote:

Did this get adopted as a WG item already and I missed it?

On Monday, December 22, 2014 4:33 AM, Justin Richer <> wrote:

That's easy: any headers. That's why the signer specifies which ones. Would be good to have since guidance tough, and examples. 

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Sergey Beryozkin <>
Date:12/22/2014 7:08 AM (GMT-05:00) 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt 

Hi Justin

I see a fair bit of interest toward this work now being shown from my 
colleagues; it would help if the next draft could clarify which HTTP 
headers can be signed given it is difficult to get hold of some of HTTP 
headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>          Title           : A Method for Signing an HTTP Requests for OAuth
>          Authors         : Justin Richer
>                            John Bradley
>                            Hannes Tschofenig
> Filename        : draft-ietf-oauth-signed-http-request-00.txt
> Pages           : 11
> Date            : 2014-07-21
> Abstract:
>     This document a method for offering data origin authentication and
>     integrity protection of HTTP requests.  To convey the relevant data
>     items in the request a JSON-based encapsulation is used and the JSON
>     Web Signature (JWS) technique is re-used.  JWS offers integrity
>     protection using symmetric as well as asymmetric cryptography.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list