- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 02 Dec 2014 21:53:22 +0100
- To: "David I. Lehn" <dil@lehn.org>
- CC: Richard Barnes <rlb@ipv.sx>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials Community Group <public-credentials@w3.org>
On 2014-12-02 20:34, David I. Lehn wrote: > On Tue, Dec 2, 2014 at 1:29 PM, Anders Rundgren > <anders.rundgren.net@gmail.com> wrote: >> On 2014-12-02 19:09, Richard Barnes wrote: >>> >>> Human-readability is only a very minor part of the objectives here. >>> Base64 deserialization is not a major issue. >> >> >> This departs from the thoughts behind JSON's predecessor, XML. >> >> Anyway, I'm sure many other organizations will use JSON clear-text >> signatures >> (home-brewed though since there is no such standard), particularly since it >> has >> been found out to be compliant with at least the browser parsers. That this >> is the case has a trivial explanation: >> >> Only a bad programmer would design a parser so it would output data >> in a different order than it was supplied in, even if the "standard" >> allowed that. >> > > You've mentioned something like this a few times. Can you clarify or > give a link to details on what context this is in, what platforms you > are targeting, what data you are dealing with, and what algorithms you > are performing on that data? There's a lot of information on this so I don't know really where to start... On https://mobilepki.org/jcs you can test my take on the JSON clear text signature concept, JCS. It also holds a link to a specification. JCS doesn't target a specific platform, it is intended for any application that use information-rich JSON messages like payments although the initial application was something similar to what Richard works with, i.e. security protocols. The cool thing about JCS is that the signature is just another property added to a JSON object; it doesn't change the object in any other way. This is pretty much what XML enveloped signatures have done since around Y2K although with a complexity that requires experts that even today seems to cause substantial interoperability problems: http://lists.w3.org/Archives/Public/public-xmlsec/2014Oct/0003.html Core JCS validation OTOH is trivial and can be done with 20 lines of javascript so the there is no "library" that you necessarily must use. If you know how to use the validate method in a crypto API, then you can validate a JCS. I'm considering upgrading JCS to use JOSE arguments and style. Anders > > -dave >
Received on Tuesday, 2 December 2014 20:53:57 UTC