{"alg":{"name":"A128GCM"},"key":{"alg":"A128KW","key":"that"}}
{"enc":        "A128GCM" ,       "alg":"A128KW","kid":"that" }
       ........         . .......                           .

Figure 18

The overhead of this proposed change is thus 17 octets of header, which comes to 20 octets after base64url encoding. So while this does change the header structure – so it will break compatibility with existing implementations – it doesn’t change the overall structure of a JWE, and doesn’t add a dramatic amount of overhead.

In fact, one could argue that this makes the compact form even more flexible. The current compact form has no way to accommodate, for example, the double-wrapped case above. In the revised header structure, the double-wrapped key would still work: The wrapped CMK would be removed to a binary part, and the secondary wrapped key would remain in the header. It would be gigantic, but it would work.

6.5. JWS

The same story makes sense for JWS, with a couple of revisions. First, JWS signatures with asymmetric keys don’t need wrapped keys, so their “key” values would just be a JWK for the public key. (Other metadata parameters, such as “x5c” could live at the same level as the “alg”, and “key” parameters, or in the JWK.) On the other hand, JWS objects that encode MACs could benefit from having wrapped keys in the “key” field.

The second major difference is that for JWS, it is sometimes desirable to store the input to to cryptographic operation (the signed data) in addition to the output (the signature). In the JWE examples above, the “data” field represents the output of the cryptographic operation. So it would be good to define an additional, optional field for JWS, which would contain an octet string for the protected data. If that field were present, the JWS could be process directly; otherwise, it would represent a detached signature.

6.6. Summary

In the above, we’ve described a proposed change to the JWE and JWS headers to move away from a flat bag of parameters, toward a structure with two required fields and two optional fields:

1. REQUIRED: “alg”, containing parameters to describe the algorithm used to process the JWE/JWS object
2. REQUIRED: “key”, containing the key used to process the JWE/JWS, either directly, in wrapped form, or as an ID
3. OPTIONAL: “data”, containing the ciphertext (JWE) or signed data (JWS)
4. OPTIONAL: “mac”, containing the MAC or signature value for the JWE/JWS object

This revised structure doesn’t lose any features relative to the current format, since other header fields like “zip” can still be added to the header. And it imposes low length overhead, in the low tens of octets.

This simpler structure makes it possible to address all of the requirements above with out significant changes to JWE and JWS. In fact, it goes beyond the design goals – instead of having one way to encrypt keys, we have one way to encrypt anything at all.

7. Revised JSON Format and Translation to Compact

In the discussion above, we’ve outlined a JSON structure that provides some richer structure than the current JWE header. This requires us to modify somewhat the mapping between a JSON-serialized JWE or JWS object and its compact encoding. In this section, we describe the mapping in detail for JWE. With a minor change to the JWS compact serializatoin (adding fields for IV and encrypted key, which can be left empty), the same translation can be used for both JWE and JWS.

7.1. Translation from JSON to Compact

Input: JSON object X representing a JWE object in the JSON serialization

• Set the Encoded JWE Encrypted Key to X.key.data. If X.key is not present, set it to the empty string.
• Set the Encoded JWE Initialization Vector to X.alg.iv. If X.alg is not present, set it to the empty string.
• Set the Encoded JWE Ciphertext to X.data
• Set the Encoded JWE Integrity Value to X.mac
• Delete the “data” field from X.key, the “iv” field from X.alg, and the “data” and “mac” fields from X
• Base64url encode the bytes of the UTF-8 representation of the X to create the Encoded JWE Header.
• Assemble the final representation: The Compact Serialization of this result is the concatenation of the Encoded JWE Header, the Encoded JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded JWE Ciphertext, and the Encoded JWE Integrity Value in that order, with the five strings being separated by four period (‘.’) characters.

Output: Text string representing a JWE object in the compact serialization

The following JavaScript functions implement this translation, first for the current JSON serialization and second for the proposed serialization (as described above).

function json2compact_current(obj) {
    var JWE_key  = obj.recipients[0].encrypted_key;
    var JWE_iv   = obj.initialization_vector;
    var JWE_data = obj.ciphertext;
    var JWE_mac  = obj.recipients[0].integrity_value;

    var JWE_header = obj.recipients[0].header;
    
    return [
        JWE_header,
        JWE_key,
        JWE_iv,
        JWE_data,
        JWE_mac
    ].join(".");
}

function json2compact_proposed(obj) {
    var JWE_key  = obj.key.data;
    var JWE_iv   = obj.alg.iv;
    var JWE_data = obj;
    var JWE_mac  = obj.mac;

    delete obj.key.data;   
    delete obj.alg.iv;     
    delete obj.data;       
    delete obj.mac;        
    var JWE_header = base64url(JSON.stringify(obj));

    return [
        JWE_header,
        JWE_key,
        JWE_iv,
        JWE_data,
        JWE_mac
    ].join(".");
}

function compact2json_current(str) {
    var parts = str.split(".");
    var obj = { recipients: [{}], };
    
    obj.recipients[0].header = parts[0];
    obj.recipients[0].encrypted_key = parts[1];
    obj.recipients[0].integrity_value = parts[4];
    obj.initialization_vector = parts[2];
    obj.ciphertext = parts[3];

    return obj;
}

function compact2json_proposed(str) {
    var parts = str.split(".");
    var obj = JSON.parse(parts[0]);

    obj.key.data = parts[1];
    obj.alg.iv   = parts[2];
    obj.data     = parts[3];
    obj.mac      = parts[4];
    
    return obj;
}

JWS Fields     Key     Alg     Hdr
  "alg"                         X
  "jku"                         X
  "jwk"         X
  "x5u"                         X
  "x5t"                         X
  "x5c"                         X
  "kid"         X
  "typ"                         X
  "cty"                         X

JWE Fields     Key     Alg     Hdr
  "alg"                         X
  "enc"         X
  "epk"         X
  "zip"                         X
  "jku"                         X
  "jwk"         X
  "x5u"                         X
  "x5t"                         X
  "x5c"                         X
  "kid"         X
  "typ"                         X
  "cty"                         X
  "apu"                 X
  "apv"                 X
  "epu"                 X
  "epv"                 X

      +--> pub  -----------------------> "kat"
      |
key --+
      |
      +--> priv -> marshal -> encrypt -> "data"

{ "kty": "oct", "k": "cSax0MQz66lGh7hMsgNm8mC+hS+DplWW7o+yUVVIINU=" }

{
    "kty": "EC",
    "crv": "P-256",
    "kid": "1",
    "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
    "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
    "d": "870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE"
}

{
    "kty": "RSA",
    "alg": "RS256",
    "kid": "2011-04-29",
    "n": /* 256 octets */,
    "e": "AQAB",
    "d": /* 256 octets */,
    "p": /* 128 octets */,
    "q": /* 128 octets */,
    "dp": /* 128 octets */,
    "dq": /* 128 octets */,
    "qi": /* 128 octets */,
}

Test Case      1     2     3
             AES    EC   RSA
============================
Baseline      64   186  1648
Simple        88   248  2200
JWKS2         44   180  2066
JWKS3         44   180  1634