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 already have the JOSE infrastructure, and I was wondering how we could plug in the c14n. Vladimir On 06/09/18 23:20, Samuel Erdtman wrote: > 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. > > Best regards > //Samuel > > > > On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <sam...@erdtman.se> wrote: > >> 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 an array at the top level >> cleartext_signature attribute one could just do a minor change to existing >> implementations to support cleartext signatures. >> >> On Wed, 5 Sep 2018 at 15:54, Dave Tonge <dave.to...@momentumft.co.uk> >> wrote: >> >>> 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 Erdtman <sam...@erdtman.se> wrote: >>> >>>> 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 >>>> >>>> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
