idnits 2.17.1 draft-ietf-secevent-subject-identifiers-05.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 24, 2019) is 1738 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 25, 2020 Coinbase 6 July 24, 2019 8 Subject Identifiers for Security Event Tokens 9 draft-ietf-secevent-subject-identifiers-05 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 25, 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 . . . . . . . . . . . . . 6 65 4. Subject Identifiers in JWTs . . . . . . . . . . . . . . . . . 7 66 4.1. "sub_id" Claim . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 8.2. Informative References . . . . . . . . . . . . . . . . . 14 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_number" claim whose value is a string 195 containing the full telephone number of the subject, including 196 international dialing prefix, formatted according to E.164 [E164]. 197 The "phone_number" claim is REQUIRED and MUST NOT be null or empty. 198 The Phone Number Subject Identifier Type is identified by the name 199 "phone-number". 201 Below is a non-normative example Subject Identifier for the Email 202 Subject Identifier Type: 204 { 205 "subject_type": "phone-number", 206 "phone_number": "+12065550100", 207 } 209 Figure 3: Example: Subject Identifier for the Phone Number Subject 210 Identifier Type. 212 3.4. Issuer and Subject Subject Identifier Type 214 The Issuer and Subject Subject Identifier Type describes a principal 215 identified with a pair of "iss" and "sub" claims, as defined by 216 [JWT]. These claims MUST follow the formats of the "iss" claim and 217 "sub" claim defined by [JWT], respectively. Both the "iss" claim and 218 the "sub" claim are REQUIRED and MUST NOT be null or empty. The 219 Issuer and Subject Subject Identifier Type is identified by the name 220 "iss-sub". 222 Below is a non-normative example Subject Identifier for the Issuer 223 and Subject Subject Identifier Type: 225 { 226 "subject_type": "iss-sub", 227 "iss": "http://issuer.example.com/", 228 "sub": "145234573", 229 } 231 Figure 4: Example: Subject Identifier for the Issuer and Subject 232 Subject Identifier Type. 234 3.5. Aliases Subject Identifier Type 236 The Aliases Subject Identifier Type describes a subject that is 237 identified with a list of different Subject Identifiers. It is 238 intended for use when a variety of identifiers have been shared with 239 the party that will be interpreting the Subject Identifier, and it is 240 unknown which of those identifiers they will recognize or support. 241 Subject Identifiers of this type MUST contain an "identifiers" claim 242 whose value is a JSON array containing one or more Subject 243 Identifiers. Each Subject Identifier in the array MUST identify the 244 same entity. The "identifiers" claim is REQUIRED and MUST NOT be 245 null or empty. It MAY contain multiple instances of the same Subject 246 Identifier Type (e.g., multiple Email Subject Identifiers), but 247 SHOULD NOT contain exact duplicates. This type is identified by the 248 name "aliases". 250 "alias" Subject Identifiers MUST NOT be nested; i.e., the 251 "identifiers" claim of an "alias" Subject Identifier MUST NOT contain 252 a Subject Identifier of type "aliases". 254 Below is a non-normative example Subject Identifier for the Aliases 255 Subject Identifier Type: 257 { 258 "subject_type": "aliases", 259 "identifiers": [ 260 { 261 "subject_type": "email", 262 "email": "user@example.com", 263 }, 264 { 265 "subject_type": "phone-number", 266 "phone_number": "+12065550100", 267 }, 268 { 269 "subject_type": "email", 270 "email": "user+qualifier@example.com", 271 } 272 ], 273 } 275 Figure 5: Example: Subject Identifier for the Aliases Subject 276 Identifier Type. 278 4. Subject Identifiers in JWTs 280 4.1. "sub_id" Claim 282 This document defines the "sub_id" JWT Claim, in accordance with 283 Section 4.2 of [RFC7519]. When present, the value of this claim MUST 284 be a Subject Identifier that identifies the principal that is the 285 subject of the JWT. The "sub_id" claim MAY be included in a JWT, 286 whether or not the "sub" claim is present. When both the "sub" and 287 "sub_id" claims are present in a JWT, they MUST identify the same 288 principal. 290 Below is are non-normative examples of JWTs containing the "sub_id" 291 claim: 293 { 294 "iss": "issuer.example.com", 295 "sub_id": { 296 "subject_type": "email", 297 "email": "user@example.com", 298 }, 299 } 301 Figure 6: Example: JWT containing a `sub_id` claim and no `sub` 302 claim. 304 { 305 "iss": "issuer.example.com", 306 "sub": "user@example.com", 307 "sub_id": { 308 "subject_type": "email", 309 "email": "user@example.com", 310 }, 311 } 313 Figure 7: Example: JWT where both the `sub` and `sub_id` claims 314 identify the subject using the same identifier. 316 { 317 "iss": "issuer.example.com", 318 "sub": "user@example.com", 319 "sub_id": { 320 "subject_type": "email", 321 "email": "elizabeth@example.com", 322 }, 323 } 325 Figure 8: Example: JWT where both the `sub` and `sub_id` claims 326 identify the subject using different values of the same identifier 327 type. 329 { 330 "iss": "issuer.example.com", 331 "sub": "user@example.com", 332 "sub_id": { 333 "subject_type": "account", 334 "uri": "acct:example.user@service.example.com", 335 }, 336 } 338 Figure 9: Example: JWT where the `sub` and `sub_id` claims identify 339 the subject via different types of identifiers. 341 4.2. "sub_id" and "iss-sub" Subject Identifiers 343 The "sub_id" claim MAY contain an "iss-sub" Subject Identifier. In 344 this case, the JWT's "iss" claim and the Subject Identifier's "iss" 345 claim MAY be different. For example, an OpenID Connect [OIDC] client 346 may construct such a JWT when issuing a JWT back to its OpenID 347 Connect Identity Provider, in order to communicate information about 348 the services' shared subject principal using an identifier the 349 Identity Provider is known to understand. Similarly, the JWT's "sub" 350 claim and the Subject Identifier's "sub" claim MAY be different. For 351 example, this may be used by an OpenID Connect client to communicate 352 the subject principal's local identifier at the client back to its 353 Identity Provider. 355 Below are non-normative examples of a JWT where the "iss" claims are 356 the same, and a JWT where they are different. 358 { 359 "iss": "issuer.example.com", 360 "sub_id": { 361 "subject_type": "iss-sub", 362 "iss": "issuer.example.com", 363 "sub": "example_user", 364 }, 365 } 367 Figure 10: Example: JWT with a `iss-sub` Subject Identifier where JWT 368 issuer and subject issuer are the same. 370 { 371 "iss": "client.example.com", 372 "sub_id": { 373 "subject_type": "iss-sub", 374 "iss": "issuer.example.com", 375 "sub": "example_user", 376 }, 377 } 379 Figure 11: Example: JWT with an `iss-sub` Subject Identifier where 380 the JWT issuer and subject issuer are different. 382 { 383 "iss": "client.example.com", 384 "sub": "client_user", 385 "sub_id": { 386 "subject_type": "iss-sub", 387 "iss": "issuer.example.com", 388 "sub": "example_user", 389 }, 390 } 392 Figure 12: Example: JWT with an `iss-sub` Subject Identifier where 393 the JWT `iss` and `sub` claims differ from the Subject Identifier's 394 `iss` and `sub` claims. 396 5. Privacy Considerations 398 5.1. Identifier Correlation 400 The act of presenting two or more identifiers for a single principal 401 together (e.g., within an "aliases" Subject Identifier, or via the 402 "sub" and "sub_id" JWT claims) may communicate more information about 403 the principal than was intended. For example, the entity to which 404 the identifiers are presented, now knows that both identifiers relate 405 to the same principal, and may be able to correlate additional data 406 based on that. When transmitting Subject Identifiers, the 407 transmitter SHOULD take care that they are only transmitting multiple 408 identifiers together when it is known that the recipient already 409 knows that the identifiers are related (e.g., because they were 410 previously sent to the recipient as claims in an OpenID Connect ID 411 Token). 413 6. Security Considerations 415 There are no security considerations. 417 7. IANA Considerations 419 7.1. Security Event Subject Identifier Types Registry 421 This document defines Subject Identifier Types, for which IANA is 422 asked to create and maintain a new registry titled "Security Event 423 Subject Identifier Types". Initial values for the Security Event 424 Subject Identifier Types registry are given in Section 3. Future 425 assignments are to be made through the Expert Review registration 426 policy [BCP26] and shall follow the template presented in 427 Section 7.1.1. 429 7.1.1. Registration Template 431 Type Name 432 The name of the Subject Identifier Type, as described in 433 Section 3. The name MUST be an ASCII string consisting only of 434 lower-case characters ("a" - "z"), digits ("0" - "9"), and hyphens 435 ("-"), and SHOULD NOT exceed 20 characters in length. 437 Type Description 438 A brief description of the Subject Identifier Type. 440 Change Controller 441 For types defined in documents published by the OpenID Foundation 442 or its working groups, list "OpenID Foundation RISC Working 443 Group". For all other types, list the name of the party 444 responsible for the registration. Contact information such as 445 mailing address, email address, or phone number may also be 446 provided. 448 Defining Document(s) 449 A reference to the document or documents that define the Subject 450 Identifier Type. The definition MUST specify the name, format, 451 and meaning of each claim that may occur within a Subject 452 Identifier of the defined type, as well as whether each claim is 453 optional or required, or the circumstances under which the claim 454 is optional or required. URIs that can be used to retrieve copies 455 of each document SHOULD be included. 457 7.1.2. Initial Registry Contents 459 7.1.2.1. Account Subject Identifier Type 461 o Type Name: "account" 463 o Type Description: Subject identifier based on "acct" URI. 465 o Change Controller: IETF secevent Working Group 467 o Defining Document(s): Section 3 of this document. 469 7.1.2.2. Email Subject Identifier Type 471 o Type Name: "email" 473 o Type Description: Subject identifier based on email address. 475 o Change Controller: IETF secevent Working Group 477 o Defining Document(s): Section 3 of this document. 479 7.1.2.3. Issuer and Subject Subject Identifier Type 481 o Type Name: "iss-sub" 483 o Type Description: Subject identifier based on an issuer and 484 subject. 486 o Change Controller: IETF secevent Working Group 488 o Defining Document(s): Section 3 of this document. 490 7.1.2.4. Phone Number Subject Identifier Type 492 o Type Name: "phone-number" 494 o Type Description: Subject identifier based on an phone number. 496 o Change Controller: IETF secevent Working Group 498 o Defining Document(s): Section 3 of this document. 500 7.1.2.5. Aliases Subject Identifier Type 502 o Type Name: "aliases" 504 o Type Description: Subject identifier that groups together multiple 505 different subject identifiers for the same subject. 507 o Change Controller: IETF secevent Working Group 509 o Defining Document(s): Section 3 of this document. 511 7.1.3. Guidance for Expert Reviewers 513 The Expert Reviewer is expected to review the documentation 514 referenced in a registration request to verify its completeness. The 515 Expert Reviewer must base their decision to accept or reject the 516 request on a fair and impartial assessment of the request. If the 517 Expert Reviewer has a conflict of interest, such as being an author 518 of a defining document referenced by the request, they must recuse 519 themselves from the approval process for that request. In the case 520 where a request is rejected, the Expert Reviewer should provide the 521 requesting party with a written statement expressing the reason for 522 rejection, and be prepared to cite any sources of information that 523 went into that decision. 525 Subject Identifier Types need not be generally applicable and may be 526 highly specific to a particular domain; it is expected that types may 527 be registered for niche or industry-specific use cases. The Expert 528 Reviewer should focus on whether the type is thoroughly documented, 529 and whether its registration will promote or harm interoperability. 530 In most cases, the Expert Reviewer should not approve a request if 531 the registration would contribute to confusion, or amount to a 532 synonym for an existing type. 534 7.2. JSON Web Token Claims Registration 536 This document defines the "sub_id" JWT Claim, which IANA is asked to 537 register in the "JSON Web Token Claims" registry IANA JSON Web Token 538 Claims Registry [IANA.JWT.Claims] established by [SET]. 540 7.2.1. Registry Contents 542 o Claim Name: "sub_id" 544 o Claim Description: Subject Identifier 546 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 Draft 05 - AB: 656 o Renamed the "phone" type to "phone-number" and its "phone" claim 657 to "phone_number". 659 Authors' Addresses 661 Annabelle Backman (editor) 662 Amazon 664 Email: richanna@amazon.com 666 Marius Scurtescu 667 Coinbase 669 Email: marius.scurtescu@coinbase.com