RFC 7515
JSON Web Signature (JWS)
Appendix A. JWS Examples
This section provides several examples of JWSs. While the first three examples all represent JSON Web Tokens (JWTs) [JWT], the payload can be any octet sequence, as shown in Appendix A.4.A.1. Example JWS Using HMAC SHA-256
A.1.1. Encoding
The following example JWS Protected Header declares that the data structure is a JWT [JWT] and the JWS Signing Input is secured using the HMAC SHA-256 algorithm. {"typ":"JWT", "alg":"HS256"} To remove potential ambiguities in the representation of the JSON object above, the actual octet sequence representing UTF8(JWS Protected Header) used in this example is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first and second lines, the second line has one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url- encoded JSON object.) {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}
The following octet sequence, which is the UTF-8 representation used
in this example for the JSON object above, is the JWS Payload:
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
Encoding this JWS Payload as BASE64URL(UTF8(JWS Payload)) gives this
value (with line breaks for display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) gives this string (with line breaks for
display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII
representation of above string, is the following octet sequence
(using JSON array notation):
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81,
105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74,
73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51,
77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67,
74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84,
107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100,
72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76,
109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73,
106, 112, 48, 99, 110, 86, 108, 102, 81]
HMACs are generated using keys. This example uses the symmetric key
represented in JSON Web Key [JWK] format below (with line breaks
within values for display purposes only):
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
Running the HMAC SHA-256 algorithm on the JWS Signing Input with this
key yields this JWS Signature octet sequence:
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173,
187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83,
132, 141, 121]
Encoding this JWS Signature as BASE64URL(JWS Signature) gives this
value:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks
for display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
A.1.2. Validating
Since the "alg" Header Parameter is "HS256", we validate the HMAC
SHA-256 value contained in the JWS Signature.
To validate the HMAC value, we repeat the previous process of using
the correct key and the JWS Signing Input (which is the initial
substring of the JWS Compact Serialization representation up until
but not including the second period character) as input to the HMAC
SHA-256 function and then taking the output and determining if it
matches the JWS Signature (which is base64url decoded from the value
encoded in the JWS representation). If it matches exactly, the HMAC
has been validated.
A.2. Example JWS Using RSASSA-PKCS1-v1_5 SHA-256
A.2.1. Encoding
The JWS Protected Header in this example is different from the
previous example in two ways. First, because a different algorithm
is being used, the "alg" value is different. Second, for
illustration purposes only, the optional "typ" (type) Header
Parameter is not used. (This difference is not related to the
algorithm employed.) The JWS Protected Header used is:
{"alg":"RS256"}
The octets representing UTF8(JWS Protected Header) in this example
(using JSON array notation) are:
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJSUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as
in the previous example. Since the BASE64URL(JWS Payload) value will
therefore be the same, its computation is not repeated here.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) gives this string (with line breaks for
display purposes only):
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII
representation of above string, is the following octet sequence:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only): {"kty":"RSA", "n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8 NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ", "e":"AQAB", "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0 BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn 439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ", "p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc", "q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA -njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc", "dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb 34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0", "dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa 7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU", "qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U" }
The RSA private key is then passed to the RSA signing function, which
also takes the hash type, SHA-256, and the JWS Signing Input as
inputs. The result of the digital signature is an octet sequence,
which represents a big-endian integer. In this example, it is:
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69,
243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125,
131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81,
102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69,
229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219,
61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7,
16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31,
190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244,
74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1,
48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129,
253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239,
177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202,
173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157,
105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69,
34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202,
234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90,
193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238,
251, 71]
Encoding the signature as BASE64URL(JWS Signature) produces this
value (with line breaks for display purposes only):
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks
for display purposes only):
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
A.2.2. Validating
Since the "alg" Header Parameter is "RS256", we validate the RSASSA-
PKCS1-v1_5 SHA-256 digital signature contained in the JWS Signature.
Validating the JWS Signature is a bit different from the previous
example. We pass the public key (n, e), the JWS Signature (which is
base64url decoded from the value encoded in the JWS representation),
and the JWS Signing Input (which is the initial substring of the JWS
Compact Serialization representation up until but not including the
second period character) to an RSASSA-PKCS1-v1_5 signature verifier
that has been configured to use the SHA-256 hash function.
A.3. Example JWS Using ECDSA P-256 SHA-256
A.3.1. Encoding
The JWS Protected Header for this example differs from the previous
example because a different algorithm is being used. The JWS
Protected Header used is:
{"alg":"ES256"}
The octets representing UTF8(JWS Protected Header) in this example
(using JSON array notation) are:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJFUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as
in the previous examples. Since the BASE64URL(JWS Payload) value
will therefore be the same, its computation is not repeated here.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) gives this string (with line breaks for
display purposes only):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII
representation of above string, is the following octet sequence:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
This example uses the Elliptic Curve key represented in JSON Web Key
[JWK] format below:
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
The Elliptic Curve Digital Signature Algorithm (ECDSA) private part d
is then passed to an ECDSA signing function, which also takes the
curve type, P-256, the hash type, SHA-256, and the JWS Signing Input
as inputs. The result of the digital signature is the Elliptic Curve
(EC) point (R, S), where R and S are unsigned integers. In this
example, the R and S values, given as octet sequences representing
big-endian integers are:
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
The JWS Signature is the value R || S. Encoding the signature as
BASE64URL(JWS Signature) produces this value (with line breaks for
display purposes only):
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks
for display purposes only):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
A.3.2. Validating
Since the "alg" Header Parameter is "ES256", we validate the ECDSA
P-256 SHA-256 digital signature contained in the JWS Signature.
Validating the JWS Signature is a bit different from the previous
examples. We need to split the 64 member octet sequence of the JWS
Signature (which is base64url decoded from the value encoded in the
JWS representation) into two 32 octet sequences, the first
representing R and the second S. We then pass the public key (x, y),
the signature (R, S), and the JWS Signing Input (which is the initial
substring of the JWS Compact Serialization representation up until
but not including the second period character) to an ECDSA signature verifier that has been configured to use the P-256 curve with the SHA-256 hash function.A.4. Example JWS Using ECDSA P-521 SHA-512
A.4.1. Encoding
The JWS Protected Header for this example differs from the previous example because different ECDSA curves and hash functions are used. The JWS Protected Header used is: {"alg":"ES512"} The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJFUzUxMiJ9 The JWS Payload used in this example is the ASCII string "Payload". The representation of this string is the following octet sequence: [80, 97, 121, 108, 111, 97, 100] Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value: UGF5bG9hZA Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string: eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
This example uses the Elliptic Curve key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only): {"kty":"EC", "crv":"P-521", "x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_ NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk", "y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2", "d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA xerEzgdRhajnu0ferB0d53vM9mE15j2C" } The ECDSA private part d is then passed to an ECDSA signing function, which also takes the curve type, P-521, the hash type, SHA-512, and the JWS Signing Input as inputs. The result of the digital signature is the EC point (R, S), where R and S are unsigned integers. In this example, the R and S values, given as octet sequences representing big-endian integers are: +--------+----------------------------------------------------------+ | Result | Value | | Name | | +--------+----------------------------------------------------------+ | R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, | | | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, | | | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, | | | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, | | | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, | | | 206, 209, 172, 63, 237, 119, 109] | | S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, | | | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, | | | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, | | | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, | | | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, | | | 188, 222, 59, 242, 103] | +--------+----------------------------------------------------------+ The JWS Signature is the value R || S. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only): AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks
for display purposes only):
eyJhbGciOiJFUzUxMiJ9
.
UGF5bG9hZA
.
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
A.4.2. Validating
Since the "alg" Header Parameter is "ES512", we validate the ECDSA
P-521 SHA-512 digital signature contained in the JWS Signature.
Validating this JWS Signature is very similar to the previous
example. We need to split the 132-member octet sequence of the JWS
Signature into two 66-octet sequences, the first representing R and
the second S. We then pass the public key (x, y), the signature (R,
S), and the JWS Signing Input to an ECDSA signature verifier that has
been configured to use the P-521 curve with the SHA-512 hash
function.
A.5. Example Unsecured JWS
The following example JWS Protected Header declares that the encoded
object is an Unsecured JWS:
{"alg":"none"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJub25lIn0
The JWS Payload used in this example, which follows, is the same as
in the previous examples. Since the BASE64URL(JWS Payload) value
will therefore be the same, its computation is not repeated here.
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The JWS Signature is the empty octet string and BASE64URL(JWS
Signature) is the empty string.
Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks
for display purposes only):
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
A.6. Example JWS Using General JWS JSON Serialization
This section contains an example using the general JWS JSON
Serialization syntax. This example demonstrates the capability for
conveying multiple digital signatures and/or MACs for the same
payload.
The JWS Payload used in this example is the same as that used in the
examples in Appendix A.2 and Appendix A.3 (with line breaks for
display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Two digital signatures are used in this example: the first using
RSASSA-PKCS1-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256.
For the first, the JWS Protected Header and key are the same as in
Appendix A.2, resulting in the same JWS Signature value; therefore,
its computation is not repeated here. For the second, the JWS
Protected Header and key are the same as in Appendix A.3, resulting
in the same JWS Signature value; therefore, its computation is not
repeated here.
A.6.1. JWS Per-Signature Protected Headers
The JWS Protected Header value used for the first signature is:
{"alg":"RS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJSUzI1NiJ9
The JWS Protected Header value used for the second signature is:
{"alg":"ES256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJFUzI1NiJ9
A.6.2. JWS Per-Signature Unprotected Headers
Key ID values are supplied for both keys using per-signature Header
Parameters. The two JWS Unprotected Header values used to represent
these key IDs are:
{"kid":"2010-12-29"}
and
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. Complete JOSE Header Values
Combining the JWS Protected Header and JWS Unprotected Header values
supplied, the JOSE Header values used for the first and second
signatures, respectively, are:
{"alg":"RS256",
"kid":"2010-12-29"}
and
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.4. Complete JWS JSON Serialization Representation
The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only): { "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", "signatures":[ {"protected":"eyJhbGciOiJSUzI1NiJ9", "header": {"kid":"2010-12-29"}, "signature": "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"}, {"protected":"eyJhbGciOiJFUzI1NiJ9", "header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}, "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS lSApmWQxfKTUJqPP3-Kg6NU1Q"}] }
A.7. Example JWS Using Flattened JWS JSON Serialization
This section contains an example using the flattened JWS JSON Serialization syntax. This example demonstrates the capability for conveying a single digital signature or MAC in a flattened JSON structure. The values in this example are the same as those in the second signature of the previous example in Appendix A.6. The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only): { "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", "protected":"eyJhbGciOiJFUzI1NiJ9", "header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}, "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS lSApmWQxfKTUJqPP3-Kg6NU1Q" }
Appendix B. "x5c" (X.509 Certificate Chain) Example
The JSON array below is an example of a certificate chain that could be used as the value of an "x5c" (X.509 certificate chain) Header Parameter, per Section 4.1.6 (with line breaks within values for display purposes only): ["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2 8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo 7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2 RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL 5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9 p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ EjYx8WnM25sgVjOuH0aBsXBTWVU+4=", "MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb 24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux 6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
Appendix C. Notes on Implementing base64url Encoding without Padding
This appendix describes how to implement base64url encoding and decoding functions without padding based upon standard base64 encoding and decoding functions that do use padding. To be concrete, example C# code implementing these functions is shown below. Similar code could be used in other languages. static string base64urlencode(byte [] arg) { string s = Convert.ToBase64String(arg); // Regular base64 encoder s = s.Split('=')[0]; // Remove any trailing '='s s = s.Replace('+', '-'); // 62nd char of encoding s = s.Replace('/', '_'); // 63rd char of encoding return s; } static byte [] base64urldecode(string arg) { string s = arg; s = s.Replace('-', '+'); // 62nd char of encoding s = s.Replace('_', '/'); // 63rd char of encoding switch (s.Length % 4) // Pad with trailing '='s { case 0: break; // No pad chars in this case case 2: s += "=="; break; // Two pad chars case 3: s += "="; break; // One pad char default: throw new System.Exception( "Illegal base64url string!"); } return Convert.FromBase64String(s); // Standard base64 decoder } As per the example code above, the number of '=' padding characters that needs to be added to the end of a base64url-encoded string without padding to turn it into one with padding is a deterministic function of the length of the encoded string. Specifically, if the length mod 4 is 0, no padding is added; if the length mod 4 is 2, two '=' padding characters are added; if the length mod 4 is 3, one '=' padding character is added; if the length mod 4 is 1, the input is malformed.
An example correspondence between unencoded and encoded values follows. The octet sequence below encodes into the string below, which when decoded, reproduces the octet sequence. 3 236 255 224 193 A-z_4MEAppendix D. Notes on Key Selection
This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS or for selecting the key to be used to decrypt a JWE. This guidance describes a family of possible algorithms rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6. These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may include: * Keys supplied by the application protocol being used. * Keys referenced by the "jku" (JWK Set URL) Header Parameter. * The key provided by the "jwk" (JSON Web Key) Header Parameter. * The key referenced by the "x5u" (X.509 URL) Header Parameter. * The key provided by the "x5c" (X.509 certificate chain) Header Parameter. * Other applicable keys available to the application.
The order for collecting and trying keys from different key
sources is typically application dependent. For example,
frequently, all keys from a one set of locations, such as local
caches, will be tried before collecting and trying keys from
other locations.
2. Filter the set of collected keys. For instance, some
applications will use only keys referenced by "kid" (key ID) or
"x5t" (X.509 certificate SHA-1 thumbprint) parameters. If the
application uses the JWK "alg" (algorithm), "use" (public key
use), or "key_ops" (key operations) parameters, keys with
inappropriate values of those parameters would be excluded.
Additionally, keys might be filtered to include or exclude keys
with certain other member values in an application-specific
manner. For some applications, no filtering will be applied.
3. Order the set of collected keys. For instance, keys referenced
by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint)
parameters might be tried before keys with neither of these
values. Likewise, keys with certain member values might be
ordered before keys with other member values. For some
applications, no ordering will be applied.
4. Make trust decisions about the keys. Signatures made with keys
not meeting the application's trust criteria would not be
accepted. Such criteria might include, but is not limited to,
the source of the key, whether the TLS certificate validates for
keys retrieved from URLs, whether a key in an X.509 certificate
is backed by a valid certificate chain, and other information
known by the application.
5. Attempt signature or MAC validation for a JWS or decryption of a
JWE with some or all of the collected and possibly filtered and/
or ordered keys. A limit on the number of keys to be tried might
be applied. This process will normally terminate following a
successful validation or decryption.
Note that it is reasonable for some applications to perform signature
or MAC validation prior to making a trust decision about a key, since
keys for which the validation fails need no trust decision.
Appendix E. Negative Test Case for "crit" Header Parameter
Conforming implementations must reject input containing critical extensions that are not understood or cannot be processed. The following JWS must be rejected by all implementations, because it uses an extension Header Parameter name "http://example.invalid/ UNDEFINED" that they do not understand. Any other similar input, in which the use of the value "http://example.invalid/UNDEFINED" is substituted for any other Header Parameter name not understood by the implementation, must also be rejected. The JWS Protected Header value for this JWS is: {"alg":"none", "crit":["http://example.invalid/UNDEFINED"], "http://example.invalid/UNDEFINED":true } The complete JWS that must be rejected is as follows (with line breaks for display purposes only): eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. RkFJTA.Appendix F. Detached Content
In some contexts, it is useful to integrity-protect content that is not itself contained in a JWS. One way to do this is to create a JWS in the normal fashion using a representation of the content as the payload but then delete the payload representation from the JWS and send this modified object to the recipient rather than the JWS. When using the JWS Compact Serialization, the deletion is accomplished by replacing the second field (which contains BASE64URL(JWS Payload)) value with the empty string; when using the JWS JSON Serialization, the deletion is accomplished by deleting the "payload" member. This method assumes that the recipient can reconstruct the exact payload used in the JWS. To use the modified object, the recipient reconstructs the JWS by re-inserting the payload representation into the modified object and uses the resulting JWS in the usual manner. Note that this method needs no support from JWS libraries, as applications can use this method by modifying the inputs and outputs of standard JWS libraries.
Acknowledgements
Solutions for signing JSON content were previously explored by Magic Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document. Thanks to Axel Nennker for his early implementation and feedback on the JWS and JWE specifications. This specification is the work of the JOSE working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification: Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner. Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.Authors' Addresses
Michael B. Jones Microsoft EMail: mbj@microsoft.com URI: http://self-issued.info/ John Bradley Ping Identity EMail: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/ Nat Sakimura Nomura Research Institute EMail: n-sakimura@nri.co.jp URI: http://nat.sakimura.org/