idnits 2.17.1 draft-ietf-secevent-subject-identifiers-06.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 (September 04, 2020) is 1329 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 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: March 8, 2021 Coinbase 6 September 04, 2020 8 Subject Identifiers for Security Event Tokens 9 draft-ietf-secevent-subject-identifiers-06 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 March 8, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . 4 58 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Subject Identifiers . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Subject Identifier Types versus Principal Types . . . . . 5 61 3.2. Subject Identifier Type Definitions . . . . . . . . . . . 5 62 3.2.1. Account Subject Identifier Type . . . . . . . . . . . 6 63 3.2.2. Email Subject Identifier Type . . . . . . . . . . . . 6 64 3.2.3. Phone Number Subject Identifier Type . . . . . . . . 7 65 3.2.4. Issuer and Subject Subject Identifier Type . . . . . 7 66 3.2.5. Aliases Subject Identifier Type . . . . . . . . . . . 8 67 4. Subject Identifiers in JWTs . . . . . . . . . . . . . . . . . 9 68 4.1. "sub_id" Claim . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. "sub_id" and "iss_sub" Subject Identifiers . . . . . . . 11 70 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 71 5.1. Identifier Correlation . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 6.1. Confidentiality and Integrity . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Security Event Subject Identifier Types Registry . . . . 13 76 7.1.1. Registry Location . . . . . . . . . . . . . . . . . . 13 77 7.1.2. Registration Template . . . . . . . . . . . . . . . . 13 78 7.1.3. Initial Registry Contents . . . . . . . . . . . . . . 14 79 7.1.4. Guidance for Expert Reviewers . . . . . . . . . . . . 15 80 7.2. JSON Web Token Claims Registration . . . . . . . . . . . 16 81 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 8.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 86 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 As described in Section 1.2 of SET [RFC8417], the subject of a 92 security event may take a variety of forms, including but not limited 93 to a JWT [RFC7519] principal, an IP address, a URL, etc. 94 Furthermore, even in the case where the subject of an event is more 95 narrowly scoped, there may be multiple ways by which a given subject 96 may be identified. For example, an account may be identified by an 97 opaque identifier, an email address, a phone number, a JWT "iss" 98 claim and "sub" claim, etc., depending on the nature and needs of the 99 transmitter and receiver. Even within the context of a given 100 transmitter and receiver relationship, it may be appropriate to 101 identify different accounts in different ways, for example if some 102 accounts only have email addresses associated with them while others 103 only have phone numbers. Therefore it can be necessary to indicate 104 within a SET the mechanism by which the subject of the security event 105 is being identified. 107 To address this problem, this specification defines Subject 108 Identifiers - JSON [RFC7159] objects containing information 109 identifying a subject - and Subject Identifier Types - named sets of 110 rules describing how to encode different kinds of subject identifying 111 information (e.g., an email address, or an issuer and subject pair) 112 as a Subject Identifier. 114 Below is a non-normative example of a Subject Identifier that 115 identifies a subject by email address, using the Email Subject 116 Identifier Type. 118 { 119 "subject_type": "email", 120 "email": "user@example.com", 121 } 123 Figure 1: Example: Subject Identifier using the Email Subject 124 Identifier Type 126 Subject Identifiers are intended to be a general purpose mechanism 127 for identifying principals within JSON objects. Below is a non- 128 normative example of a JWT that uses a Subject Identifier in the 129 "sub_id" claim (defined in this specification) to identify its 130 subject. 132 { 133 "iss": "issuer.example.com", 134 "sub_id": { 135 "subject_type": "phone_number", 136 "phone_number": "+12065550100", 137 }, 138 } 140 Figure 2: Example: JWT using a Subject Identifier with the sub_id 141 claim 143 Below is a non-normative example of a SET containing a hypothetical 144 security event describing the interception of a message, using 145 Subject Identifiers to identify the sender, intended recipient, and 146 interceptor. 148 { 149 "iss": "issuer.example.com", 150 "iat": 1508184845, 151 "aud": "aud.example.com", 152 "events": { 153 "https://secevent.example.com/events/message-interception": { 154 "from": { 155 "subject_type": "email", 156 "email": "alice@example.com", 157 }, 158 "to": { 159 "subject_type": "email", 160 "email": "bob@example.com", 161 }, 162 "interceptor": { 163 "subject_type": "email", 164 "email": "eve@example.com", 165 }, 166 }, 167 }, 168 } 170 Figure 3: Example: SET with an event payload containing multiple 171 Subject Identifiers 173 2. Notational Conventions 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2.1. Definitions 181 This specification utilizes terminology defined in [RFC7159], 182 [RFC7519], and [RFC8417]. 184 3. Subject Identifiers 186 A Subject Identifier is a JSON [RFC7159] object whose contents may be 187 used to identify a principal within some context. A Subject 188 Identifier Type is a named definition of a set of information that 189 may be used to identify a principal, and the rules for encoding that 190 information as a Subject Identifier. A Subject Identifier MUST 191 conform to a specific Subject Identifier Type, and MUST contain a 192 "subject_type" member whose value is the name of that Subject 193 Identifier Type. 195 Every Subject Identifier Type MUST have a unique name registered in 196 the IANA "Security Event Subject Identifier Types" registry 197 established by Section 7.1, or a Collision-Resistant Name as defined 198 in [RFC7519]. Subject Identifier Types that are expected to be used 199 broadly by a variety of parties SHOULD be registered in the "Security 200 Event Subject Identifier Types" registry. 202 A Subject Identifier Type MAY describe more members than are strictly 203 necessary to identify a subject, and MAY describe conditions under 204 which those members are required, optional, or prohibited. 206 Aside from the "subject_type" member whose definition is given above, 207 every member within a Subject Identifier MUST match the format 208 specified for that member by the Subject Identifier's Subject 209 Identifier Type. A Subject Identifier MUST NOT contain any members 210 prohibited or not described by its Subject Identifier Type, and MUST 211 contain all members required by its Subject Identifier Type. 213 3.1. Subject Identifier Types versus Principal Types 215 A Subject Identifier Type describes a way to identify a principal, 216 but does not explicitly indicate the type of that principal (e.g., 217 user, group, network connection, baseball team, astronomic object). 218 Consequently Subject Identifiers remove ambiguity around how a 219 principal is being identified, and how to parse an identifying 220 structure, but they do not remove ambiguity around how to resolve 221 that identifier to a principal. For example, consider a directory 222 management API that allows callers to identify users and groups 223 through both immutable unique identifiers and mutable email 224 addresses. Such an API could use Subject Identifiers to disambiguate 225 between which of these two types of identifiers is in use. However, 226 the service would have to determine whether the principal is a user 227 or group via some other means, such as by querying a database or by 228 inferring the type from the API contract. 230 3.2. Subject Identifier Type Definitions 232 The following Subject Identifier Types are registered in the IANA 233 "Security Event Subject Identifier Types" registry established by 234 Section 7.1. 236 3.2.1. Account Subject Identifier Type 238 The Account Subject Identifier Type identifies a principal using an 239 account at a service provider, identified with an "acct" URI as 240 defined in [RFC7565]. Subject Identifiers of this type MUST contain 241 a "uri" member whose value is the "acct" URI for the subject. The 242 "uri" member is REQUIRED and MUST NOT be null or empty. The Account 243 Subject Identifier Type is identified by the name "account". 245 Below is a non-normative example Subject Identifier for the Account 246 Subject Identifier Type: 248 { 249 "subject_type": "account", 250 "uri": "acct:example.user@service.example.com", 251 } 253 Figure 4: Example: Subject Identifier for the Account Subject 254 Identifier Type 256 3.2.2. Email Subject Identifier Type 258 The Email Subject Identifier Type identifies a principal using an 259 email address. Subject Identifiers of this type MUST contain an 260 "email" member whose value is a string containing the email address 261 of the principal, formatted as an "addr-spec" as defined in 262 Section 3.4.1 of [RFC5322]. The "email" member is REQUIRED and MUST 263 NOT be null or empty. The value of the "email" member SHOULD 264 identify a mailbox to which email may be delivered, in accordance 265 with [RFC5321]. The Email Subject Identifier Type is identified by 266 the name "email". 268 Below is a non-normative example Subject Identifier for the Email 269 Subject Identifier Type: 271 { 272 "subject_type": "email", 273 "email": "user@example.com", 274 } 276 Figure 5: Example: Subject Identifier for the Email Subject 277 Identifier Type 279 3.2.2.1. Email Canonicalization 281 Many email providers will treat multiple email addresses as 282 equivalent. While the domain portion of an [RFC5322] email address 283 is consistently treated as case-insensitive per [RFC1034], some 284 providers treat the local part of the email address as case- 285 insensitive as well, and consider "user@example.com", 286 "User@example.com", and "USER@example.com" as the same email address. 287 This has led users to view these strings as equivalent, driving 288 service providers to implement proprietary email canonicalization 289 algorithms to ensure that email addresses entered by users resolve to 290 the same canonical string. When receiving an Email Subject 291 Identifier, the recipient SHOULD use their implementation's 292 canonicalization algorithm to resolve the email address to the same 293 string used in their system. 295 3.2.3. Phone Number Subject Identifier Type 297 The Phone Number Subject Identifier Type identifies a principal using 298 a telephone number. Subject Identifiers of this type MUST contain a 299 "phone_number" member whose value is a string containing the full 300 telephone number of the principal, including international dialing 301 prefix, formatted according to E.164 [E164]. The "phone_number" 302 member is REQUIRED and MUST NOT be null or empty. The Phone Number 303 Subject Identifier Type is identified by the name "phone_number". 305 Below is a non-normative example Subject Identifier for the Email 306 Subject Identifier Type: 308 { 309 "subject_type": "phone_number", 310 "phone_number": "+12065550100", 311 } 313 Figure 6: Example: Subject Identifier for the Phone Number Subject 314 Identifier Type. 316 3.2.4. Issuer and Subject Subject Identifier Type 318 The Issuer and Subject Subject Identifier Type identifies a principal 319 using a pair of "iss" and "sub" members, analagous to how subjects 320 are identified using the "iss" and "sub" claims in OpenID Connect 321 [OpenID.Core] ID Tokens. These members MUST follow the formats of 322 the "iss" member and "sub" member defined by [RFC7519], respectively. 323 Both the "iss" member and the "sub" member are REQUIRED and MUST NOT 324 be null or empty. The Issuer and Subject Subject Identifier Type is 325 identified by the name "iss_sub". 327 Below is a non-normative example Subject Identifier for the Issuer 328 and Subject Subject Identifier Type: 330 { 331 "subject_type": "iss_sub", 332 "iss": "http://issuer.example.com/", 333 "sub": "145234573", 334 } 336 Figure 7: Example: Subject Identifier for the Issuer and Subject 337 Subject Identifier Type 339 3.2.5. Aliases Subject Identifier Type 341 The Aliases Subject Identifier Type describes a subject that is 342 identified with a list of different Subject Identifiers. It is 343 intended for use when a variety of identifiers have been shared with 344 the party that will be interpreting the Subject Identifier, and it is 345 unknown which of those identifiers they will recognize or support. 346 Subject Identifiers of this type MUST contain an "identifiers" member 347 whose value is a JSON array containing one or more Subject 348 Identifiers. Each Subject Identifier in the array MUST identify the 349 same entity. The "identifiers" member is REQUIRED and MUST NOT be 350 null or empty. It MAY contain multiple instances of the same Subject 351 Identifier Type (e.g., multiple Email Subject Identifiers), but 352 SHOULD NOT contain exact duplicates. This type is identified by the 353 name "aliases". 355 "alias" Subject Identifiers MUST NOT be nested; i.e., the 356 "identifiers" member of an "alias" Subject Identifier MUST NOT 357 contain a Subject Identifier of type "aliases". 359 Below is a non-normative example Subject Identifier for the Aliases 360 Subject Identifier Type: 362 { 363 "subject_type": "aliases", 364 "identifiers": [ 365 { 366 "subject_type": "email", 367 "email": "user@example.com", 368 }, 369 { 370 "subject_type": "phone_number", 371 "phone_number": "+12065550100", 372 }, 373 { 374 "subject_type": "email", 375 "email": "user+qualifier@example.com", 376 } 377 ], 378 } 380 Figure 8: Example: Subject Identifier for the Aliases Subject 381 Identifier Type 383 4. Subject Identifiers in JWTs 385 4.1. "sub_id" Claim 387 The "sub" JWT Claim is defined in Section 4.1.2 of [RFC7519] as 388 containing a string value, and therefore cannot contain a Subject 389 Identifier (which is a JSON object) as its value. This document 390 defines the "sub_id" JWT Claim, in accordance with Section 4.2 of 391 [RFC7519], as a common claim that identifies the subject of the JWT 392 using a Subject Identifier. When present, the value of this claim 393 MUST be a Subject Identifier that identifies the principal that is 394 the subject of the JWT. The "sub_id" claim MAY be included in a JWT, 395 whether or not the "sub" claim is present. When both the "sub" and 396 "sub_id" claims are present in a JWT, they MUST identify the same 397 principal. 399 When processing a JWT with both "sub" and "sub_id" claims, 400 implementations MUST NOT rely on both claims to determine the 401 subject. An implementation MAY attempt to determine the subject from 402 one claim and fall back to using the other if it determines it does 403 not understand the format of the first claim. For example, an 404 implementation may attempt to use "sub_id", and fall back to using 405 "sub" upon finding that "sub_id" contains a Subject Identifier whose 406 type is not recognized by the implementation. 408 Below are non-normative examples of JWTs containing the "sub_id" 409 claim: 411 { 412 "iss": "issuer.example.com", 413 "sub_id": { 414 "subject_type": "email", 415 "email": "user@example.com", 416 }, 417 } 419 Figure 9: Example: JWT containing a `sub_id` claim and no `sub` claim 421 { 422 "iss": "issuer.example.com", 423 "sub": "user@example.com", 424 "sub_id": { 425 "subject_type": "email", 426 "email": "user@example.com", 427 }, 428 } 430 Figure 10: Example: JWT where both the `sub` and `sub_id` claims 431 identify the subject using the same identifier 433 { 434 "iss": "issuer.example.com", 435 "sub": "user@example.com", 436 "sub_id": { 437 "subject_type": "email", 438 "email": "elizabeth@example.com", 439 }, 440 } 442 Figure 11: Example: JWT where both the `sub` and `sub_id` claims 443 identify the subject using different values of the same identifier 444 type 446 { 447 "iss": "issuer.example.com", 448 "sub": "user@example.com", 449 "sub_id": { 450 "subject_type": "account", 451 "uri": "acct:example.user@service.example.com", 452 }, 453 } 455 Figure 12: Example: JWT where the `sub` and `sub_id` claims identify 456 the subject via different types of identifiers 458 4.2. "sub_id" and "iss_sub" Subject Identifiers 460 The "sub_id" claim MAY contain an "iss_sub" Subject Identifier. In 461 this case, the JWT's "iss" claim and the Subject Identifier's "iss" 462 member MAY be different. For example, an OpenID Connect 463 [OpenID.Core] client may construct such a JWT when issuing a JWT back 464 to its OpenID Connect Identity Provider, in order to communicate 465 information about the services' shared subject principal using an 466 identifier the Identity Provider is known to understand. Similarly, 467 the JWT's "sub" claim and the Subject Identifier's "sub" member MAY 468 be different. For example, this may be used by an OpenID Connect 469 client to communicate the subject principal's local identifier at the 470 client back to its Identity Provider. 472 Below are non-normative examples of a JWT where the "iss" claim and 473 "iss" member within the "sub_id" claim are the same, and a JWT where 474 they are different. 476 { 477 "iss": "issuer.example.com", 478 "sub_id": { 479 "subject_type": "iss_sub", 480 "iss": "issuer.example.com", 481 "sub": "example_user", 482 }, 483 } 485 Figure 13: Example: JWT with a `iss_sub` Subject Identifier where JWT 486 issuer and subject issuer are the same 488 { 489 "iss": "client.example.com", 490 "sub_id": { 491 "subject_type": "iss_sub", 492 "iss": "issuer.example.com", 493 "sub": "example_user", 494 }, 495 } 497 Figure 14: Example: JWT with an `iss_sub` Subject Identifier where 498 the JWT issuer and subject issuer are different 500 { 501 "iss": "client.example.com", 502 "sub": "client_user", 503 "sub_id": { 504 "subject_type": "iss_sub", 505 "iss": "issuer.example.com", 506 "sub": "example_user", 507 }, 508 } 510 Figure 15: Example: JWT with an `iss_sub` Subject Identifier where 511 the JWT `iss` and `sub` claims differ from the Subject Identifier's 512 `iss` and `sub` members 514 5. Privacy Considerations 516 5.1. Identifier Correlation 518 The act of presenting two or more identifiers for a single principal 519 together (e.g., within an "aliases" Subject Identifier, or via the 520 "sub" and "sub_id" JWT claims) may communicate more information about 521 the principal than was intended. For example, the entity to which 522 the identifiers are presented, now knows that both identifiers relate 523 to the same principal, and may be able to correlate additional data 524 based on that. When transmitting Subject Identifiers, the 525 transmitter SHOULD take care that they are only transmitting multiple 526 identifiers together when it is known that the recipient already 527 knows that the identifiers are related (e.g., because they were 528 previously sent to the recipient as claims in an OpenID Connect ID 529 Token), or when correlation is essential to the use case. 531 The considerations described in Section 6 of [RFC8417] also apply 532 when Subject Identifiers are used within SETs. The considerations 533 described in Section 12 of [RFC7519] also apply when Subject 534 Identifiers are used within JWTs. 536 6. Security Considerations 538 6.1. Confidentiality and Integrity 540 This specification does not define any mechanism for ensuring the 541 confidentiality or integrityi of a Subject Identifier. Where such 542 properties are required, implementations MUST use mechanisms provided 543 by the containing format (e.g., integrity protecting SETs or JWTs 544 using JWS [RFC7515]), or at the transport layer or other layer in the 545 application stack (e.g., using TLS [RFC8446]). 547 Further considerations regarding confidentiality and integrity of 548 SETs can be found in Section 5.1 of [RFC8417]. 550 7. IANA Considerations 552 7.1. Security Event Subject Identifier Types Registry 554 This document defines Subject Identifier Types, for which IANA is 555 asked to create and maintain a new registry titled "Security Event 556 Subject Identifier Types". Initial values for the Security Event 557 Subject Identifier Types registry are given in Section 3. Future 558 assignments are to be made through the Expert Review registration 559 policy [BCP26] and shall follow the template presented in 560 Section 7.1.2. 562 It is suggested that multiple Designated Experts be appointed who are 563 able to represent the perspectives of different applications using 564 this specification, in order to enable broadly informed review of 565 registration decisions. In cases where a registration decision could 566 be perceived as creating a conflict of interest for a particular 567 Expert, that Expert should defer to the judgment of the other 568 Experts. 570 7.1.1. Registry Location 572 (This section to be removed by the RFC Editor before publication as 573 an RFC.) 575 The authors recommend that the Subject Identifier Types registry be 576 located at "https://www.iana.org/assignments/secevent/". 578 7.1.2. Registration Template 580 Type Name 581 The name of the Subject Identifier Type, as described in 582 Section 3. The name MUST be an ASCII string consisting only of 583 lower-case characters ("a" - "z"), digits ("0" - "9"), underscores 584 ("_"), and hyphens ("-"), and SHOULD NOT exceed 20 characters in 585 length. 587 Type Description 588 A brief description of the Subject Identifier Type. 590 Change Controller 591 For types defined in documents published by the IETF or its 592 working groups, list "IETF". For all other types, list the name 593 of the party responsible for the registration. Contact 594 information such as mailing address, email address, or phone 595 number may also be provided. 597 Defining Document(s) 598 A reference to the document or documents that define the Subject 599 Identifier Type. The definition MUST specify the name, format, 600 and meaning of each member that may occur within a Subject 601 Identifier of the defined type, as well as whether each member is 602 optional, required, prohibited, or the circumstances under which 603 the member may be optional, required, or prohibited. URIs that 604 can be used to retrieve copies of each document SHOULD be 605 included. 607 7.1.3. Initial Registry Contents 609 7.1.3.1. Account Subject Identifier Type 611 o Type Name: "account" 613 o Type Description: Subject identifier based on "acct" URI. 615 o Change Controller: IETF 617 o Defining Document(s): Section 3 of this document. 619 7.1.3.2. Email Subject Identifier Type 621 o Type Name: "email" 623 o Type Description: Subject identifier based on email address. 625 o Change Controller: IETF 627 o Defining Document(s): Section 3 of this document. 629 7.1.3.3. Issuer and Subject Subject Identifier Type 631 o Type Name: "iss_sub" 633 o Type Description: Subject identifier based on an issuer and 634 subject. 636 o Change Controller: IETF 638 o Defining Document(s): Section 3 of this document. 640 7.1.3.4. Phone Number Subject Identifier Type 642 o Type Name: "phone_number" 644 o Type Description: Subject identifier based on an phone number. 646 o Change Controller: IETF 648 o Defining Document(s): Section 3 of this document. 650 7.1.3.5. Aliases Subject Identifier Type 652 o Type Name: "aliases" 654 o Type Description: Subject identifier that groups together multiple 655 different subject identifiers for the same subject. 657 o Change Controller: IETF 659 o Defining Document(s): Section 3 of this document. 661 7.1.4. Guidance for Expert Reviewers 663 The Expert Reviewer is expected to review the documentation 664 referenced in a registration request to verify its completeness. The 665 Expert Reviewer must base their decision to accept or reject the 666 request on a fair and impartial assessment of the request. If the 667 Expert Reviewer has a conflict of interest, such as being an author 668 of a defining document referenced by the request, they must recuse 669 themselves from the approval process for that request. In the case 670 where a request is rejected, the Expert Reviewer should provide the 671 requesting party with a written statement expressing the reason for 672 rejection, and be prepared to cite any sources of information that 673 went into that decision. 675 Subject Identifier Types need not be generally applicable and may be 676 highly specific to a particular domain; it is expected that types may 677 be registered for niche or industry-specific use cases. The Expert 678 Reviewer should focus on whether the type is thoroughly documented, 679 and whether its registration will promote or harm interoperability. 680 In most cases, the Expert Reviewer should not approve a request if 681 the registration would contribute to confusion, or amount to a 682 synonym for an existing type. 684 7.2. JSON Web Token Claims Registration 686 This document defines the "sub_id" JWT Claim, which IANA is asked to 687 register in the "JSON Web Token Claims" registry IANA JSON Web Token 688 Claims Registry [IANA.JWT.Claims] established by [RFC7519]. 690 7.2.1. Registry Contents 692 o Claim Name: "sub_id" 694 o Claim Description: Subject Identifier 696 o Change Controller: IESG 698 o Specification Document(s): Section 4.1 of this document. 700 8. References 702 8.1. Normative References 704 [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 705 Writing an IANA Considerations Section in RFCs", BCP 26, 706 RFC 8126, DOI 10.17487/RFC8126, June 2017, 707 . 709 [E164] International Telecommunication Union, "The international 710 public telecommunication numbering plan", 2010, 711 . 713 [IANA.JWT.Claims] 714 IANA, "JSON Web Token Claims", n.d., 715 . 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 723 DOI 10.17487/RFC5321, October 2008, 724 . 726 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 727 DOI 10.17487/RFC5322, October 2008, 728 . 730 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 731 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 732 2014, . 734 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 735 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 736 . 738 [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, 739 DOI 10.17487/RFC7565, May 2015, 740 . 742 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 743 "Security Event Token (SET)", RFC 8417, 744 DOI 10.17487/RFC8417, July 2018, 745 . 747 8.2. Informative References 749 [OpenID.Core] 750 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 751 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 752 . 754 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 755 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 756 . 758 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 759 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 760 2015, . 762 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 763 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 764 . 766 Acknowledgements 768 The authors would like to thank the members of the IETF Security 769 Events working group, as well as those of the OpenID Shared Signals 770 and Events Working Group, whose work provided the original basis for 771 this document. 773 Change Log 775 (This section to be removed by the RFC Editor before publication as 776 an RFC.) 777 Draft 00 - AB - First draft 779 Draft 01 - AB: 781 o Added reference to RFC 5322 for format of "email" claim. 783 o Renamed "iss_sub" type to "iss-sub". 785 o Renamed "id_token_claims" type to "id-token-claims". 787 o Added text specifying the nature of the subjects described by each 788 type. 790 Draft 02 - AB: 792 o Corrected format of phone numbers in examples. 794 o Updated author info. 796 Draft 03 - AB: 798 o Added "account" type for "acct" URIs. 800 o Replaced "id-token-claims" type with "aliases" type. 802 o Added email canonicalization guidance. 804 o Updated semantics for "email", "phone", and "iss-sub" types. 806 Draft 04 - AB: 808 o Added "sub_id" JWT Claim definition, guidance, examples. 810 o Added text prohibiting "aliases" nesting. 812 o Added privacy considerations for identifier correlation. 814 Draft 05 - AB: 816 o Renamed the "phone" type to "phone-number" and its "phone" claim 817 to "phone_number". 819 Draft 06 - AB: 821 o Replaced usage of the word "claim" to describe members of a 822 Subject Identifier with the word "member", in accordance with 823 terminology in RFC7159. 825 o Renamed the "phone-number" type to "phone_number" and "iss-sub" to 826 "iss_sub". 828 o Added normative requirements limiting the use of both "sub" and 829 "sub_id" claims together when processing a JWT. 831 o Clarified that identifier correlation may be acceptable when it is 832 a core part of the use case. 834 o Replaced references to OIDF with IETF in IANA Considerations. 836 o Recommended the appointment of multiple Designated Experts, and a 837 location for the Subject Identifier Types registry. 839 o Added "_" to list of allowed characters in the Type Name for 840 Subject Identifier Types. 842 o Clarified that Subject Identifiers don't provide confidentiality 843 or integrity protection. 845 o Added references to SET, JWT privacy and security considerations. 847 o Added section describing the difference between subject identifier 848 type and principal type that hopefully clarifies things and 849 doesn't just muddy the water further. 851 Authors' Addresses 853 Annabelle Backman (editor) 854 Amazon 856 Email: richanna@amazon.com 858 Marius Scurtescu 859 Coinbase 861 Email: marius.scurtescu@coinbase.com