Seems that there is some uncertainty about this "special" serialisation. I would actually vote for replacing the flatened JSON serialisation with one, that provides a real benefit. Taken up on a discussion I read earlier on the list, wouldn't it be more sensible to have a "readable" JSON serialisation (i.e., leaving the signed payload "human readbale")!? This would of course require some form of normalisation/canonicalisaton as used e.g. in XML Security. Still, this would be something valuable to have and a real distinguishing point in comparison to the other serialisations.
If people think that this is worth a discussion, then maybe we should kick-off an explicit thread on it. Another point I would like to raise is to have an additional mandatory header entry specifying the JWS/JWE version used. As the standards will evolve over time, it would be good to know, with what version of the JWS/JWE standards a given object have been protected. BR, Luigi. Am 12.03.15 um 18:20 schrieb Justin Richer: > My bad, I totally missed that. > > -- Justin > > On 3/12/2015 11:38 AM, John Bradley wrote: >> Yes flattened is a special case of the JSON serialization that has >> only one signature. >> >> I don't know that there is a huge benefit to it over the regular JSON >> serialization that supports multiple signatures. >> >> Some people really wanted it at the time. >> >> Supporting the general JSON serialization would be a higher priority >> for me. In most cases I have seen, as Justin points out people >> wanting a single signature go with compact. >> >> John B. >> >> >>> On Mar 12, 2015, at 11:49 AM, Brian Campbell >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> flattened is not the same as compact FWIW >>> >>> compact -> >>> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.1 >>> >>> flattened -> >>> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2 >>> >>> On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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] >>> <mailto:[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] <mailto:[email protected]> >>> >>> https://www.ietf.org/mailman/listinfo/jose >>> >> >>> >> -- >>> >> Vladimir Dzhuvinov :: [email protected] >>> <mailto:[email protected]> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> jose mailing list >>> >> [email protected] <mailto:[email protected]> >>> >> https://www.ietf.org/mailman/listinfo/jose >>> >> >>> > >>> > _______________________________________________ >>> > jose mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/jose >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
