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 current draft just expired but if we have found interest I would be more than willing to post an update. I was supposed to do so earlier but since it has been hard to find a home for the work (an interested WG) it has not be top of my proirity list. With the potential update we (I and the co authors) intended to do some cleanup and one significant change. We think we should move from ES6 serialization to canonicalization based on draft-rundgren-json-canonicalization-scheme <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01>. After a lot of research and emails we have come to the conclusion that it would be easier to get buy in for this method than to get languages to support ES6 compatible serialization. draft-rundgren-json-canonicalization-scheme has the additional benefit that non-intrusive modifications such as attribute reordering would not make ruin this signature which was the case with ES6 serialization (and we could avoid some minor ES6 quirks). Implementations for the draft-rundgren-json-canonicalization-scheme canonicalization schema is available in JavaScript <https://www.npmjs.com/package/canonicalize>, .NET <https://github.com/cyberphone/json-canonicalization/tree/master/dotnet>, Java <https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>, and Python <https://github.com/cyberphone/json-canonicalization/tree/master/python3>. Anders is currently putting a lot of effort into the canonicalization to make sure it is stable, and it has been reviewed by several people knowledgeable in JSON. When it comes to draft-erdtman-jose-cleartext-jws implementations, I have done one in JavaScript (I modified an existing JOSE implementation in a few hours) and Anders has done a Java implementation (at least). The examples in the specification was created and validated with different implementations. I know canonicalization is a scary thing if you have worked with canonicalization of XML, but I can tell you canonicalization of JSON is not even close to that complex. Best regards //Samuel Erdtman On Mon, Sep 3, 2018 at 3:09 PM, Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > 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. There should also be more and > better software support for that. I don't think we can get around JSON > c10n, if we want to keep the message content in clear text. > > Vladimir > > On 03/09/18 15:27, George Fletcher wrote: > > 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/spec/latest/ > > On 9/3/18 6:23 AM, 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 the draft cavage spec. > > I also share your worry about the potential for things to move back to a > SOAP style of API. > > Having a look at the https://tools.ietf.org/html/dr > aft-ietf-oauth-signed-http-request-03 spec it is quite general purpose, > whereas I'm in favour of something that is explicitly designed for JSON > requests and responses. If there was confidence in the > JSON canonicalisation described in https://tools.ietf.org/html/dr > aft-erdtman-jose-cleartext-jws-00 then this seems to enable APIs to stay > REStful but with the support for self-contained signatures. For many > applications I agree that there will need to be some repetition of values > in the JSON payload that are already in the header, e.g. audience, issuer > and time. But if general purpose HTTP signing is a lost cause, then > "Cleartext JSON Web Signatures" seem the next best thing. > > Dave > > > > > > > On Sat, 1 Sep 2018 at 01:06, Phil Hunt <phil.h...@oracle.com > <mailto:phil.h...@oracle.com> <phil.h...@oracle.com>> wrote: > > Dave, > > I’m not sure this is as useful as one might think - from RFC3230… > > > > 7 <https://tools.ietf.org/html/rfc3230#section-7> > <https://tools.ietf.org/html/rfc3230#section-7> Security > Considerations > > > > This document specifies a data integrity mechanism that protects > HTTP > instance data, but not HTTP entity headers, from certain kinds of > accidental corruption. It is also useful in detecting at least > one > spoofing attack [9 <https://tools.ietf.org/html/rfc3230#ref-9> > <https://tools.ietf.org/html/rfc3230#ref-9>]. However, it is not > intended as general > protection against malicious tampering with HTTP messages. > > The HTTP Digest Access Authentication mechanism [5 > <https://tools.ietf.org/html/rfc3230#ref-5> > <https://tools.ietf.org/html/rfc3230#ref-5>] provides some > protection against malicious tampering. > > > For example, if you have a corporate web proxy or ISP that decides > to help out by doing content compression as an example, all your > requests will start failing (so-called accidental corruption). We > learned from XML that consistent canonicalization of the request > data is important. > > IOW…RFC3230 is valid when it works, but what about all the times > it fails for no apparent reason? (false negatives) > > In my humble experience with REST, the HTTP body is only a small > part of the transaction. The headers, method, and URL parameters > contain all of the semantics to an application transaction. Sure > there are some requests that are just built on HTTP POST. But you > have to be sure, there are no parameters that matter in the > headers or URL. > > The OAuth WG took a big ambitious stab at this (thanks Justin), > but we weren’t convinced implementations would be stable.. > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 > > I can’t help but worry we are headed back to RPC style SOAP like > containers based on JSON tokens that can be signed and that > contain all the semantics and data of a transaction to be signed. > Now that I said that, I’m going to go wash my mouth out. Ugh. > > Phil > > > > On Aug 31, 2018, at 3:05 PM, Dave Tonge > <dave.to...@momentumft.co.uk > <mailto:dave.to...@momentumft.co.uk> <dave.to...@momentumft.co.uk>> > wrote: > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools. > ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8P > Zh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL > cLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s= > y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=> > ) > They then use the draft cavage spec to sign a defined set of > headers which includes the date and digest headers.. > > > If you want attestation, better to use SET or plain JWT. > > The pushback on this has been that to use JWTs for all API > request bodies and responses would make the APIs harder to > develop against and debug. > However I do think it is a better option than having signatures > in headers. I like the idea of using content negotiation to allow > clients to request either application/json or application/jwt > from an API endpoint. > > I'd be interested if there is any interest in the working group > for this draft though: > https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools. > ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext- > 2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap > I_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvD > LnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlL > nfhtq6GZGc0HlswqLcp4OK4&e=> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=> > . > As Ben mentioned, does the issue of JSON canonicalization make > this a non-starter? > > Thanks > > Dave > > > > > -- > Dave Tonge > CTO > Moneyhub Enterprise <http://www.google.com/url?q=h > ttp%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCN > GUnR5opJv5S1uZOVg8aISwPKAv3A> > <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A> > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at fca.org.uk/register > <http://fca.org.uk/register> <http://fca.org.uk/register>. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772 . > Moneyhub Financial Technology Limited 2018 © > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email or > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachments > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company may > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
