idnits 2.17.1 draft-ietf-secevent-subject-identifiers-04.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 ([JSON], [JWT], [SET]), 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 (July 08, 2019) is 1748 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 7159 (ref. 'JSON') (Obsoleted by RFC 8259) -- Duplicate reference: RFC7519, mentioned in 'RFC7519', was also mentioned in 'JWT'. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Events Working Group A. Backman, Ed. 3 Internet-Draft Amazon 4 Intended status: Standards Track M. Scurtescu 5 Expires: January 9, 2020 Coinbase 6 July 08, 2019 8 Subject Identifiers for Security Event Tokens 9 draft-ietf-secevent-subject-identifiers-04 11 Abstract 13 Security events communicated within Security Event Tokens may support 14 a variety of identifiers to identify the subject and/or other 15 principals related to the event. This specification formalizes the 16 notion of subject identifiers as named sets of well-defined claims 17 describing the subject, a mechanism for representing subject 18 identifiers within a [JSON] object such as a JSON Web Token [JWT] or 19 Security Event Token [SET], and a registry for defining and 20 allocating names for these claim sets. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 9, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 58 3. Subject Identifiers . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Account Subject Identifier Type . . . . . . . . . . . . . 3 60 3.2. Email Subject Identifier Type . . . . . . . . . . . . . . 4 61 3.2.1. Email Canonicalization . . . . . . . . . . . . . . . 4 62 3.3. Phone Number Subject Identifier Type . . . . . . . . . . 5 63 3.4. Issuer and Subject Subject Identifier Type . . . . . . . 5 64 3.5. Aliases Subject Identifier Type . . . . . . . . . . . . . 5 65 4. Subject Identifiers in JWTs . . . . . . . . . . . . . . . . . 6 66 4.1. "sub_id" Claim . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. "sub_id" and "iss-sub" Subject Identifiers . . . . . . . 8 68 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 69 5.1. Identifier Correlation . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Security Event Subject Identifier Types Registry . . . . 10 73 7.1.1. Registration Template . . . . . . . . . . . . . . . . 10 74 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 10 75 7.1.3. Guidance for Expert Reviewers . . . . . . . . . . . . 12 76 7.2. JSON Web Token Claims Registration . . . . . . . . . . . 12 77 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 As described in section 1.2 of [SET], the subject of a security event 88 may take a variety of forms, including but not limited to a JWT 89 principal, an IP address, a URL, etc. Furthermore, even in the case 90 where the subject of an event is more narrowly scoped, there may be 91 multiple ways by which a given subject may be identified. For 92 example, an account may be identified by an opaque identifier, an 93 email address, a phone number, a JWT "iss" claim and "sub" claim, 94 etc., depending on the nature and needs of the transmitter and 95 receiver. Even within the context of a given transmitter and 96 receiver relationship, it may be appropriate to identify different 97 accounts in different ways, for example if some accounts only have 98 email addresses associated with them while others only have phone 99 numbers. Therefore it can be necessary to indicate within a SET the 100 mechanism by which the subject of the security event is being 101 identified. 103 2. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Subject Identifiers 111 A Subject Identifier Type is a light-weight schema that describes a 112 set of claims that identifies a subject. Every Subject Identifier 113 Type MUST have a unique name registered in the IANA "Security Event 114 Subject Identifier Types" registry established by Section 7.1. A 115 Subject Identifier Type MAY describe more claims than are strictly 116 necessary to identify a subject, and MAY describe conditions under 117 which those claims are required, optional, or prohibited. 119 A Subject Identifier is a [JSON] object containing a "subject_type" 120 claim whose value is the name of a Subject Identifier Type, and a set 121 of additional "payload claims" which are to be interpreted according 122 to the rules defined by that Subject Identifier Type. Payload claim 123 values MUST match the format specified for the claim by the Subject 124 Identifier Type. A Subject Identifier MUST NOT contain any payload 125 claims prohibited or not described by its Subject Identifier Type, 126 and MUST contain all payload claims required by its Subject 127 Identifier Type. 129 The following Subject Identifier Types are registered in the IANA 130 "Security Event Subject Identifier Types" registry established by 131 Section 7.1. 133 3.1. Account Subject Identifier Type 135 The Account Subject Identifier Type describes a user account at a 136 service provider, identified with an "acct" URI as defined in 137 [RFC7565]. Subject Identifiers of this type MUST contain a "uri" 138 claim whose value is the "acct" URI for the subject. The "uri" claim 139 is REQUIRED and MUST NOT be null or empty. The Account Subject 140 Identifier Type is identified by the name "account". 142 Below is a non-normative example Subject Identifier for the Account 143 Subject Identifier Type: 145 { 146 "subject_type": "account", 147 "uri": "acct:example.user@service.example.com", 148 } 150 Figure 1: Example: Subject Identifier for the Account Subject 151 Identifier Type. 153 3.2. Email Subject Identifier Type 155 The Email Subject Identifier Type describes a principal identified 156 with an email address. Subject Identifiers of this type MUST contain 157 an "email" claim whose value is a string containing the email address 158 of the subject, formatted as an "addr-spec" as defined in 159 Section 3.4.1 of [RFC5322]. The "email" claim is REQUIRED and MUST 160 NOT be null or empty. The value of the "email" claim SHOULD identify 161 a mailbox to which email may be delivered, in accordance with 162 [RFC5321]. The Email Subject Identifier Type is identified by the 163 name "email". 165 Below is a non-normative example Subject Identifier for the Email 166 Subject Identifier Type: 168 { 169 "subject_type": "email", 170 "email": "user@example.com", 171 } 173 Figure 2: Example: Subject Identifier for the Email Subject 174 Identifier Type. 176 3.2.1. Email Canonicalization 178 Many email providers will treat multiple email addresses as 179 equivalent. For example, some providers treat email addresses as 180 case-insensitive, and consider "user@example.com", 181 "User@example.com", and "USER@example.com" as the same email address. 182 This has led users to view these strings as equivalent, driving 183 service providers to implement proprietary email canonicalization 184 algorithms to ensure that email addresses entered by users resolve to 185 the same canonical string. When receiving an Email Subject 186 Identifier, the recipient SHOULD use their implementation's 187 canonicalization algorithm to resolve the email address to the same 188 subject identifier string used in their system. 190 3.3. Phone Number Subject Identifier Type 192 The Phone Number Subject Identifier Type describes a principal 193 identified with a telephone number. Subject Identifiers of this type 194 MUST contain a "phone" claim whose value is a string containing the 195 full telephone number of the subject, including international dialing 196 prefix, formatted according to E.164 [E164]. The "phone" claim is 197 REQUIRED and MUST NOT be null or empty. The Phone Number Subject 198 Identifier Type is identified by the name "phone". 200 Below is a non-normative example Subject Identifier for the Email 201 Subject Identifier Type: 203 { 204 "subject_type": "phone", 205 "phone": "+12065550100", 206 } 208 Figure 3: Example: Subject Identifier for the Phone Number Subject 209 Identifier Type. 211 3.4. Issuer and Subject Subject Identifier Type 213 The Issuer and Subject Subject Identifier Type describes a principal 214 identified with a pair of "iss" and "sub" claims, as defined by 215 [JWT]. These claims MUST follow the formats of the "iss" claim and 216 "sub" claim defined by [JWT], respectively. Both the "iss" claim and 217 the "sub" claim are REQUIRED and MUST NOT be null or empty. The 218 Issuer and Subject Subject Identifier Type is identified by the name 219 "iss-sub". 221 Below is a non-normative example Subject Identifier for the Issuer 222 and Subject Subject Identifier Type: 224 { 225 "subject_type": "iss-sub", 226 "iss": "http://issuer.example.com/", 227 "sub": "145234573", 228 } 230 Figure 4: Example: Subject Identifier for the Issuer and Subject 231 Subject Identifier Type. 233 3.5. Aliases Subject Identifier Type 235 The Aliases Subject Identifier Type describes a subject that is 236 identified with a list of different Subject Identifiers. It is 237 intended for use when a variety of identifiers have been shared with 238 the party that will be interpreting the Subject Identifier, and it is 239 unknown which of those identifiers they will recognize or support. 240 Subject Identifiers of this type MUST contain an "identifiers" claim 241 whose value is a JSON array containing one or more Subject 242 Identifiers. Each Subject Identifier in the array MUST identify the 243 same entity. The "identifiers" claim is REQUIRED and MUST NOT be 244 null or empty. It MAY contain multiple instances of the same Subject 245 Identifier Type (e.g., multiple Email Subject Identifiers), but 246 SHOULD NOT contain exact duplicates. This type is identified by the 247 name "aliases". 249 "alias" Subject Identifiers MUST NOT be nested; i.e., the 250 "identifiers" claim of an "alias" Subject Identifier MUST NOT contain 251 a Subject Identifier of type "aliases". 253 Below is a non-normative example Subject Identifier for the Aliases 254 Subject Identifier Type: 256 { 257 "subject_type": "aliases", 258 "identifiers": [ 259 { 260 "subject_type": "email", 261 "email": "user@example.com", 262 }, 263 { 264 "subject_type": "phone", 265 "phone": "+12065550100", 266 }, 267 { 268 "subject_type": "email", 269 "email": "user+qualifier@example.com", 270 } 271 ], 272 } 274 Figure 5: Example: Subject Identifier for the Aliases Subject 275 Identifier Type. 277 4. Subject Identifiers in JWTs 279 4.1. "sub_id" Claim 281 This document defines the "sub_id" JWT Claim, in accordance with 282 Section 4.2 of [RFC7519]. When present, the value of this claim MUST 283 be a Subject Identifier that identifies the principal that is the 284 subject of the JWT. The "sub_id" claim MAY be included in a JWT, 285 whether or not the "sub" claim is present. When both the "sub" and 286 "sub_id" claims are present in a JWT, they MUST identify the same 287 principal. 289 Below is are non-normative examples of JWTs containing the "sub_id" 290 claim: 292 { 293 "iss": "issuer.example.com", 294 "sub_id": { 295 "subject_type": "email", 296 "email": "user@example.com", 297 }, 298 } 300 Figure 6: Example: JWT containing a `sub_id` claim and no `sub` 301 claim. 303 { 304 "iss": "issuer.example.com", 305 "sub": "user@example.com", 306 "sub_id": { 307 "subject_type": "email", 308 "email": "user@example.com", 309 }, 310 } 312 Figure 7: Example: JWT where both the `sub` and `sub_id` claims 313 identify the subject using the same identifier. 315 { 316 "iss": "issuer.example.com", 317 "sub": "user@example.com", 318 "sub_id": { 319 "subject_type": "email", 320 "email": "elizabeth@example.com", 321 }, 322 } 324 Figure 8: Example: JWT where both the `sub` and `sub_id` claims 325 identify the subject using different values of the same identifier 326 type. 328 { 329 "iss": "issuer.example.com", 330 "sub": "user@example.com", 331 "sub_id": { 332 "subject_type": "account", 333 "uri": "acct:example.user@service.example.com", 334 }, 335 } 337 Figure 9: Example: JWT where the `sub` and `sub_id` claims identify 338 the subject via different types of identifiers. 340 4.2. "sub_id" and "iss-sub" Subject Identifiers 342 The "sub_id" claim MAY contain an "iss-sub" Subject Identifier. In 343 this case, the JWT's "iss" claim and the Subject Identifier's "iss" 344 claim MAY be different. For example, an OpenID Connect [OIDC] client 345 may construct such a JWT when issuing a JWT back to its OpenID 346 Connect Identity Provider, in order to communicate information about 347 the services' shared subject principal using an identifier the 348 Identity Provider is known to understand. Similarly, the JWT's "sub" 349 claim and the Subject Identifier's "sub" claim MAY be different. For 350 example, this may be used by an OpenID Connect client to communicate 351 the subject principal's local identifier at the client back to its 352 Identity Provider. 354 Below are non-normative examples of a JWT where the "iss" claims are 355 the same, and a JWT where they are different. 357 { 358 "iss": "issuer.example.com", 359 "sub_id": { 360 "subject_type": "iss-sub", 361 "iss": "issuer.example.com", 362 "sub": "example_user", 363 }, 364 } 366 Figure 10: Example: JWT with a `iss-sub` Subject Identifier where JWT 367 issuer and subject issuer are the same. 369 { 370 "iss": "client.example.com", 371 "sub_id": { 372 "subject_type": "iss-sub", 373 "iss": "issuer.example.com", 374 "sub": "example_user", 375 }, 376 } 378 Figure 11: Example: JWT with an `iss-sub` Subject Identifier where 379 the JWT issuer and subject issuer are different. 381 { 382 "iss": "client.example.com", 383 "sub": "client_user", 384 "sub_id": { 385 "subject_type": "iss-sub", 386 "iss": "issuer.example.com", 387 "sub": "example_user", 388 }, 389 } 391 Figure 12: Example: JWT with an `iss-sub` Subject Identifier where 392 the JWT `iss` and `sub` claims differ from the Subject Identifier's 393 `iss` and `sub` claims. 395 5. Privacy Considerations 397 5.1. Identifier Correlation 399 The act of presenting two or more identifiers for a single principal 400 together (e.g., within an "aliases" Subject Identifier, or via the 401 "sub" and "sub_id" JWT claims) may communicate more information about 402 the principal than was intended. For example, the entity to which 403 the identifiers are presented, now knows that both identifiers relate 404 to the same principal, and may be able to correlate additional data 405 based on that. When transmitting Subject Identifiers, the 406 transmitter SHOULD take care that they are only transmitting multiple 407 identifiers together when it is known that the recipient already 408 knows that the identifiers are related (e.g., because they were 409 previously sent to the recipient as claims in an OpenID Connect ID 410 Token). 412 6. Security Considerations 414 There are no security considerations. 416 7. IANA Considerations 418 7.1. Security Event Subject Identifier Types Registry 420 This document defines Subject Identifier Types, for which IANA is 421 asked to create and maintain a new registry titled "Security Event 422 Subject Identifier Types". Initial values for the Security Event 423 Subject Identifier Types registry are given in Section 3. Future 424 assignments are to be made through the Expert Review registration 425 policy [BCP26] and shall follow the template presented in 426 Section 7.1.1. 428 7.1.1. Registration Template 430 Type Name 431 The name of the Subject Identifier Type, as described in 432 Section 3. The name MUST be an ASCII string consisting only of 433 lower-case characters ("a" - "z"), digits ("0" - "9"), and hyphens 434 ("-"), and SHOULD NOT exceed 20 characters in length. 436 Type Description 437 A brief description of the Subject Identifier Type. 439 Change Controller 440 For types defined in documents published by the OpenID Foundation 441 or its working groups, list "OpenID Foundation RISC Working 442 Group". For all other types, list the name of the party 443 responsible for the registration. Contact information such as 444 mailing address, email address, or phone number may also be 445 provided. 447 Defining Document(s) 448 A reference to the document or documents that define the Subject 449 Identifier Type. The definition MUST specify the name, format, 450 and meaning of each claim that may occur within a Subject 451 Identifier of the defined type, as well as whether each claim is 452 optional or required, or the circumstances under which the claim 453 is optional or required. URIs that can be used to retrieve copies 454 of each document SHOULD be included. 456 7.1.2. Initial Registry Contents 458 7.1.2.1. Account Subject Identifier Type 460 o Type Name: "account" 462 o Type Description: Subject identifier based on "acct" URI. 464 o Change Controller: IETF secevent Working Group 466 o Defining Document(s): Section 3 of this document. 468 7.1.2.2. Email Subject Identifier Type 470 o Type Name: "email" 472 o Type Description: Subject identifier based on email address. 474 o Change Controller: IETF secevent Working Group 476 o Defining Document(s): Section 3 of this document. 478 7.1.2.3. Issuer and Subject Subject Identifier Type 480 o Type Name: "iss-sub" 482 o Type Description: Subject identifier based on an issuer and 483 subject. 485 o Change Controller: IETF secevent Working Group 487 o Defining Document(s): Section 3 of this document. 489 7.1.2.4. Phone Number Subject Identifier Type 491 o Type Name: "phone" 493 o Type Description: Subject identifier based on an phone number. 495 o Change Controller: IETF secevent Working Group 497 o Defining Document(s): Section 3 of this document. 499 7.1.2.5. Aliases Subject Identifier Type 501 o Type Name: "aliases" 503 o Type Description: Subject identifier that groups together multiple 504 different subject identifiers for the same subject. 506 o Change Controller: IETF secevent Working Group 508 o Defining Document(s): Section 3 of this document. 510 7.1.3. Guidance for Expert Reviewers 512 The Expert Reviewer is expected to review the documentation 513 referenced in a registration request to verify its completeness. The 514 Expert Reviewer must base their decision to accept or reject the 515 request on a fair and impartial assessment of the request. If the 516 Expert Reviewer has a conflict of interest, such as being an author 517 of a defining document referenced by the request, they must recuse 518 themselves from the approval process for that request. In the case 519 where a request is rejected, the Expert Reviewer should provide the 520 requesting party with a written statement expressing the reason for 521 rejection, and be prepared to cite any sources of information that 522 went into that decision. 524 Subject Identifier Types need not be generally applicable and may be 525 highly specific to a particular domain; it is expected that types may 526 be registered for niche or industry-specific use cases. The Expert 527 Reviewer should focus on whether the type is thoroughly documented, 528 and whether its registration will promote or harm interoperability. 529 In most cases, the Expert Reviewer should not approve a request if 530 the registration would contribute to confusion, or amount to a 531 synonym for an existing type. 533 7.2. JSON Web Token Claims Registration 535 This document defines the "sub_id" JWT Claim, which IANA is asked to 536 register in the "JSON Web Token Claims" registry IANA JSON Web Token 537 Claims Registry [IANA.JWT.Claims] established by [SET]. 539 7.2.1. Registry Contents 541 o Claim Name: "sub_id" 543 o Claim Description: Subject Identifier 545 o Change Controller: IESG 547 o Specification Document(s): Section 4.1 of this document. 549 8. References 551 8.1. Normative References 553 [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 554 Writing an IANA Considerations Section in RFCs", BCP 26, 555 RFC 8126, DOI 10.17487/RFC8126, June 2017, 556 . 558 [E164] International Telecommunication Union, "The international 559 public telecommunication numbering plan", 2010, 560 . 562 [IANA.JWT.Claims] 563 IANA, "JSON Web Token Claims", n.d., 564 . 566 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 567 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 568 2014, . 570 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 571 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 572 . 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 580 DOI 10.17487/RFC5321, October 2008, 581 . 583 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 584 DOI 10.17487/RFC5322, October 2008, 585 . 587 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 588 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 589 . 591 [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, 592 DOI 10.17487/RFC7565, May 2015, 593 . 595 [SET] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 596 "Security Event Token (SET)", RFC 8417, 597 DOI 10.17487/RFC8417, July 2018, 598 . 600 8.2. Informative References 602 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 603 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 604 . 606 Acknowledgements 608 This document is based on work developed within the OpenID RISC 609 Working Group. The authors would like to thank the members of this 610 group for their hard work and contributions. 612 Change Log 614 (This section to be removed by the RFC Editor before publication as 615 an RFC.) 617 Draft 00 - AB - First draft 619 Draft 01 - AB: 621 o Added reference to RFC 5322 for format of "email" claim. 623 o Renamed "iss_sub" type to "iss-sub". 625 o Renamed "id_token_claims" type to "id-token-claims". 627 o Added text specifying the nature of the subjects described by each 628 type. 630 Draft 02 - AB: 632 o Corrected format of phone numbers in examples. 634 o Updated author info. 636 Draft 03 - AB: 638 o Added "account" type for "acct" URIs. 640 o Replaced "id-token-claims" type with "aliases" type. 642 o Added email canonicalization guidance. 644 o Updated semantics for "email", "phone", and "iss-sub" types. 646 Draft 04 - AB: 648 o Added "sub_id" JWT Claim definition, guidance, examples. 650 o Added text prohibiting "aliases" nesting. 652 o Added privacy considerations for identifier correlation. 654 Authors' Addresses 656 Annabelle Backman (editor) 657 Amazon 659 Email: richanna@amazon.com 661 Marius Scurtescu 662 Coinbase 664 Email: marius.scurtescu@coinbase.com