Just to add some perspective, if by “flattened” serialization, you mean the compact serializations of JWS (header.payload.signature) and JWE (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge advantages to these, and they’re the only ones that I personally use.
The simplicity gained in processing the compact forms, both in terms of generating and consuming. With the compact forms, you get something that can be dropped on the wire into an HTTP header, form parameter, query parameter, a string in just about any language, all without any quoting or further processing. Plus, to get back to the crypto calculations, you use the literal strings sent across the wire, which is a really nice feature. I’ve personally yet to have a use case that required the multiple signatures or other features of the JSON serialized flavor, nor have I seen much uptake of it in the wild compared to the compact forms. — Justin > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono > <[email protected]> wrote: > > Dear Vladimir, > > yes, we do support the flattened serialisation, but you are right, we > did not mention it in the "feature list". This is mainly because we do > not see any benefit in having this serialisation. We followed the > discussions on it and had own discussions internally. I do not see the > point to define a distinct serialisation which is very close to an > already existing one. This increases complexity only and that's it. The > marginal amount of data reduction coming with the flattened > serialisation is ridiculous in comparison to the JSON serialisation with > only one signature. I personally like the second approach more, since it > still give you the flexibility to add further signatures along the way. > Basically, this is the way our architecture supports multiple > signatures. They are added by the signing parties one after the other. > From our perspective, this is the only realistic use case here. Having a > signing process in possession of multiple distinct private key breaks > with a lot of security principles. At least in my understanding or do I > miss something here!? > > In our architectural approach a JwsDocument is constructed by a JwsMaker > (either from scratch or by parsing an existing one): > > JwsDocument jws = JwsMaker.generate... > > Having such an object, getting a particular serialisation is just a > matter of calling the respective method: > > - Compact: jws.getCompactSerialisation(); > - Compact DETACHED: jws.getCompactDetachedSerialisation(); > - JSON: jws.getJsonSerialisation(); > - JSON PRETTYPRINTED: jws.getJsonSerialisation(true); > - JSON DETACHED: jws.getJsonDetachedSerialisation(); > - JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(true); > - JSON Flattened: jws.getJsonFlattenedSerialisation(); > - JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true); > - JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation(); > - JSON Flattened PRITTYPRINTED & DETACHED: > jws.getJsonFlattenedDetachedSerialisation(true) > > Hope that helps!? > > Do not hesitate to ask further questions. We are happy to help and > further feedback is welcome! > > BR, Luigi. > > > Am 11.03.15 um 17:38 schrieb Vladimir Dzhuvinov: >> Thanks for sharing this. >> >> I see that you support JSON and compact serialisation, but what is >> flattened serialisation? >> >> Thanks, >> >> Vladimir >> >> On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote: >>> Dear all, >>> >>> we developed an own JOSE implementation in Java, mainly because we >>> missed the JSON serialisation in almost all of the available libs. You >>> can grasp it here: >>> >>> http://jw-asterisk.realsoasecurity.de/ >>> >>> We are still doing some polishing, that is why the sources are still >>> lacking. Stay tuned, though, updates will follow soon... >>> >>> The documentation and especially the unit tests should help in taking >>> the first steps. >>> >>> Let us know what you think about it... >>> >>> BR, Luigi. >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> -- >> Vladimir Dzhuvinov :: [email protected] >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
