On 2024-08-07, at 18:19, David Waite <david=40alkaline-solutions....@dmarc.ietf.org> wrote: > > > Sent from my iPhone > >> On Aug 7, 2024, at 8:22 AM, Carsten Bormann <c...@tzi.org> wrote: >> >> On 2024-08-07, at 15:55, Orie Steele <orie@transmute.industries> wrote: >>> >>> JSON serializations might be better stored in databases, since the base64 >>> encoded components can often be stored as binary instead of text... but >>> CBOR would be even better. >> >> It is trivial to define a CBOR-based serialization of the JWP compact form, >> replacing the base-64 armor by a CBOR sequence of strings (or arrays of >> strings for ~). Having both means that one can have a URL-safe form >> (base64url + ./~) and a media-type (CBOR sequence). > > Somewhat off topic, but the latest draft is beared toward expressing the > serialized parts as either octet strings (each protected header) or arrays of > octet strings (payloads, proofs). BASE64URL encoding is a serialization > concern and a detail of dropping binary data (like public key data) into > JSON.
Right, which is why it is nearly trivial to do the CBOR outer encapsulation. (I would prefer to do this in such a way that all formats that use base64url + . + ~ can use the same code to get rid of the outer base64url + . + ~; the _ thing makes this slightly less trivial than it otherwise would be.) If you could supply an example document, I could write those three lines... >> I didn’t manage to write the document yet, but it’s really trivial (and, >> like, three lines of code). >> >> A true CWP would also get rid of base64 throughout the building of inputs >> for the cryptography. > > The discussion points I anticipate will be whether to make the protected > headers JSON or CBOR (more likely, if both should be defined e.g. a > compressed JWP serialization as well as a true CWP), and whether to make the > serialized form based on an overarching array or map. Well, I don’t know about compressed (A CBOR outer encapsulation of those byte strings and arrays would simply be “not expanded”). Again, I think that can best be discussed based on some examples. > I’d certainly prefer to have CWP be part of the same effort, rather than > replicate the effort in another group. I think we have seen how that leads to > having differing capabilities, split attention for reviews and feedback, and > multiple registries. CWT was defined independently of JWT because JWT had been done already three years earlier. We can do a properly joint approach this time, with a JSON-specific variant and a variant without special JSON support added. Grüße, Carsten _______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org