What do others think of this suggestion? To me, it seems that it unnecessary
increases the asymmetry of the JWS JSON Serialization representation.
As it stands in -01, the "payload" member is always a JSON string encoding the
payload. Whether b64 is true or false, it is used as-is (after removing JSON
escaping) in the JWS Signing Input computation. So it's treated uniformly, for
signing purposes.
The only difference that b64 makes is whether one base64url-decodes the string
to extract the actual payload or whether the string is itself the payload.
Adding another field such as "raw" would increase - not decrease - the number
of special cases, because there would be two different places the payload might
be, and new possible inconsistencies would be introduced, such as b64:false in
the header but using "payload" rather than "raw" - an error case that would
then have to be handled. As it is, this inconsistency is not expressible,
which seems preferable.
-- Mike
From: jose [mailto:[email protected]] On Behalf Of Manger, James
Sent: Monday, August 10, 2015 12:07 AM
To: [email protected]
Subject: [jose] "payload" sometimes b64 and sometime raw
With draft-ietf-jose-jws-signing-input-options-01 the "b64" member in the
header changes two things:
1) whether or not the payload bytes are base64url-encoded before being used as
input bytes to the signing algorithm; and
2) whether the "payload" member of a JWS JSON serialization holds the
base64url-encoding of the payload bytes, or a JSON-string-encoding of the
payload Unicode characters.
It would be better if the "b64" member only did the first of these.
A new member of the JWS JSON serialization should be defined for the second
item. For instance, define a member called "pld" or "raw" or "payload2" or
"content" that is a string whose UTF-8-encoding (after removing any JSON
escapes) is the payload bytes.
The draft-ietf-jose-jws-signing-input-options-01 design is particularly poor as
when you look at a JWS JSON serialization you can see the "payload" value but
you cannot tell if it is base64url-encoded or raw until you base64url-decode
the "protected" value to look for a "b64" member.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
