Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Vladimir I have published an implementation created by Anders. You can find it here https://github.com/erdtman/java-json-canonicalization I have tested to add support for this in a JavaScript JOSE implementation (node-jose), it was super easy (just hours of work). Best regards On Mon, Sep 10

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, Thanks for the quick update. Factoring out the c14n to a separate independent spec resulted in a much clearer draft. I don't see anything missing in terms of spec have it implemented. Can you suggest a Java library that can handle the c14n (rundgren-json-canonicalization-scheme)? We al

Re: [OAUTH-WG] Non-repudiation for API requests and responses

H Torsten I agree that use use of draft-erdtman-jose-cleartext-jws doesn't support non-repudiation for JSON HTTP requests or responses alone. There was a reference made earlier in the email chain to ACME which requires `url` to be added to the JWT payload, and mention was made that some header par

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Thank you for asking Torsten, If method or URL contains additional information not contained in the request body then it would have to be duplicated into the request to be signed. This may also aplie to headers. I do not necessarily think it would be bad to duplicate this information into the req

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, thanks for preparing this draft. I‘ve got one question: how would one use it for non-reputation? I assume non-reputation would require not only to sign the request body but also (at least) data about the target of the request, typically a URL + HTTP method. Would one need to include

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi, A new version has been submitted. It would awesome if we could get some comments on the draft and thoughts about a potential future adoption. https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 Changes includes the change of canonicalization method and some minor clarifications.

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Thanks James - definitely an interesting case. I'd be sorry to see ACME and other APIs go down the route of POSTing base64 encoded blobs for all API interactions. On Mon, 3 Sep 2018 at 14:56, Manger, James wrote: > ACME > (Automati

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Then I’ll post an update within a ~week. There is one thing that could make implementing even simpler (from my experience). That is how to handle multiple signatures. Today the specification supports sharing of headers between signatures. If signatures instead are completely independent and put in

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, Thanks for the reply, I would definitely be interested in an updated draft. Both the signing spec and the canonicalization spec seem a lot simpler than JSON-LD. It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs Thanks Dave On Tue, 4 Sep 2018 at 23:33, Samuel E

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi As one of the authors of draft-erdtman-jose-cleartext-jws I definitely think this is the way to go. The initial use case was to sign transaction requests and responses, and as was mentioned in previous emails it is very much desirable to not obfuscate the payload with base64 encoding. The curr

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi George, JSON-LD still requires c14n. I opened the particular spec and the c14n job with JSON-LD appears quite complex. The structure of the linked data must also be brought into some particular form. https://json-ld.github.io/normalization/spec/ C10n of plain JSON should be a simpler job. The

Re: [OAUTH-WG] Non-repudiation for API requests and responses

ACME (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the Flattened JSON Serialization with a "url" member in the protected header. It is li

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Dave, On 03/09/18 13:23, Dave Tonge wrote: > Hi Phil > > Thanks again for the helpful reply. > I 100% agree with you about the problem of false negatives with RFC3230. > I am not in favour of the its use and will do my best to highlight these > issues with those who are proposing its use with t

Re: [OAUTH-WG] Non-repudiation for API requests and responses

I'm not a big fan of canonicalization for signatures. In the past it has been brittle, the libraries subject to bugs, and hard for developers to adopt. That said, if no canonicalization is not a requirement, have you checked out JSON-LD? It has embedded signature support. https://json-ld.org/sp

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Phil Thanks again for the helpful reply. I 100% agree with you about the problem of false negatives with RFC3230. I am not in favour of the its use and will do my best to highlight these issues with those who are proposing its use with the draft cavage spec. I also share your worry about the p

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Dave, I’m not sure this is as useful as one might think - from RFC3230… > 7 Security Considerations > >This document specifies a data integrity mechanism that protects HTTP >instance data, but not HTTP entity headers, from certain kinds of >

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Thanks for the replies. You're absolutely right Phil and George - apologies I omitted the digest step from the first email. Both the STET and Berlin Group specs require the use of SHA-256 or SHA-512 digest header as per RFC3230 (https://tools.ietf.org/html/rfc3230) They then use the draft cavage sp

Re: [OAUTH-WG] Non-repudiation for API requests and responses

On 8/31/18 12:15 PM, Phil Hunt wrote: Phil On Aug 31, 2018, at 7:45 AM, Benjamin Kaduk wrote: On Fri, Aug 31, 2018 at 06:56:34AM +0200, Dave Tonge wrote: [snip] In Europe we have a number of standards groups who are defining these APIs on behalf of banks. Unfortunately they are all taking d

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Phil > On Aug 31, 2018, at 7:45 AM, Benjamin Kaduk wrote: > >> On Fri, Aug 31, 2018 at 06:56:34AM +0200, Dave Tonge wrote: >> [snip] >> In Europe we have a number of standards groups who are defining these APIs >> on behalf of banks. Unfortunately they are all taking different approaches >> t

Re: [OAUTH-WG] Non-repudiation for API requests and responses

On Fri, Aug 31, 2018 at 06:56:34AM +0200, Dave Tonge wrote: [snip] > In Europe we have a number of standards groups who are defining these APIs > on behalf of banks. Unfortunately they are all taking different approaches > to this problem - including the use of a draft that I understand isn't on a

[OAUTH-WG] Non-repudiation for API requests and responses

Hi all, I'm working with financial APIs - APIs to initiate payments and APIs to retrieve balances and transactions. May of these APIs are protected by OAuth 2.0 profiles, however there is a requirement to support the signing of API requests and responses for non-repudiation purposes. For example