Re: [jose] JOSE top-level syntax proposal

["Vladimir Dzhuvinov / NimbusDS" <[e-mail]>]

> I think the (nice looking) Nimbus code, for instance, 
> splits on dots, base64url-decodes, interprets as UTF-8, 
> parses as JSON, extracts the "alg" element, looks up 
> the alg value to learn its type... then sees it is an 
> encrypted message and passes the original string to the 
> encryption code (where splitting/decoding/interpreting/
> parsing happens all over again).

Yes, it is indeed so.

An alternative would be to pass both the decoded header 
JSON and the entire raw message (because the raw header is
required for signature verification). I didn't do it
because that would make the subclass APIs more complicated 
and a bit awkward too. 

I don't know how much performance is lost there, however.


> For instance, a web app firewall might perform some 
> sanity checks on the content.

I understand. I think that was your initial concern when
you first brought up the issue.


> Or (if your app accepts unprotected and signed 
> messages), you can convert a signed message to an 
> unprotected one when the signing algorithm is 
> unrecognized. At least that doesn't punish the sender 
> for trying to offer some security (by signing), even 
> if you don't support that algorithm yet.

The current format doesn't make this impossible.


> As a bonus, a message's mode is instantly obvious to 
> developers (without cut 'n pasting a header into a 
> base64url decoding tool).

Yes, this can be handy.


I'm still neutral on this proposal and would like to see
what the others think. In terms of coding to update our
existing library it doesn't seem like much work.


Vladimir