idnits 2.17.1 draft-jordan-jws-ct-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 January 2021) is 1193 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Jordan, Ed. 3 Internet-Draft Broadcom 4 Intended status: Informational S. Erdtman 5 Expires: 16 July 2021 Spotify AB 6 A. Rundgren 7 Independent 8 12 January 2021 10 JWS Clear Text JSON Signature Option (JWS/CT) 11 draft-jordan-jws-ct-01 13 Abstract 15 This document describes a method for extending the scope of the JSON 16 Web Signature (JWS) standard, called JWS/CT. By combining the 17 detached mode of JWS with the JSON Canonicalization Scheme (JCS), 18 JWS/CT enables JSON objects to remain in the JSON format after being 19 signed (aka "Clear Text" signing). In addition to supporting a 20 consistent data format, this arrangement also simplifies 21 documentation, debugging, and logging. The ability to embed signed 22 JSON objects in other JSON objects, makes the use of counter- 23 signatures straightforward. 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 16 July 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Signature Creation . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. Create the JSON Object to be Signed . . . . . . . . . 4 60 3.1.2. Canonicalize the JSON Object to be Signed . . . . . . 4 61 3.1.3. Generate a JWS String . . . . . . . . . . . . . . . . 5 62 3.1.4. Assemble the Signed JSON Object . . . . . . . . . . . 5 63 3.2. Signature Validation . . . . . . . . . . . . . . . . . . 6 64 3.2.1. Parse the Signed JSON Object . . . . . . . . . . . . 6 65 3.2.2. Fetch the Signature Property String . . . . . . . . . 6 66 3.2.3. Remove the Signature Property String . . . . . . . . 6 67 3.2.4. Canonicalize the Remaining JSON Object . . . . . . . 7 68 3.2.5. Validate the JWS String . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Open-Source Implementations . . . . . . . . . . . . 10 75 Appendix B. JWS/CT Application Notes . . . . . . . . . . . . . . 10 76 B.1. Counter Signatures . . . . . . . . . . . . . . . . . . . 10 77 B.2. Detached Signatures . . . . . . . . . . . . . . . . . . . 11 78 B.3. Array of Signatures . . . . . . . . . . . . . . . . . . . 13 79 Appendix C. Test Vector Using the Ed25519 Algorithm . . . . . . 14 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 81 Document History . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 This specification introduces a method for augmenting data expressed 87 in the JSON [RFC8259] notation, with enveloped signatures, similar to 88 the scheme used in the XML Signature [XMLDSIG] standard. For 89 interoperability reasons this specification constrains JSON objects 90 to the I-JSON [RFC7493] subset. 92 To avoid "reinventing the wheel", this specification leverages the 93 JSON Web Signature (JWS) [RFC7515] standard. 95 By building on the detached mode of JWS in combination with the JSON 96 Canonicalizion Scheme (JCS) [RFC8785], JSON objects to be signed can 97 be kept in the JSON format. This arrangement is here referred to as 98 JWS/CT, where CT stands for "Clear Text" signing. 100 The primary motivations for keeping signed JSON objects in the JSON 101 format include _simplified documentation_, _debugging_, and 102 _logging_, as well as for maintaining a _consistent message 103 structure_. 105 Another target is HTTP-based signature schemes that currently utilize 106 HTTP header values for holding detached signatures. By rather using 107 the method described herein, signed JSON-formatted HTTP requests and 108 responses may be self-contained and thus be _serializable_. The 109 latter facilitates such data to be 111 * stored in databases 112 * passed through intermediaries 113 * embedded in other JSON objects 114 * counter-signed 116 without losing the ability to (at any time) verify signatures. 118 Appendix B outlines different ways to handle multiple signatures 119 including counter-signing using JWS/CT. 121 The intended audiences of this document are JSON tool vendors as well 122 as designers of JSON-based cryptographic solutions. 124 2. Terminology 126 Note that this document is not on the IETF standards track. However, 127 a conformant implementation is supposed to adhere to the specified 128 behavior for security and interoperability reasons. This text uses 129 BCP 14 to describe that necessary behavior. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Detailed Operation 139 This section describes the details related to signing and validating 140 signatures based on this specification. 142 The following characteristics are vital to know for prospective JWS/ 143 CT implementers and users: 145 * With the exception of the reliance on the detached mode described 146 in Appendix F (https://tools.ietf.org/html/rfc7515#appendix-F) of 147 JWS, JWS/CT does not alter the JWS signature creation process, 148 validation process, or format. This means that the contents of 149 JWS headers as well as things related to signature algorithms and 150 cryptographic keys are out of scope for this specification. 152 * JWS/CT exclusively depends on the JWS _Compact Serialization_ 153 mode. 155 * JCS [RFC8785] constrains JSON objects to the I-JSON [RFC7493] 156 subset. 158 The signature creation and signature validation sections feature 159 samples using the "HS256" JOSE algorithm [RFC7518] with a 256-bit key 160 having the following value here expressed as hexadecimal bytes: 162 7f dd 85 1a 3b 9d 2d af c5 f0 d0 00 30 e2 2b 93 43 90 0c d4 2e de 163 49 48 56 8a 4a 2e e6 55 29 1a 165 3.1. Signature Creation 167 The following sub-sections describe how JSON objects can be signed 168 according to the JWS/CT specification. 170 3.1.1. Create the JSON Object to be Signed 172 Create or parse the JSON object to be signed. 174 For illustrating the subsequent operations the following sample 175 object is used: 177 { 178 "statement": "Hello signed world!", 179 "otherProperties": [2000, true] 180 } 182 3.1.2. Canonicalize the JSON Object to be Signed 184 Use the result of the previous step as input to the canonicalization 185 process described in JCS [RFC8785]. 187 Applied to the sample, the following JSON string should be generated: 189 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 190 After encoding the string above in the UTF-8 [UNICODE] format, the 191 following bytes (here in hexadecimal notation) should be generated: 193 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 194 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 195 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 197 3.1.3. Generate a JWS String 199 Use the result of the previous step as "JWS Payload" to the signature 200 process described in https://tools.ietf.org/html/rfc7515#appendix-F 201 of JWS. 203 Note: although it is true that using the "Unencoded Payload" mode of 204 RFC7797 [RFC7797] would eliminate an _internal-only_, base64url 205 encoding step, the performance hit should be marginal for most real- 206 world applications. The current design also makes JWS/CT independent 207 of JWS library support for the ""b64":false" and ""crit":["b64"]" JWS 208 header items required by RFC7797. However, this specification does 209 not in any way prohibit the use RFC7797, it rather leaves it as an 210 _implementer option_. 212 For the sample, the JWS header is assumed to be: 214 {"alg":"HS256"} 216 The resulting JWS string should then after payload removal and using 217 the key specified in Section 3, read as follows: 219 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 221 3.1.4. Assemble the Signed JSON Object 223 Before a complete signed object can be created, a dedicated top-level 224 property for holding the JWS signature string needs to be defined. 225 The only requirement is that this property MUST NOT clash with any 226 other top-level property name. The JWS string itself MUST be 227 supplied as a JSON string argument ("") to the signature property. 229 For the sample, the property name ""signature"" is assumed to be the 230 designated holder of the JWS string. Equipped with a signature 231 property, the JWS string from the previous section, and the original 232 JSON sample, the process above should result in the following, now 233 signed JSON object (with line breaks in the "signature" property for 234 display purposes only): 236 { 237 "statement": "Hello signed world!", 238 "otherProperties": [2000, true], 239 "signature": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 240 DtJeSxH2uLU0DhqQP5Zjw4" 241 } 243 Note: one could equally well apply the signature to the canonicalized 244 version of the JSON object. However, the rearrangement of properties 245 (performed by JCS), may sometimes be considered an issue from a 246 "human" point of view, while computing-wise the order of JSON 247 properties has no impact on the outcome. 249 3.2. Signature Validation 251 The following sub-sections describe how JSON objects signed according 252 to the JWS/CT specification can be validated. 254 3.2.1. Parse the Signed JSON Object 256 Parse the JSON object that is anticipated to be signed. If the 257 parsing is unsuccessful, the operation MUST cause a compliant 258 implementation to terminate with an appropriate error. 260 To illustrate the subsequent operations the signed JSON object 261 featured in Section 3.1.4 is used as sample. 263 3.2.2. Fetch the Signature Property String 265 After successful parsing, retrieve the designated JSON top-level 266 property holding the JWS string. If the property is missing or its 267 argument is not a JSON string (""), the operation MUST cause a 268 compliant implementation to terminate with an appropriate error. 270 For the sample, where the property named ""signature"" is assumed to 271 hold the JWS string, the operation above should return the following 272 string: 274 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 276 3.2.3. Remove the Signature Property String 278 Since the signature is calculated over the actual JSON object data, 279 the designated signature property and its argument MUST be removed 280 from the signed JSON object. 282 If applied to the sample the resulting JSON object should read as 283 follows: 285 { 286 "statement": "Hello signed world!", 287 "otherProperties": [2000, true] 288 } 290 Note: JSON tools usually by default remove whitespace. In addition, 291 the original ordering of properties may not always be honored. 292 However, none of this has (due to the canonicalization performed by 293 JCS), any impact on the result. 295 3.2.4. Canonicalize the Remaining JSON Object 297 Use the result of the previous step as input to the canonicalization 298 process described in JCS [RFC8785]. 300 If applied to the sample the result of the process above should read 301 as follows: 303 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 305 After encoding the string above in the UTF-8 [UNICODE] format, the 306 following bytes (here in hexadecimal notation) should be generated: 308 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 309 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 310 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 312 3.2.5. Validate the JWS String 314 After extracting the detached mode JWS string and canonicalizing the 315 JSON object (to retrieve the "JWS Payload"), the JWS string MUST be 316 restored as described in https://tools.ietf.org/html/ 317 rfc7515#appendix-F of JWS [RFC7515]. The actual JWS validation 318 procedure is not specified here because it is covered by [RFC7515] 319 and also depends on application-specific policies like: 321 * Accepted JWS signature algorithms 322 * Accepted and/or required JWS header elements 323 * Signature key lookup methods 325 If the validation process for some reason fails, the operation MUST 326 cause a compliant implementation to terminate with an appropriate 327 error. 329 For the sample, validation is straightforward since both the 330 algorithm and the key to use are predefined (see Section 3). The 331 input string to a JWS validator should after the process step above 332 read as follows (with line breaks for display purposes only): 334 eyJhbGciOiJIUzI1NiJ9.eyJvdGhlclByb3BlcnRpZXMiOlsyMDAwLHRydWVdLCJzdGF0 335 ZW1lbnQiOiJIZWxsbyBzaWduZWQgd29ybGQhIn0.VHVItCBCb8Q5CI-49imarDtJeSxH2 336 uLU0DhqQP5Zjw4 338 4. IANA Considerations 340 This document has no IANA actions. 342 5. Security Considerations 344 This specification inherits all the security considerations of JWS 345 [RFC7515] and JCS [RFC8785]. 347 In similarity to any other signature specification, it is crucial 348 that signatures are verified before acting on the signed payload. 350 However, poorly tested software components may also introduce 351 security issues. Consider the following JSON example: 353 { 354 "fromAccount": "1234", 355 "toAccount": "4567", 356 "amount": { 357 "value": 100, 358 "currency":"USD" 359 } 360 } 362 A non-compliant JCS implementation could return 364 {"amount":{},"fromAccount":"1234","toAccount":"4567"} 366 giving an attacker the ability to change ""amount"" to whatever it 367 wants. Note though that this attack presumes that the consumer and 368 producer use implementations broken in the same way, otherwise the 369 signature would not validate. 371 For usage in a wider community, the name of the designated signature 372 property becomes a critical factor that MUST be documented and 373 communicated. However, in a properly designed system, a faulty or 374 missing signature MUST "only" lead to failed operation, and not to a 375 security breach. 377 6. References 379 6.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 387 DOI 10.17487/RFC7493, March 2015, 388 . 390 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 391 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 392 2015, . 394 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 395 DOI 10.17487/RFC7518, May 2015, 396 . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 403 Interchange Format", STD 90, RFC 8259, 404 DOI 10.17487/RFC8259, December 2017, 405 . 407 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON 408 Canonicalization Scheme (JCS)", RFC 8785, 409 DOI 10.17487/RFC8785, June 2020, 410 . 412 [UNICODE] The Unicode Consortium, "The Unicode Standard", 413 . 415 6.2. Informative References 417 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 418 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 419 . 421 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 422 DOI 10.17487/RFC7517, May 2015, 423 . 425 [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload 426 Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, 427 . 429 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 430 and Signatures in JSON Object Signing and Encryption 431 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 432 . 434 [SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 435 2015, . 438 [XMLDSIG] W3C, "XML Signature Syntax and Processing Version 1.1", 439 W3C Recommendation, April 2013, 440 . 442 Appendix A. Open-Source Implementations 444 Due to the simplicity of this specification, there is hardly a need 445 for specific support software. However, JCS which is (at the time of 446 writing), a relatively new design, may be fetched as a separate 447 component for multiple platforms. The following open-source 448 implementations have been verified to be compatible with JCS: 450 * JavaScript: 452 * Java: 455 * Go: 458 * .NET/C#: 461 * Python: 464 Appendix B. JWS/CT Application Notes 466 The following application notes are not a part of the JWS/CT core; 467 they show how JWS/CT can be used in contexts involving multiple 468 signatures. 470 B.1. Counter Signatures 472 Consider the following JWS/CT object showing an imaginary real estate 473 business record: 475 { 476 "gps": [38.89768255588178, -77.03658644893932], 477 "object": {"type": "house", "price": "$635,000"}, 478 "role": "buyer", 479 "name": "John Smith", 480 "timeStamp": "2020-11-08T13:56:08Z", 481 "signature": "<>" 482 } 484 Adding a notary signature on top of this could be performed by 485 embedding the former object as follows: 487 { 488 "attesting": { 489 "gps": [38.89768255588178, -77.03658644893932], 490 "object": {"type": "house", "price": "$635,000"}, 491 "role": "buyer", 492 "name": "John Smith", 493 "timeStamp": "2020-11-08T13:56:08Z", 494 "signature": "<>" 495 }, 496 "role": "notary", 497 "name": "Carol Lombardi-Jones", 498 "timeStamp": "2020-11-08T13:58:42Z", 499 "signature": "<>" 500 } 502 A side effect of this arrangement is that the notary's signature 503 signs not only the notary data, but the buyer's data and signature as 504 well. In most cases this way of adding signatures is advantageous 505 since it maintains the actual order of signing events which also 506 cannot be tampered with without invalidating the outermost signature. 508 Note that all properties above including ""signature"" are 509 application specific. 511 B.2. Detached Signatures 513 In the case the signing entities are "peers" or are unrelated to each 514 other, counter-signatures like described in Appendix B.1 are not 515 applicable since they presume a specific flow. For supporting 516 _independent_ or _asynchronous_ signers targeting a common document 517 or data object, an imaginable solution is using a scheme where each 518 signer rather calculates a hash of the target document/data and 519 includes the hash with the signer-specific meta data like the 520 following: 522 { 524 <> 526 "signers": [{ 527 "sha256": "<>", 529 <> 531 "signature": "<>" 532 },{ 533 "sha256": "<>", 535 <> 537 "signature": "<>" 538 }] 539 } 541 In this case the object to sign would not be limited to JSON; it 542 could for example be a PDF document hosted on a specific URL. Note 543 that the relying party would have to update the structure for each 544 signature received. In some cases a database would probably be more 545 useful for holding individual signatures since a database can cope 546 with any number of signers as well as keeping track of who have 547 actually signed. The latter is crucial for things like international 548 treaties and company board statements. 550 Note that ""signers"", ""sha256"", and ""signature"" are application 551 specific property names. 553 The following sample shows a possible signature object (with line 554 breaks in the signature strings for display purposes only): 556 { 557 "statement": "Hello signed world!", 558 "otherProperties": [2000, true], 559 "signers": [{ 560 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 561 "timeStamp": "2020-11-18T07:45:28Z", 562 "name": "Jane Doe", 563 "signature": "eyJhbGciOiJIUzI1NiJ9..57zPdGh88IgI9kECb1u3O 564 Rhjrbe5mZP4wetM2QCoCBM" 565 },{ 566 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 567 "timeStamp": "2020-11-18T08:03:40Z", 568 "name": "John Doe", 569 "signature": "eyJhbGciOiJFZERTQSJ9..OQLwF9XHtLru0GYMkG-WS 570 dSdqJkQ-jxTqLJXtV8dqruJe1DVsBLI8ok0IZu8jXibZPow5W1hbBmdYJAYCu5hCA" 571 }] 572 } 574 Notes: 576 * "Jane Doe" used the sample key from Section 3 while "John Doe" 577 used the sample key specified in Appendix C. 579 * The ""sha256"" properties hold base64url-encoded [RFC4648], 580 SHA256-hashes [SHS] of the canonicalized data created in 581 Section 3.1.2. 583 B.3. Array of Signatures 585 Another possibility supporting _multiple and independent_ signatures 586 is collecting JWS signature strings in a JSON array object according 587 to the following scheme: 589 { 591 <> 593 "<>": ["<>", 594 "<>", 595 . 596 "<>"] 597 } 599 Processing would follow Section 3, with the addition that each 600 signature is dealt with individually. 602 Compared to Appendix B.2, signature arrays imply that possible 603 signer-specific meta-data is supplied as JWS extensions in the 604 associated signature's base64url-encoded header. 606 By combining the sample used in Section 3 with the test vector in 607 Appendix C, a valid signature array object could be as follows (with 608 line breaks in the signature strings for display purposes only): 610 { 611 "statement": "Hello signed world!", 612 "otherProperties": [2000, true], 613 "signatures": ["eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 614 DtJeSxH2uLU0DhqQP5Zjw4", 615 "eyJhbGciOiJFZERTQSJ9..WAyfK782CRkJh4hcP-OQ3 616 qUYpH6xY3vfFhaRSzNgG5Eu4p54SyTX25-HjNRN8qE5hmMovd8tycp6I9uqRofiBg"] 617 } 619 Note that ""signatures"" is not a key word, it was only selected to 620 highlight the fact that there are multiple signatures. 622 Appendix C. Test Vector Using the Ed25519 Algorithm 624 This appendix shows how a signed version of the JSON sample object in 625 Section 3.1.1 would look like if applying the "Ed25519" algorithm 626 described in RFC 8037 [RFC8037] (with line breaks in the "signature" 627 property for display purposes only): 629 { 630 "statement": "Hello signed world!", 631 "otherProperties": [2000, true], 632 "signature": "eyJhbGciOiJFZERTQSJ9..WAyfK782CRkJh4hcP-OQ3 633 qUYpH6xY3vfFhaRSzNgG5Eu4p54SyTX25-HjNRN8qE5hmMovd8tycp6I9uqRofiBg" 634 } 636 The sample above depends on a JWS header holding the algorithm 637 "{"alg":"EdDSA"}", and the following private key, here expressed in 638 the JWK [RFC7517] format: 640 { 641 "kty": "OKP", 642 "crv": "Ed25519", 643 "x": "_kms9bkrbpI1lPLoM2j2gKySS-k89TOuyvgC43dX-Mk", 644 "d": "0flr-6bXs459f9qwAq20Zs3NizTGIEH5_rTDFoumFV4" 645 } 647 Acknowledgements 649 People who have contributed directly and indirectly with valuable 650 input to this specification include Vladimir Dzhuvinov, Freddi Gyara, 651 and Filip Skokan. 653 Document History 655 [[ This section to be removed by the RFC Editor before publication as 656 an RFC ]] 658 Version 00: 660 * Initial publication. 662 Version 01: 664 * Added paragraph to Abstract. 666 * Updated Security Considerations. 668 Authors' Addresses 670 Bret Jordan (editor) 671 Broadcom 672 1320 Ridder Park Drive 673 San Jose, CA 95131 674 United States of America 676 Email: bret.jordan@broadcom.com 678 Samuel Erdtman 679 Spotify AB 680 Birger Jarlsgatan 61, 4tr 681 SE-113 56 Stockholm 682 Sweden 684 Email: erdtman@spotify.com 686 Anders Rundgren 687 Independent 688 Montpellier 689 France 691 Email: anders.rundgren.net@gmail.com 692 URI: https://www.linkedin.com/in/andersrundgren/