Re: [jose] JOSE and signed REST requests

[Justin Richer <[e-mail]>]

Or that there will be enough interest in the spec that it will either spur the OAuth working group to finish what it started, or the work will move elsewhere.

 — Justin

> On Aug 2, 2016, at 9:36 AM, Mike Jones <[e-mail]> wrote:
> 
> 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 https://www.ietf.org/proceedings/96/minutes/minutes-96-oauth.
> 
> 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 [mailto:[e-mail]] On Behalf Of Sergey Beryozkin
> Sent: Tuesday, August 2, 2016 4:34 AM
> To: [e-mail]
> 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:
> http://cxf.apache.org/docs/jax-rs-jose.html#JAX-RSJOSE-JOSEJAX-RSFilters
> JWS:
> 
> http://cxf.apache.org/docs/jax-rs-jose.html#JAX-RSJOSE-JWS
> 
> 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:
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02
>> 
>> 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 
>>> REST API.
>>> 
>>> Since my role was "cryptography" I recommended the following approach 
>>> http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-
>>> 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:
>>> https://tools.ietf.org/html/draft-cavage-http-signatures-05
>>> 
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose