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 <[email protected]> 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:[email protected]] On Behalf Of Sergey Beryozkin > Sent: Tuesday, August 2, 2016 4:34 AM > To: [email protected] > 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
