idnits 2.17.1 draft-jordan-jws-ct-00.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 (20 November 2020) is 1247 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: 24 May 2021 Spotify AB 6 A. Rundgren 7 Independent 8 20 November 2020 10 JWS Clear Text JSON Signature Option (JWS/CT) 11 draft-jordan-jws-ct-00 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). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 24 May 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Signature Creation . . . . . . . . . . . . . . . . . . . 4 55 3.1.1. Create the JSON Object to be Signed . . . . . . . . . 4 56 3.1.2. Canonicalize the JSON Object to be Signed . . . . . . 4 57 3.1.3. Generate a JWS String . . . . . . . . . . . . . . . . 5 58 3.1.4. Assemble the Signed JSON Object . . . . . . . . . . . 5 59 3.2. Signature Validation . . . . . . . . . . . . . . . . . . 6 60 3.2.1. Parse the Signed JSON Object . . . . . . . . . . . . 6 61 3.2.2. Fetch the Signature Property String . . . . . . . . . 6 62 3.2.3. Remove the Signature Property String . . . . . . . . 6 63 3.2.4. Canonicalize the Remaining JSON Object . . . . . . . 7 64 3.2.5. Validate the JWS String . . . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Open-Source Implementations . . . . . . . . . . . . 9 71 Appendix B. JWS/CT Application Notes . . . . . . . . . . . . . . 10 72 B.1. Counter Signatures . . . . . . . . . . . . . . . . . . . 10 73 B.2. Detached Signatures . . . . . . . . . . . . . . . . . . . 11 74 B.3. Array of Signatures . . . . . . . . . . . . . . . . . . . 13 75 Appendix C. Test Vector Using the Ed25519 Algorithm . . . . . . 14 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 This specification introduces a method for augmenting data expressed 82 in the JSON [RFC8259] notation, with enveloped signatures, similar to 83 the scheme used in the XML Signature [XMLDSIG] standard. For 84 interoperability reasons this specification constrains JSON objects 85 to the I-JSON [RFC7493] subset. 87 To avoid "reinventing the wheel", this specification leverages the 88 JSON Web Signature (JWS) [RFC7515] standard. 90 By building on the detached mode of JWS in combination with the JSON 91 Canonicalizion Scheme (JCS) [RFC8785], JSON objects to be signed can 92 be kept in the JSON format. This arrangement is here referred to as 93 JWS/CT, where CT stands for "Clear Text" signing. 95 The primary motivations for keeping signed JSON objects in the JSON 96 format include _simplified documentation_, _debugging_, and 97 _logging_, as well as for maintaining a _consistent message 98 structure_. 100 Another target is HTTP-based signature schemes that currently utilize 101 HTTP header values for holding detached signatures. By rather using 102 the method described herein, signed JSON-formatted HTTP requests and 103 responses may be self-contained and thus be _serializable_. The 104 latter facilitates such data to be 106 * stored in databases 107 * passed through intermediaries 108 * embedded in other JSON objects 109 * counter-signed 111 without losing the ability to (at any time) verify signatures. 113 Appendix B outlines different ways to handle multiple signatures 114 including counter-signing using JWS/CT. 116 The intended audiences of this document are JSON tool vendors as well 117 as designers of JSON-based cryptographic solutions. 119 2. Terminology 121 Note that this document is not on the IETF standards track. However, 122 a conformant implementation is supposed to adhere to the specified 123 behavior for security and interoperability reasons. This text uses 124 BCP 14 to describe that necessary behavior. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Detailed Operation 134 This section describes the details related to signing and validating 135 signatures based on this specification. 137 The following characteristics are vital to know for prospective JWS/ 138 CT implementers and users: 140 * With the exception of the reliance on the detached mode described 141 in Appendix F (https://tools.ietf.org/html/rfc7515#appendix-F) of 142 JWS, JWS/CT does not alter the JWS signature creation process, 143 validation process, or format. This means that the contents of 144 JWS headers as well as things related to signature algorithms and 145 cryptographic keys are out of scope for this specification. 147 * JWS/CT exclusively depends on the JWS _Compact Serialization_ 148 mode. 150 * JCS [RFC8785] constrains JSON objects to the I-JSON [RFC7493] 151 subset. 153 The signature creation and signature validation sections feature 154 samples using the "HS256" JOSE algorithm [RFC7518] with a 256-bit key 155 having the following value here expressed as hexadecimal bytes: 157 7f dd 85 1a 3b 9d 2d af c5 f0 d0 00 30 e2 2b 93 43 90 0c d4 2e de 158 49 48 56 8a 4a 2e e6 55 29 1a 160 3.1. Signature Creation 162 The following sub-sections describe how JSON objects can be signed 163 according to the JWS/CT specification. 165 3.1.1. Create the JSON Object to be Signed 167 Create or parse the JSON object to be signed. 169 For illustrating the subsequent operations the following sample 170 object is used: 172 { 173 "statement": "Hello signed world!", 174 "otherProperties": [2000, true] 175 } 177 3.1.2. Canonicalize the JSON Object to be Signed 179 Use the result of the previous step as input to the canonicalization 180 process described in JCS [RFC8785]. 182 Applied to the sample, the following JSON string should be generated: 184 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 186 After encoding the string above in the UTF-8 [UNICODE] format, the 187 following bytes (here in hexadecimal notation) should be generated: 189 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 190 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 191 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 193 3.1.3. Generate a JWS String 195 Use the result of the previous step as "JWS Payload" to the signature 196 process described in https://tools.ietf.org/html/rfc7515#appendix-F 197 of JWS. 199 Note: although it is true that using the "Unencoded Payload" mode of 200 RFC7797 [RFC7797] would eliminate an _internal-only_, base64url 201 encoding step, the performance hit should be marginal for most real- 202 world applications. The current design also makes JWS/CT independent 203 of JWS library support for the ""b64":false" and ""crit":["b64"]" JWS 204 header items required by RFC7797. However, this specification does 205 not in any way prohibit the use RFC7797, it rather leaves it as an 206 _implementer option_. 208 For the sample, the JWS header is assumed to be: 210 {"alg":"HS256"} 212 The resulting JWS string should then after payload removal and using 213 the key specified in Section 3, read as follows: 215 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 217 3.1.4. Assemble the Signed JSON Object 219 Before a complete signed object can be created, a dedicated top-level 220 property for holding the JWS signature string needs to be defined. 221 The only requirement is that this property MUST NOT clash with any 222 other top-level property name. The JWS string itself MUST be 223 supplied as a JSON string argument ("") to the signature property. 225 For the sample, the property name ""signature"" is assumed to be the 226 designated holder of the JWS string. Equipped with a signature 227 property, the JWS string from the previous section, and the original 228 JSON sample, the process above should result in the following, now 229 signed JSON object (with line breaks in the "signature" property for 230 display purposes only): 232 { 233 "statement": "Hello signed world!", 234 "otherProperties": [2000, true], 235 "signature": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 236 DtJeSxH2uLU0DhqQP5Zjw4" 237 } 239 Note: one could equally well apply the signature to the canonicalized 240 version of the JSON object. However, the rearrangement of properties 241 (performed by JCS), may sometimes be considered an issue from a 242 "human" point of view, while computing-wise the order of JSON 243 properties has no impact on the outcome. 245 3.2. Signature Validation 247 The following sub-sections describe how JSON objects signed according 248 to the JWS/CT specification can be validated. 250 3.2.1. Parse the Signed JSON Object 252 Parse the JSON object that is anticipated to be signed. If the 253 parsing is unsuccessful, the operation MUST cause a compliant 254 implementation to terminate with an appropriate error. 256 To illustrate the subsequent operations the signed JSON object 257 featured in Section 3.1.4 is used as sample. 259 3.2.2. Fetch the Signature Property String 261 After successful parsing, retrieve the designated JSON top-level 262 property holding the JWS string. If the property is missing or its 263 argument is not a JSON string (""), the operation MUST cause a 264 compliant implementation to terminate with an appropriate error. 266 For the sample, where the property named ""signature"" is assumed to 267 hold the JWS string, the operation above should return the following 268 string: 270 eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 272 3.2.3. Remove the Signature Property String 274 Since the signature is calculated over the actual JSON object data, 275 the designated signature property and its argument MUST be removed 276 from the signed JSON object. 278 If applied to the sample the resulting JSON object should read as 279 follows: 281 { 282 "statement": "Hello signed world!", 283 "otherProperties": [2000, true] 284 } 286 Note: JSON tools usually by default remove whitespace. In addition, 287 the original ordering of properties may not always be honored. 288 However, none of this has (due to the canonicalization performed by 289 JCS), any impact on the result. 291 3.2.4. Canonicalize the Remaining JSON Object 293 Use the result of the previous step as input to the canonicalization 294 process described in JCS [RFC8785]. 296 If applied to the sample the result of the process above should read 297 as follows: 299 {"otherProperties":[2000,true],"statement":"Hello signed world!"} 301 After encoding the string above in the UTF-8 [UNICODE] format, the 302 following bytes (here in hexadecimal notation) should be generated: 304 7b 22 6f 74 68 65 72 50 72 6f 70 65 72 74 69 65 73 22 3a 5b 32 30 305 30 30 2c 74 72 75 65 5d 2c 22 73 74 61 74 65 6d 65 6e 74 22 3a 22 306 48 65 6c 6c 6f 20 73 69 67 6e 65 64 20 77 6f 72 6c 64 21 22 7d 308 3.2.5. Validate the JWS String 310 After extracting the detached mode JWS string and canonicalizing the 311 JSON object (to retrieve the "JWS Payload"), the JWS string MUST be 312 restored as described in https://tools.ietf.org/html/ 313 rfc7515#appendix-F of JWS [RFC7515]. The actual JWS validation 314 procedure is not specified here because it is covered by [RFC7515] 315 and also depends on application-specific policies like: 317 * Accepted JWS signature algorithms 318 * Accepted and/or required JWS header elements 319 * Signature key lookup methods 321 If the validation process for some reason fails, the operation MUST 322 cause a compliant implementation to terminate with an appropriate 323 error. 325 For the sample, validation is straightforward since both the 326 algorithm and the key to use are predefined (see Section 3). The 327 input string to a JWS validator should after the process step above 328 read as follows (with line breaks for display purposes only): 330 eyJhbGciOiJIUzI1NiJ9.eyJvdGhlclByb3BlcnRpZXMiOlsyMDAwLHRydWVdLCJzdGF0 331 ZW1lbnQiOiJIZWxsbyBzaWduZWQgd29ybGQhIn0.VHVItCBCb8Q5CI-49imarDtJeSxH2 332 uLU0DhqQP5Zjw4 334 4. IANA Considerations 336 This document has no IANA actions. 338 5. Security Considerations 340 This specification inherits all the security considerations of JWS 341 [RFC7515] and JCS [RFC8785]. 343 In similarity to any other signature specification, it is crucial 344 that signatures are verified before acting on the signed payload. 346 For usage in a wider community, the name of the designated signature 347 property becomes a critical factor that MUST be documented and 348 communicated. However, in a properly designed system, a faulty or 349 missing signature MUST "only" lead to failed operation, and not to a 350 security breach. 352 6. References 354 6.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 362 DOI 10.17487/RFC7493, March 2015, 363 . 365 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 366 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 367 2015, . 369 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 370 DOI 10.17487/RFC7518, May 2015, 371 . 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 375 May 2017, . 377 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 378 Interchange Format", STD 90, RFC 8259, 379 DOI 10.17487/RFC8259, December 2017, 380 . 382 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON 383 Canonicalization Scheme (JCS)", RFC 8785, 384 DOI 10.17487/RFC8785, June 2020, 385 . 387 [UNICODE] The Unicode Consortium, "The Unicode Standard", 388 . 390 6.2. Informative References 392 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 393 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 394 . 396 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 397 DOI 10.17487/RFC7517, May 2015, 398 . 400 [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload 401 Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, 402 . 404 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 405 and Signatures in JSON Object Signing and Encryption 406 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 407 . 409 [SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 410 2015, . 413 [XMLDSIG] W3C, "XML Signature Syntax and Processing Version 1.1", 414 W3C Recommendation, April 2013, 415 . 417 Appendix A. Open-Source Implementations 419 Due to the simplicity of this specification, there is hardly a need 420 for specific support software. However, JCS which is (at the time of 421 writing), a relatively new design, may be fetched as a separate 422 component for multiple platforms. The following open-source 423 implementations have been verified to be compatible with JCS: 425 * JavaScript: 427 * Java: 430 * Go: 433 * .NET/C#: 436 * Python: 439 Appendix B. JWS/CT Application Notes 441 The following application notes are not a part of the JWS/CT core; 442 they show how JWS/CT can be used in contexts involving multiple 443 signatures. 445 B.1. Counter Signatures 447 Consider the following JWS/CT object showing an imaginary real estate 448 business record: 450 { 451 "gps": [38.89768255588178, -77.03658644893932], 452 "object": {"type": "house", "price": "$635,000"}, 453 "role": "buyer", 454 "name": "John Smith", 455 "timeStamp": "2020-11-08T13:56:08Z", 456 "signature": "<>" 457 } 459 Adding a notary signature on top of this could be performed by 460 embedding the former object as follows: 462 { 463 "attesting": { 464 "gps": [38.89768255588178, -77.03658644893932], 465 "object": {"type": "house", "price": "$635,000"}, 466 "role": "buyer", 467 "name": "John Smith", 468 "timeStamp": "2020-11-08T13:56:08Z", 469 "signature": "<>" 470 }, 471 "role": "notary", 472 "name": "Carol Lombardi-Jones", 473 "timeStamp": "2020-11-08T13:58:42Z", 474 "signature": "<>" 475 } 477 A side effect of this arrangement is that the notary's signature 478 signs not only the notary data, but the buyer's data and signature as 479 well. In most cases this way of adding signatures is advantageous 480 since it maintains the actual order of signing events which also 481 cannot be tampered with without invalidating the outermost signature. 483 Note that all properties above including ""signature"" are 484 application specific. 486 B.2. Detached Signatures 488 In the case the signing entities are "peers" or are unrelated to each 489 other, counter-signatures like described in Appendix B.1 are not 490 applicable since they presume a specific flow. For supporting 491 _independent_ or _asynchronous_ signers targeting a common document 492 or data object, an imaginable solution is using a scheme where each 493 signer rather calculates a hash of the target document/data and 494 includes the hash with the signer-specific meta data like the 495 following: 497 { 499 <> 501 "signers": [{ 502 "sha256": "<>", 504 <> 506 "signature": "<>" 507 },{ 508 "sha256": "<>", 510 <> 512 "signature": "<>" 513 }] 514 } 516 In this case the object to sign would not be limited to JSON; it 517 could for example be a PDF document hosted on a specific URL. Note 518 that the relying party would have to update the structure for each 519 signature received. In some cases a database would probably be more 520 useful for holding individual signatures since a database can cope 521 with any number of signers as well as keeping track of who have 522 actually signed. The latter is crucial for things like international 523 treaties and company board statements. 525 Note that ""signers"", ""sha256"", and ""signature"" are application 526 specific property names. 528 The following sample shows a possible signature object (with line 529 breaks in the signature strings for display purposes only): 531 { 532 "statement": "Hello signed world!", 533 "otherProperties": [2000, true], 534 "signers": [{ 535 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 536 "timeStamp": "2020-11-18T07:45:28Z", 537 "name": "Jane Doe", 538 "signature": "eyJhbGciOiJIUzI1NiJ9..57zPdGh88IgI9kECb1u3O 539 Rhjrbe5mZP4wetM2QCoCBM" 540 },{ 541 "sha256": "n-i0HIBJKELoTicCK9c5nqJ8cYH0znGRcEbYKoQfm70", 542 "timeStamp": "2020-11-18T08:03:40Z", 543 "name": "John Doe", 544 "signature": "eyJhbGciOiJFZERTQSJ9..OQLwF9XHtLru0GYMkG-WS 545 dSdqJkQ-jxTqLJXtV8dqruJe1DVsBLI8ok0IZu8jXibZPow5W1hbBmdYJAYCu5hCA" 546 }] 547 } 549 Notes: 551 * "Jane Doe" used the sample key from Section 3 while "John Doe" 552 used the sample key specified in Appendix C. 554 * The ""sha256"" properties hold base64url-encoded [RFC4648], 555 SHA256-hashes [SHS] of the canonicalized data created in 556 Section 3.1.2. 558 B.3. Array of Signatures 560 Another possibility supporting _multiple and independent_ signatures 561 is collecting JWS signature strings in a JSON array object according 562 to the following scheme: 564 { 566 <> 568 "<>": ["<>", 569 "<>", 570 . 571 "<>"] 572 } 574 Processing would follow Section 3, with the addition that each 575 signature is dealt with individually. 577 Compared to Appendix B.2, signature arrays imply that possible 578 signer-specific meta-data is supplied as JWS extensions in the 579 associated signature's base64url-encoded header. 581 By combining the sample used in Section 3 with the test vector in 582 Appendix C, a valid signature array object could be as follows (with 583 line breaks in the signature strings for display purposes only): 585 { 586 "statement": "Hello signed world!", 587 "otherProperties": [2000, true], 588 "signatures": ["eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imar 589 DtJeSxH2uLU0DhqQP5Zjw4", 590 "eyJhbGciOiJFZERTQSJ9..WAyfK782CRkJh4hcP-OQ3 591 qUYpH6xY3vfFhaRSzNgG5Eu4p54SyTX25-HjNRN8qE5hmMovd8tycp6I9uqRofiBg"] 592 } 594 Note that ""signatures"" is not a key word, it was only selected to 595 highlight the fact that there are multiple signatures. 597 Appendix C. Test Vector Using the Ed25519 Algorithm 599 This appendix shows how a signed version of the JSON sample object in 600 Section 3.1.1 would look like if applying the "Ed25519" algorithm 601 described in RFC 8037 [RFC8037] (with line breaks in the "signature" 602 property for display purposes only): 604 { 605 "statement": "Hello signed world!", 606 "otherProperties": [2000, true], 607 "signature": "eyJhbGciOiJFZERTQSJ9..WAyfK782CRkJh4hcP-OQ3 608 qUYpH6xY3vfFhaRSzNgG5Eu4p54SyTX25-HjNRN8qE5hmMovd8tycp6I9uqRofiBg" 609 } 611 The sample above depends on a JWS header holding the algorithm 612 "{"alg":"EdDSA"}", and the following private key, here expressed in 613 the JWK [RFC7517] format: 615 { 616 "kty": "OKP", 617 "crv": "Ed25519", 618 "x": "_kms9bkrbpI1lPLoM2j2gKySS-k89TOuyvgC43dX-Mk", 619 "d": "0flr-6bXs459f9qwAq20Zs3NizTGIEH5_rTDFoumFV4" 620 } 622 Acknowledgements 624 People who have contributed directly and indirectly with valuable 625 input to this specification include Vladimir Dzhuvinov, Freddi Gyara, 626 and Filip Skokan. 628 Authors' Addresses 630 Bret Jordan (editor) 631 Broadcom 632 1320 Ridder Park Drive 633 San Jose, CA 95131 634 United States of America 636 Email: bret.jordan@broadcom.com 638 Samuel Erdtman 639 Spotify AB 640 Birger Jarlsgatan 61, 4tr 641 SE-113 56 Stockholm 642 Sweden 644 Email: erdtman@spotify.com 646 Anders Rundgren 647 Independent 648 Montpellier 649 France 651 Email: anders.rundgren.net@gmail.com 652 URI: https://www.linkedin.com/in/andersrundgren/