idnits 2.17.1 draft-erdtman-jose-cleartext-jws-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.rundgren-json-canonicalization-scheme]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2018) is 2052 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-rundgren-json-canonicalization-scheme-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JSON Object Signing and Encryption (JOSE) S. Erdtman 3 Internet-Draft Spotify AB 4 Intended status: Informational A. Rundgren 5 Expires: March 10, 2019 Independent 6 M. Jones 7 Microsoft 8 September 6, 2018 10 Cleartext JSON Web Signature (JWS) 11 draft-erdtman-jose-cleartext-jws-01 13 Abstract 15 Cleartext JSON Web Signature (JWS) is a means of signing JSON objects 16 directly without representing the JSON to be signed in a non-JSON 17 representation, such as base64url-encoded JSON. The signature and 18 information about the signature is added to the JSON object when it 19 is signed. The signature calculation for signing the JSON object 20 uses the JSON canonicalization defined by 21 [I-D.rundgren-json-canonicalization-scheme]. Cleartext JWS builds on 22 the JWS, JWA, and JWK specifications, reusing data structures and 23 semantics from these specifications, where applicable. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 10, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The Signature Object . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Signature Scope . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. The "signature" Header Parameter . . . . . . . . . . . . 5 64 3.3. The "signers" Header Parameter . . . . . . . . . . . . . 5 65 4. Producing and Consuming Cleartext JWSs . . . . . . . . . . . 5 66 4.1. Message Signature or MAC Computation . . . . . . . . . . 5 67 4.2. Message Signature or MAC Validation . . . . . . . . . . . 6 68 4.3. Multiple Signatures . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. JSON Header Parameters Registry . . . . . . . . . . . . . 8 71 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 7.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 77 A.1. Multiple Signatures with Top-Level "alg" Header Parameter 10 78 A.2. Multiple Signatures with Top-Level "crit" Header 79 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 11 80 A.3. Elliptic Curve Key "example.com:p256" . . . . . . . . . . 11 81 A.4. Elliptic Curve Key "example.com:p256-2" . . . . . . . . . 12 82 A.5. RSA Key "example.com:r2048" . . . . . . . . . . . . . . . 12 83 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 84 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 13 85 Appendix D. Document History . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Cleartext JSON Web Signature (JWS) represents a signed JSON object 91 directly as a JSON object [RFC8259], without representing the JSON to 92 be signed in a non-JSON representation, such as base64url-encoded 93 JSON. The signature and information about the signature is added to 94 the JSON object when it is signed. The signature calculation for 95 signing the JSON object uses the JSON canonicalization defined by 96 [I-D.rundgren-json-canonicalization-scheme]. By including the 97 signature information in the JSON object to be signed, it is easy to 98 inspect data in transit and when archived, integrity can be 99 guaranteed. 101 Cleartext JWS builds on the JWS [RFC7515], JWA [RFC7518], and JWK 102 [RFC7517] specifications, reusing data structures and semantics from 103 these specifications, where applicable. Cryptographic algorithm 104 identifiers used by this specification come from the IANA "JSON Web 105 Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. 107 There are three essential differences between Cleartext JWS and JWS: 109 o Cleartext JWS can only sign JSON objects, rather than arbitrary 110 data. 112 o Cleartext JWS signature information is included within the signed 113 data. 115 o Cleartext JWS depends on predictable JSON Serialization, rather 116 than base64url-encoding the data to be signed. 118 The table below is a comparison of JWS and Cleartext JWS: 120 +-------------------------------+----------------+------------------+ 121 | | JWS | Cleartext JWS | 122 +-------------------------------+----------------+------------------+ 123 | Data to be Signed | Arbitrary data | JSON or | 124 | | | JavaScript | 125 | | | objects | 126 | Encoding of Signed Data | Base64url | None | 127 | Encoding of Header Parameters | Base64url | None | 128 | URL Friendly | Core feature | Out of scope | 129 +-------------------------------+----------------+------------------+ 131 In the following example, note that the signature information is 132 included in the JSON object. The members in the 133 "__cleartext_signature" object are the JWS Header Parameters for the 134 signature. The "signature" member contains the base64url-encoded 135 signature value. (Line breaks within values are for display purposes 136 only.) 137 { 138 "iss": "joe", 139 "exp": 1300819380, 140 "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/", 141 "numbers": [1e+30,4.5,6], 142 "__cleartext_signature": { 143 "alg": "ES256", 144 "kid": "example.com:p256", 145 "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI 146 AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHHZjsYdT96JZw" 147 } 148 } 150 The key in Appendix A.3 can be used for verifying the example 151 signature. 153 Note: Recreating the example signature using the example private key 154 would normally result in a different "signature" value since ECDSA 155 includes random data in the signature calculation. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 3. The Signature Object 167 When signing JSON data with Cleartext JWS, a JSON object with the JWS 168 Header Parameters is created and placed within the JSON data to be 169 signed. In addition to the already defined JWS Header Parameters, 170 Cleartext JWS defines two new Header Parameters: "signature" for the 171 base64url-encoded signature value and "signers" to support multiple 172 signers within the same signature object. 174 The identifier for the Cleartext Signature Object in the JSON data to 175 be signed MUST be "__cleartext_signature", unless the application 176 specifies that a different identifier is to be used. 178 3.1. Signature Scope 180 The scope of a signature (the data that is actually signed) comprises 181 all values including child objects of the signature object except for 182 the "signature" member. If multiple signers are present, only the 183 data pertaining to all signers and the data specific to that signer 184 are included (but not the data specific to other signers). See 185 Section 4.3 for more about the multiple signatures case. 187 3.2. The "signature" Header Parameter 189 The "signature" Header Parameter contains the base64url-encoded JWS 190 Signature as a string. 192 3.3. The "signers" Header Parameter 194 The optional "signers" Header Parameter contains an array of sets of 195 Header Parameters that are specific to each signer, including the 196 "signature" value for each signer. See Section 4.3 for more about 197 the multiple signatures case. 199 4. Producing and Consuming Cleartext JWSs 201 4.1. Message Signature or MAC Computation 203 To create a Cleartext JWS, the following steps are performed. The 204 order of the steps is not significant in cases where there are no 205 dependencies between the inputs and outputs of the steps. 207 1. Create the application specific JSON object to be signed. In 208 this step the JSON should not be canonicalized. 210 2. Create the "__cleartext_signature" object with the Header 211 Parameters to be used and add it as a top-level member to the 212 JSON object to be signed with the key "__cleartext_signature". 214 3. Canonicalize the JOSN object to be signed using the 215 canocalization process defined by 216 [I-D.rundgren-json-canonicalization-scheme]. Let the output of 217 the canonicalization be the cleartext input to the signature 218 algorithm. 220 4. Compute the JWS Signature in the manner defined for the 221 particular algorithm being used over the canonicalize JSON object 222 to be signed. The "alg" (algorithm) Header Parameter MUST be 223 present in the "__cleartext_signature" member, with the algorithm 224 value accurately representing the algorithm used to construct the 225 JWS Signature. 227 5. Add the "signature" member to the signature object 228 (__cleartext_signature) within the original application JSON 229 object. with the value BASE64URL(JWS Signature). 231 4.2. Message Signature or MAC Validation 233 When validating a Cleartext JWS, the following steps are performed. 234 The order of the steps is not significant in cases where there are no 235 dependencies between the inputs and outputs of the steps. If any of 236 the listed steps fails, then the input MUST be rejected. 238 When there are multiple JWS Signature values, it is an application 239 decision which of the JWS Signature values must successfully validate 240 for the Cleartext JWS to be accepted. In some cases, all must 241 successfully validate, or the Cleartext JWS will be considered 242 invalid. In other cases, only a specific JWS Signature value needs 243 to be successfully validated. However, in all cases, at least one 244 JWS Signature value MUST successfully validate, or the Cleartext JWS 245 MUST be considered invalid. 247 1. Parse the application JSON data, including the signature object. 249 2. Verify that the implementation understands and can process all 250 fields that it is required to support, whether required by this 251 specification, by the algorithm being used, or by the "crit" 252 Header Parameter value, and that the values of those parameters 253 are also understood and supported. 255 3. Save and remove the "signature" member from the signature object 256 (__cleartext_signature) and base64url-decode the encoded 257 representation of the JWS Signature. 259 4. Canonicalize the signed object, including the signature object 260 (__cleartext_signature), by following the rules by 261 [I-D.rundgren-json-canonicalization-scheme] and let the output be 262 input to the signature algorithm. 264 5. Validate the JWS Signature against the JWS Signing Input, i.e., 265 the canonicalize data, in the manner defined for the algorithm 266 being used, which MUST be accurately represented by the value of 267 the "alg" (algorithm) Header Parameter value, which MUST be 268 present. Record whether the validation succeeded or not. 270 6. Return a result indicating whether or not the Cleartext JWS was 271 successfully validated. 273 7. For later validation of the signed JSON object, put the 274 "signature" member back into the signature object 275 (__cleartext_signature) within the application JSON object. 277 4.3. Multiple Signatures 279 Multiple signers using different keys can independently add 280 signatures to a JSON object in the manner described in this section. 282 The signature procedure is essentially the same as for single 283 signatures but also includes the following: 285 o There MUST be an additional JWS Header parameter "signers", 286 holding an array of signature objects. 288 o Each signature requires its own canocalization process. During 289 this process, the signature objects for other signatures MUST be 290 (temporarily) removed. 292 o The canonicalized data in the "signers" value MUST include the 293 array brackets ([]) containing the data specific to this signature 294 but MUST NOT include the data for other signatures. The resulting 295 array will be single-valued, with no commas separating additional 296 elements. 298 o A given Header Parameter MUST NOT occur in both the top-level 299 signature object and a signature object within the "signers" 300 value. Any Header Parameter occurring in the top-level signature 301 object applies to all signatures. 303 o A signature object is equivalent to an ordinary signature object, 304 but MAY exclude the "alg" Header parameter if it is present in the 305 top-level signature object itself. If in the top-level signature 306 object, all enclosed signature objects MUST use the same algorithm 307 as well as not including the "alg" Header parameter. See 308 Appendix A.1 for an example. 310 o Likewise, if a "crit" Header parameter is specified in the top- 311 level signature object, it MUST be applied to all signature 312 objects and MUST NOT be present in them individually. See 313 Appendix A.2 for an example. 315 The following example shows a multiply signed object: 317 { 318 "iss": "joe", 319 "exp": 1300819380, 320 "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/", 321 "numbers": [1e+30,4.5,6], 322 "__cleartext_signature": { 323 "signers": [{ 324 "alg": "ES256", 325 "kid": "example.com:p256", 326 "signature": "83gr5rmjKgngLTaPpxuQWiZaQmlQ555jLHNcZLmcBpg 327 X7JZLeqrNhIrQRg3jTsNwh1RuibDYBzCsaxVUkhGEKg" 328 },{ 329 "alg": "RS256", 330 "kid": "example.com:r2048", 331 "signature": "PVQeL8XtjnetambQe98FuMBDuijwWTIFXouyNjL8WX0 332 WvamWkHjv34Iz8VOHHWr9w8t14FXJJuQ22j-h5BR7qP 333 xE7cBVS8XSltR7VvcNidfn-r-TtAVwDwn7Iz_Gk-RI7 334 QIv4ctbreYt1myG64Ikw38OEmNURCxzf9h9w3tvA3R8 335 ZE3MYgELFaQRowSW92JC1HhGZRijzHoIzvH6l_GULP_ 336 hf7kggwFNtRrzN8DLXbhBhGaoP-O0cNZsCWY2hbNU6L 337 7km6bdrqHdq88DSOEGg_-5T6qUsIAYbmCgUK7XBi2q- 338 DRPQZYnxr5570mj9Nkh0hpZ-VfAC2ftbzxFAB7ZYg" 339 }] 340 } 341 } 343 The ECDSA signature can be validated using the key in Appendix A.3 344 and the RSA signature can be validated using the key in Appendix A.5. 346 5. IANA Considerations 348 5.1. JSON Header Parameters Registry 350 This section registers the following Header Parameters in the IANA 351 "JSON Web Signature and Encryption Header Parameters" registry 352 [IANA.JOSE.HeaderParameters]. 354 5.1.1. Registry Contents 356 o Header Parameter Name: "signature" 358 o Header Parameter Description: The base64url-encoded signature 359 value 361 o Header Parameter Usage Location(s): "Cleartext JWS" 363 o Change Controller: IESG 364 o Specification Document(s): Section 3.2 366 o Header Parameter Name: "signers" 368 o Header Parameter Description: List of signature objects, each with 369 a set of Header Parameters and a signature value 371 o Header Parameter Usage Location(s): "Cleartext JWS" 373 o Change Controller: IESG 375 o Specification Document(s): Section 3.3 377 6. Security Considerations 379 The same security considerations apply to this specification as do 380 for JWS [RFC7515]. 382 7. References 384 7.1. Normative References 386 [I-D.rundgren-json-canonicalization-scheme] 387 Rundgren, A., "JSON Canonicalization Scheme (JCS)", draft- 388 rundgren-json-canonicalization-scheme-01 (work in 389 progress), June 2018. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 397 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 398 2015, . 400 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 401 DOI 10.17487/RFC7517, May 2015, 402 . 404 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 405 DOI 10.17487/RFC7518, May 2015, 406 . 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 413 Interchange Format", STD 90, RFC 8259, 414 DOI 10.17487/RFC8259, December 2017, 415 . 417 7.2. Informative References 419 [IANA.JOSE.Algorithms] 420 IANA, "JSON Web Signature and Encryption Algorithms", 421 . 424 [IANA.JOSE.HeaderParameters] 425 IANA, "JSON Web Signature and Encryption Header 426 Parameters", . 429 Appendix A. Test Vectors 431 This section contains a set of test vectors. (Line breaks within 432 values are for display purposes only.) 434 A.1. Multiple Signatures with Top-Level "alg" Header Parameter 436 { 437 "iss": "joe", 438 "exp": 1300819380, 439 "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/", 440 "numbers": [1e+30,4.5,6], 441 "__cleartext_signature": { 442 "alg": "ES256", 443 "signers": [{ 444 "kid": "example.com:p256", 445 "signature": "En1Iyg45g1HBsxYdu-SR1fjt2nixOEtMWRrVA9EO7N8QfZtrs 446 cEfNl0tkIthqKWXGGPNmWKSw9Bc0Cj6kjHMKA" 447 },{ 448 "kid": "example.com:p256-2", 449 "signature": "RVNSVosrweujm36TDq9661oZiORdPMe-A-v-TADFO_mm6ss96 450 QnVP_BqT9kIc7nSlW7lOeMWk5Tq4kL4d3M_Mw" 451 }] 452 } 453 } 454 } 456 The first signature can be verified using the key in Appendix A.3 and 457 the second signature can be verified using the key in Appendix A.4. 459 A.2. Multiple Signatures with Top-Level "crit" Header Parameter 461 { 462 "iss": "joe", 463 "exp": 1300819380, 464 "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/", 465 "numbers": [1e+30,4.5,6], 466 "__cleartext_signature": { 467 "crit": ["otherExt","https://example.com/extension"], 468 "signers": [{ 469 "alg": "ES256", 470 "kid": "example.com:p256", 471 "otherExt": "Other Data", 472 "signature": "S9PqQU5z5zThIGUvErzf7oo8EetiUFEI1v8flisWJzw0HqqY- 473 OuT_pDq1rG4gsSRAFjrazurl4NGyyxcPfeXzw" 474 },{ 475 "alg": "RS256", 476 "kid": "example.com:r2048", 477 "otherExt": "Cool Stuff", 478 "https://example.com/extension": { 479 "life-is-great": true 480 }, 481 "signature": "O-cnYTtgvyGmgX1YMQkcnRE0lnBw1EduMNVpdblKP-Iy0S143 482 BBvXrCQoEW9oTkQm7X9wkJoohWQyU4qvojoxQxmf6GQ0tEXEI 483 HqN7ixkPh_3ySXTl-gKTPiA5UL-GV44AS-k6N71qp8XhLORmU 484 m68UlTWBZaOXL0JTGjsCyGpuwNiAQbx39ZbjabvGq4NfpPIQC 485 2yjx_SKoPMiia54Mp0hz8U_S3oyAmHrG2mKFYrJ7k43aeDHK1 486 RNRu8XrW2w-Ffh4KigpClAq4q272ZSsjizfYPPjW3gqInjMZz 487 Qd8yZj5Bi5vCDcBOEKZMDoog-UzIy8SbZNl85TlkhK70oNRQ" 488 }] 489 } 490 } 492 The first signature can be verified using the key in Appendix A.3 and 493 the second signature can be verified using the key in Appendix A.5. 495 A.3. Elliptic Curve Key "example.com:p256" 497 Elliptic Curve private key, represented as a JWK: 499 { 500 "kid": "example.com:p256", 501 "kty": "EC", 502 "crv": "P-256", 503 "x": "censDzcMEkgiePz6DXB7cDuwFemshAFR90UNVQFCg8Q", 504 "y": "xq8rze6ewG0-eVcSF72J77gKiD0IHnzpwHaU7t6nVeY", 505 "d": "nEsftLbi5u9pI8B0-drEjIuJzQgZie3yeqUR3BwWDl4" 506 } 508 A.4. Elliptic Curve Key "example.com:p256-2" 510 Elliptic Curve private key, represented as a JWK: 512 { 513 "kid": "example.com:p256-2", 514 "kty": "EC", 515 "crv": "P-256", 516 "x": "RgdKcWxBsnqeryzoEv3B5KE9qAQc-nBZEV_A23uQoPs", 517 "y": "73UtZIe1Qfil1WM9Hq1ZiPXWnI1Tu7N__goVvTyjURk", 518 "d": "2jlPu5M9ISDkk-cpPgj6XGvZMhrFUfPujtQy2LtMOss" 519 } 521 A.5. RSA Key "example.com:r2048" 523 RSA private key, represented as a JWK: 525 { 526 "kid": "example.com:r2048", 527 "kty": "RSA", 528 "n": "hFWEXArvaZEpSP5qNX7x4C4Hl28GJQTNvnDwkfqiWs63kXbdyPeS06bz6GnY3 529 tfQ_093nGauWsimqKBmGAGMPtsV83Qxw1OIeO4ujbIIb9pema0qtVqs0MWlHx 530 klZGFkYfAmbuEUFxYDeLDHe0bkkXbSlB7_t8pCSvc8HLgHjEQjYOlFRwjR0D- 531 uLo-xgsCbpmCtYkB5lcT_zFgpRgY4zJNLSv7GZiz2S4Fc5ArGjd34lL47-L8b 532 ozuYjqNOv9sqX0Zgll5XaJ1ndvr7UqZu1xQFgm38reoM3IarBP_SkEFbt_v9i 533 ak602VO3k28fQhMaocP7JWR2YLT3kZM0-WTFw", 534 "e": "AQAB", 535 "d": "Q6iBYpnIrB2mkQZagP1lZuvBv9_osVaSZpLRvKD7DxhvbDTs0coaTJIoVCSB1 536 _VZip8zlUg-TnYWF1Liv9VSwfQ7ddxrcOUtej60mId0ntNz2HhbxJsWjiru8E 537 ZoArl0nEovLDNxlRgRMEyZwOKPC_xHT6nFrk7_s9pR5pEEcubGLAVBKnLCoPd 538 Lr-CBjCvWfJo73W5AZxoSb8MdWQOi5viXHURpr1Y_uBRsMuclovM56Vt05etM 539 sB1AbcTLUDwAuYrZWa1c08ql60ft7b3v6Q_rCL7EHtFU3PHAuP0mV7tM5BfAP 540 f4T0g9pbr4GOw7eqQCiYgPFE7gmCR_PDxv5YQ", 541 "p": "6DIM343hAtj1hQprJaVQ3T8YeIytIQ7Ma544C0A8BX-irjJfARy4fAlTSyBFe 542 auZ0WdbMGtKpAIgNVmfCfuP7W1bXw7UaxpqsQlbw54K1VtBs8xG-lee_2YQ3l 543 UlIiC1at6L0jxWYNkvp-LIfU2F5ZQir5ZWVXwgdMcgoNBABMc", 544 "q": "keacq0goV7pAtG2h33OAk-XOSclIF1agvEMMOKuud5V-vGQ6OaYldlYqZmSGg 545 F7RVlX0GZO70nPqatjd2G-tI8wEq5K_xmLQurUPFW8g___z0CTgJ62KbjFxCt 546 Gny5rsObX9im6cCc_EOtWZRaApzO8ykxfo1QcEjT4k1na7DzE", 547 "dp": "nPmJPnFal2Q5x_GdMlwq6QhI8OaZ_OlWRcM3PFP2v_jj8ERZehUCm8hqKTXu 548 Ai2C1dC8E2XVlj9hqu-l10fcq7Tsurz52laHnpwnD35-8HK7XmRR79jgwuUr 549 rkN90S6vt0ow2La15s-tqiBlTmDkjqqxMGfAghZiktA0PMPNI-0", 550 "dq": "D3c1lkZw2FPK9hVE-m3A7GyIwHOQq8CoCyzER-GS_eQf6hJpxaCiCfg6SF5R 551 j5v9brxvwqJRX46gA7F3WrED1m6S9Cj7ISlqXNBCiBAenGRiUOcHx8zyhpnB 552 FNeChOeoMLnk5V6yNawLbf0kYSgIJkwYvVTkfmhfCCXVO9KcI5E", 553 "qi": "wV0NzfCakfog1NFjtPzcga1MtkpizgPkxcP9LjNdvXW2YQZhM6GIEGjsu3iv 554 TrHrrM-4_bTQHOoTtfIY7wdqBKlwQTJOI0dH9FbNJ4ecGojRwgv83TN8aNKh 555 17Tt44jI5oibs2P-31B_VW9R1wwhnnOuCYpABfoSbtHIoCRme5I" 556 } 558 Appendix B. Acknowledgements 560 This document builds on the work done in the JOSE working group, so a 561 big thanks goes out to all involved in that work. It is specifically 562 inspired by JWS, so special thanks are due to the authors of that 563 document, Michael B. Jones, John Bradley, and Nat Sakimura. 565 Appendix C. Open Issues 567 The following open issues remain to be addressed in this 568 specification. 570 o The signature creation and validation steps for the multiple 571 signatures case needs to be added to Section 4.1 and Section 4.2. 573 Appendix D. Document History 575 [[ to be removed by the RFC Editor before publication as an RFC ]] 577 -01 579 o Changed canocalization from ES6 serialization to 580 [I-D.rundgren-json-canonicalization-scheme]. 582 o "signature object" is now used consistently through out the 583 specification. 585 -00 587 o Initial version. 589 Authors' Addresses 591 Samuel Erdtman 592 Spotify AB 593 Birger Jarlsgatan 61, 4tr 594 Stockholm 113 56 595 Sweden 597 Email: erdtman@spotify.com 599 Anders Rundgren 600 Independent 601 Montpellier 602 France 604 Email: anders.rundgren.net@gmail.com 606 Michael B. Jones 607 Microsoft 609 Email: mbj@microsoft.com 610 URI: http://self-issued.info/