Thanks Axel. I'm familiar with naive sign and encrypt issues (hopefully!) As I reflected on my implementation, I have to include other parameters in my payload besides the JWT, so an optimization does not look simple. I can use POST here as well, so size is not as much of an issue as it is with a redirect over GET.
-- Dick On Oct 29, 2012, at 5:10 PM, Axel Nennker <[email protected]> wrote: > An answer not related to the size issue which might be relevant regardless: > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > --Axel > > 2012/10/29 Dick Hardt <[email protected]> > > Let's say we have created a JWE as such: > > > headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritityVectorOne > > This is now the payload to a JWS. Rather than increasing the token size by > 4/3 by URL safe base 64 encoding the payload (since it is already URL safe), > it would be useful to have a JWS header parameter that indicates the payload > was not re-encoded and does not need to be URL safe base 64 decoded. > > As there are more periods than expected in a JWS, decoding would ignore all > periods except the first and last one for separating out the header, payload > and signature. > > The indicating parameter would seem to be either "tip" or "cty". I'm still > confused about the difference between the two parameters, so not sure which > one is appropriate. > > -- Dick > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
