Re: [jose] JOSE and signed REST requests

[Mike Jones <[e-mail]>]

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