Re: [jose] JOSE and signed REST requests

Mike Jones <> Tue, 02 August 2016 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EEFA12D5B7 for <>; Tue, 2 Aug 2016 06:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ovhHpUOKnRQ for <>; Tue, 2 Aug 2016 06:36:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4FD612D5D8 for <>; Tue, 2 Aug 2016 06:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vofo5eHTNc8yMrwSfsrlglDUdn9izQdaYCUXFTlRGQ0=; b=f17V8uNgS8wQdbxwKDQ3vBZB4PZ/XB1Wl1nMEI4/1Tk0eRM0i4kz76x9LbGVmMX6jXdEX/1TYXVDl/lnkWQp9ENAtrAVhvodM3wPMFsFU8cviB4/AoBYEHMjQxwXXnt9j3xzjtPAwG0mW/sYAbwdO4jeNZrvs+cSF1l2INSfzCM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 13:36:01 +0000
Received: from ([]) by ([]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 13:36:01 +0000
From: Mike Jones <>
To: Sergey Beryozkin <>, "" <>
Thread-Topic: [jose] JOSE and signed REST requests
Thread-Index: AQHR7H88+o2b/GgdiU+F4wnJWrvYRqA1fIKAgAAOFACAACC0MA==
Date: Tue, 2 Aug 2016 13:36:01 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: a5811dfb-7679-4441-0627-08d3bad9f1a5
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:tsxYL9i9pfFLHPRxdKxMunLSUyAooRD0HjTpT0ovKAQGfnDCwey9nuhMLeMXPb7QbBiGWWGpMi+/MZNtpDm7+XPXc4sBeLdOvtB3ySBoWEQHIpaHIdwbgHT00w1wmOjrr20zILLFvYjqX8xk0kLeqsi2EBL5/Fp9gjSNwwFThgcj8SMoFoBTyU+jmbRqfK7vB4qlJYMyW9HM54IN75zZYy2FVIAEb7Guiu9itgvINpUIvAnNPkRYsMg0wRYVXF0DyMLmEfHwv/VwYFTZGK8sqAG/q1PnPc3wnZMzyUWw8A7/2A3sfQ+IxkPIYDK6NZycsSOVC4+50eXqO/ANSI4thg==; 5:O5OBcEYgprS2op9P7ZVspEvy4VOwQIU0k26k88dV4WhCIPGV8x0Gh5lmyOzHjtZkegx6DSuj4fNCq/d+0vDRhalovUw7qOInvKxBUVCIS2pw9SFhH4LWU+q2VB2oqEqzXn31fle4Nha+z2Stwky+4w==; 24:cIzGPZxnzvU58RVqCQwjmXoHrorzM2IW6BUUJhROFLum793L9rfc6Ky+X1WQycScaLAshLqFcsiQwuqoL6wX2JxcgXzW7KHZIro9vZf+naI=; 7:0Jn1vKYWPCZylzcHK8j/PQhFLyT0FnpLQ1cBL1YJQfDh3dU+nxRjGD4+Leq/3zbcYQNJBEsmr+oMYMDqQbm7fSgDGRWTpqqplGgVOdiRCP6fi8nxzbeEkFIEmWxawZVKP4QvJ3JcNBPGwWOGxhq2GwV5gymbbMazPBt7VPHtLwIZK5tHHRNbsciPbomkY8hJhtjltYs/Glek+loy1Lxkaf0JOfFRzS3f4gIitGsZBm7KG5V4IGumzxCrW7/9QXuT
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(275133514327357)(236692633408356)(47284530071512);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645;
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(53754006)(13464003)(3660700001)(15975445007)(2900100001)(8676002)(9686002)(76176999)(50986999)(77096005)(11100500001)(81166006)(92566002)(68736007)(105586002)(66066001)(2950100001)(99286002)(87936001)(1720100001)(10090500001)(33656002)(54356999)(86362001)(8990500004)(2906002)(81156014)(5002640100001)(122556002)(86612001)(305945005)(2501003)(19580405001)(5005710100001)(10400500002)(10290500002)(586003)(19580395003)(76576001)(3846002)(7736002)(7696003)(8936002)(97736004)(5001770100001)(74316002)(106116001)(6116002)(102836003)(106356001)(101416001)(107886002)(3280700002)(7846002)(189998001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 13:36:01.1683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645
Archived-At: <>
Subject: Re: [jose] JOSE and signed REST requests
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 13:36:07 -0000

As background, people should be aware that at IETF 96, members of the OAuth working group expressed a preference to abandon work on the OAuth http signing spec or put it on hold.  This discussion and the results are recorded near the end of the minutes at

So anyone considering taking a dependency on this spec should take into account that it will likely never become an RFC.

				-- Mike

-----Original Message-----
From: jose [] On Behalf Of Sergey Beryozkin
Sent: Tuesday, August 2, 2016 4:34 AM
Subject: Re: [jose] JOSE and signed REST requests

Hi Justin, Anders

in Apache CXF we have the filters for signing the outgoing payload.
Short overview:

This is much less complete compared the http-request-02 work but we dpo focus on the integrity of the payload. I think it will be interesting for us to combine the http-request-02 (for ex the optional protection of the headers, etc) with the streaming approach employed to sign the data... Seems like a good opportunity for me to start looking at the the http-request-02/etc work.

Thanks, Sergey

On 02/08/16 13:43, Justin Richer wrote:
> There's also this approach:
> It's more limited than a general HTTP signing mechanism, but as a 
> consequence it's more robust for systems that mess with the HTTP 
> message in transit (which we know happens in the real world).
>  -- Justin
> On 8/2/2016 1:32 AM, Anders Rundgren wrote:
>> Hi All,
>> I was recently involved in an inter-bank payment project based on a 
>> Since my role was "cryptography" I recommended the following approach 
>> requests.html
>> since an operation is defined not only by the message payload, but 
>> also by the HTTP verb, URI, and header parameters.
>> The only related standards effort I'm aware of is this:
>> Unfortunately the methods above get rather awkward if you have a 
>> system where requests are supposed to be embedded in other messages 
>> or just proxied to another server.
>> I would rather have dropped REST in favor of transport-independent 
>> schemes using self-contained JSON-encoded signed message objects.
>> WDYT?
>> Anders
>> _______________________________________________
>> jose mailing list
> _______________________________________________
> jose mailing list

jose mailing list