tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7515

 
 
 

JSON Web Signature (JWS)

Part 3 of 3, p. 37 to 59
Prev RFC Part

 


prevText      Top      Up      ToC       Page 37 
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}

Top      Up      ToC       Page 38 
   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"
     }

Top      Up      ToC       Page 39 
   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:

Top      Up      ToC       Page 40 
     {"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]

Top      Up      ToC       Page 41 
   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"
     }

Top      Up      ToC       Page 42 
   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

Top      Up      ToC       Page 43 
   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]

Top      Up      ToC       Page 44 
   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

Top      Up      ToC       Page 45 
   (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

Top      Up      ToC       Page 46 
   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]

Top      Up      ToC       Page 47 
   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

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
   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"}

Top      Up      ToC       Page 50 
   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"}

Top      Up      ToC       Page 51 
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"}]
     }

Top      Up      ToC       Page 52 
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"
     }

Top      Up      ToC       Page 53 
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

Top      Up      ToC       Page 54 
       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"]

Top      Up      ToC       Page 55 
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.

Top      Up      ToC       Page 56 
   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_4ME

Appendix 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.

Top      Up      ToC       Page 57 
       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.

Top      Up      ToC       Page 58 
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.

Top      Up      ToC       Page 59 
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/