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

Reply via email to