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
