idnits 2.17.00 (12 Aug 2021) /tmp/idnits57216/draft-ietf-secevent-subject-identifiers-11.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 document date (21 April 2022) is 23 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) == Unused Reference: 'DID' is defined on line 779, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DID' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 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: 23 October 2022 Coinbase 6 P. Jain 7 Fastly 8 21 April 2022 10 Subject Identifiers for Security Event Tokens 11 draft-ietf-secevent-subject-identifiers-11 13 Abstract 15 Security events communicated within Security Event Tokens may support 16 a variety of identifiers to identify subjects related to the event. 17 This specification formalizes the notion of subject identifiers as 18 structured information that describe a subject, and named formats 19 that define the syntax and semantics for encoding subject identifiers 20 as JSON objects. It also defines a registry for defining and 21 allocating names for such formats, as well as the sub_id JSON Web 22 Token (JWT) claim. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 23 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5 59 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Subject Identifiers . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Identifier Formats versus Principal Types . . . . . . . . 6 62 3.2. Identifier Format Definitions . . . . . . . . . . . . . . 6 63 3.2.1. Account Identifier Format . . . . . . . . . . . . . . 6 64 3.2.2. Email Identifier Format . . . . . . . . . . . . . . . 7 65 3.2.3. Issuer and Subject Identifier Format . . . . . . . . 7 66 3.2.4. Opaque Identifier Format . . . . . . . . . . . . . . 8 67 3.2.5. Phone Number Identifier Format . . . . . . . . . . . 8 68 3.2.6. Aliases Identifier Format . . . . . . . . . . . . . . 9 69 4. Subject Identifiers in JWTs . . . . . . . . . . . . . . . . . 10 70 4.1. sub_id Claim . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. sub_id and iss_sub Subject Identifiers . . . . . . . . . 11 72 5. Considerations for Specifications that Define Identifier 73 Formats . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 75 6.1. Identifier Correlation . . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7.1. Confidentiality and Integrity . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Security Event Identifier Formats Registry . . . . . . . 14 80 8.1.1. Registry Location . . . . . . . . . . . . . . . . . . 14 81 8.1.2. Registration Template . . . . . . . . . . . . . . . . 14 82 8.1.3. Initial Registry Contents . . . . . . . . . . . . . . 15 83 8.1.4. Guidance for Expert Reviewers . . . . . . . . . . . . 16 84 8.2. JSON Web Token Claims Registration . . . . . . . . . . . 17 85 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 9.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 As described in Section 1.2 of SET [RFC8417], subjects related to 96 security events may take a variety of forms, including but not 97 limited to a JWT [RFC7519] principal, an IP address, a URL, etc. 98 Different types of subjects may need to be identified in different 99 ways (e.g., a host might be identified by an IP or MAC address, while 100 a user might be identified by an email address). Furthermore, even 101 in the case where the type of the subject is known, there may be 102 multiple ways by which a given subject may be identified. For 103 example, an account may be identified by an opaque identifier, an 104 email address, a phone number, a JWT iss claim and sub claim, etc., 105 depending on the nature and needs of the transmitter and receiver. 106 Even within the context of a given transmitter and receiver 107 relationship, it may be appropriate to identify different accounts in 108 different ways, for example if some accounts only have email 109 addresses associated with them while others only have phone numbers. 110 Therefore it can be necessary to indicate within a SET the mechanism 111 by which a subject is being identified. 113 To address this problem, this specification defines Subject 114 Identifiers - JSON [RFC7159] objects containing information 115 identifying a subject - and Identifier Formats - named sets of rules 116 describing how to encode different kinds of subject identifying 117 information (e.g., an email address, or an issuer and subject pair) 118 as a Subject Identifier. 120 Below is a non-normative example of a Subject Identifier that 121 identifies a subject by email address, using the Email Identifier 122 Format. 124 { 125 "format": "email", 126 "email": "user@example.com" 127 } 129 Figure 1: Example: Subject Identifier using the Email Identifier 130 Format 132 Subject Identifiers are intended to be a general-purpose mechanism 133 for identifying subjects within JSON objects and their usage need not 134 be limited to SETs. Below is a non-normative example of a JWT that 135 uses a Subject Identifier in the sub_id claim (defined in this 136 specification) to identify the JWT Subject. 138 { 139 "iss": "issuer.example.com", 140 "sub_id": { 141 "format": "phone_number", 142 "phone_number": "+12065550100" 143 } 144 } 146 Figure 2: Example: JWT using a Subject Identifier with the 147 "sub_id" claim 149 Usage of Subject Identifiers also need not be limited to identifying 150 JWT Subjects. They are intended as a general-purpose means of 151 expressing identifying information in an unambiguous manner. Below 152 is a non-normative example of a SET containing a hypothetical 153 security event describing the interception of a message, using 154 Subject Identifiers to identify the sender, intended recipient, and 155 interceptor. 157 { 158 "iss": "issuer.example.com", 159 "iat": 1508184845, 160 "aud": "aud.example.com", 161 "events": { 162 "https://secevent.example.com/events/message-interception": { 163 "from": { 164 "format": "email", 165 "email": "alice@example.com" 166 }, 167 "to": { 168 "format": "email", 169 "email": "bob@example.com" 170 }, 171 "interceptor": { 172 "format": "email", 173 "email": "eve@example.com" 174 } 175 } 176 } 177 } 179 Figure 3: Example: SET with an event payload containing multiple 180 Subject Identifiers 182 2. Notational Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 2.1. Definitions 190 This specification utilizes terminology defined in [RFC7159] and 191 [RFC8417]. 193 Within this specification, the terms "Subject" and "subject" refer 194 generically to anything being identified via one or more pieces of 195 information. The term "JWT Subject" refers specifically to the to 196 the subject of a JWT. (i.e., the subject that the JWT asserts claims 197 about) 199 3. Subject Identifiers 201 A Subject Identifier is a JSON [RFC7159] object whose contents may be 202 used to identify a subject within some context. An Identifier Format 203 is a named definition of a set of information that may be used to 204 identify a subject, and the rules for encoding that information as a 205 Subject Identifier; they define the syntax and semantics of Subject 206 Identifiers. A Subject Identifier MUST conform to a specific 207 Identifier Format, and MUST contain a format member whose value is 208 the name of that Identifier Format. 210 Every Identifier Format MUST have a unique name registered in the 211 IANA "Security Event Identifier Formats" registry established by 212 Section 8.1, or a Collision-Resistant Name as defined in [RFC7519]. 213 Identifier Formats that are expected to be used broadly by a variety 214 of parties SHOULD be registered in the "Security Event Identifier 215 Formats" registry. 217 An Identifier Format MAY describe more members than are strictly 218 necessary to identify a subject, and MAY describe conditions under 219 which those members are required, optional, or prohibited. The 220 format member is reserved for use as described in this specification; 221 Identifier Formats MUST NOT declare any rules regarding the format 222 member. 224 Every member within a Subject Identifier MUST match the rules 225 specified for that member by this specification or by Subject 226 Identifier's Identifier Format. A Subject Identifier MUST NOT 227 contain any members prohibited or not described by its Identifier 228 Format, and MUST contain all members required by its Identifier 229 Format. 231 3.1. Identifier Formats versus Principal Types 233 Identifier Formats define how to encode identifying information for a 234 subject. They do not define the type or nature of the subject 235 itself. E.g., While the email Identifier Format declares that the 236 value of the email member is an email address, a subject in a 237 Security Event that is identified by an email Subject Identifier 238 could be an end user who controls that email address, the mailbox 239 itself, or anything else that the transmitter and receiver both 240 understand to be associated with that email address. Consequently 241 Subject Identifiers remove ambiguity around how a subject is being 242 identified, and how to parse an identifying structure, but do not 243 remove ambiguity around how to resolve that identifier to a subject. 244 For example, consider a directory management API that allows callers 245 to identify users and groups through both opaque unique identifiers 246 and email addresses. Such an API could use Subject Identifiers to 247 disambiguate between which of these two types of identifiers is in 248 use. However, the API would have to determine whether the subject is 249 a user or group via some other means, such as by querying a database, 250 interpreting other parameters in the request, or inferring the type 251 from the API contract. 253 3.2. Identifier Format Definitions 255 The following Identifier Formats are registered in the IANA "Security 256 Event Identifier Formats" registry established by Section 8.1. 258 3.2.1. Account Identifier Format 260 The Account Identifier Format identifies a subject using an account 261 at a service provider, identified with an acct URI as defined in 262 [RFC7565]. Subject Identifiers in this format MUST contain a uri 263 member whose value is the acct URI for the subject. The uri member 264 is REQUIRED and MUST NOT be null or empty. The Account Identifier 265 Format is identified by the name account. 267 Below is a non-normative example Subject Identifier for the Account 268 Identifier Format: 270 { 271 "format": "account", 272 "uri": "acct:example.user@service.example.com" 273 } 275 Figure 4: Example: Subject Identifier for the Account Identifier 276 Format 278 3.2.2. Email Identifier Format 280 The Email Identifier Format identifies a subject using an email 281 address. Subject Identifiers in this format MUST contain an email 282 member whose value is a string containing the email address of the 283 subject, formatted as an addr-spec as defined in Section 3.4.1 of 284 [RFC5322]. The email member is REQUIRED and MUST NOT be null or 285 empty. The value of the email member SHOULD identify a mailbox to 286 which email may be delivered, in accordance with [RFC5321]. The 287 Email Identifier Format is identified by the name email. 289 Below is a non-normative example Subject Identifier in the Email 290 Identifier Format: 292 { 293 "format": "email", 294 "email": "user@example.com" 295 } 297 Figure 5: Example: Subject Identifier in the Email Identifier Format 299 3.2.2.1. Email Canonicalization 301 Many email providers will treat multiple email addresses as 302 equivalent. While the domain portion of an [RFC5322] email address 303 is consistently treated as case-insensitive per [RFC1034], some 304 providers treat the local part of the email address as case- 305 insensitive as well, and consider "user@example.com", 306 "User@example.com", and "USER@example.com" as the same email address. 307 This has led users to view these strings as equivalent, driving 308 service providers to implement proprietary email canonicalization 309 algorithms to ensure that email addresses entered by users resolve to 310 the same canonical string. When receiving an Email Subject 311 Identifier, the recipient SHOULD use their implementation's 312 canonicalization algorithm to resolve the email address to the same 313 string used in their system. 315 3.2.3. Issuer and Subject Identifier Format 317 The Issuer and Subject Identifier Format identifies a subject using a 318 pair of iss and sub members, analagous to how subjects are identified 319 using the iss and sub claims in OpenID Connect [OpenID.Core] ID 320 Tokens. These members MUST follow the formats of the iss member and 321 sub member defined by [RFC7519], respectively. Both the iss member 322 and the sub member are REQUIRED and MUST NOT be null or empty. The 323 Issuer and Subject Identifier Format is identified by the name 324 iss_sub. 326 Below is a non-normative example Subject Identifier in the Issuer and 327 Subject Identifier Format: 329 { 330 "format": "iss_sub", 331 "iss": "http://issuer.example.com/", 332 "sub": "145234573" 333 } 335 Figure 6: Example: Subject Identifier in the Issuer and Subject 336 Identifier Format 338 3.2.4. Opaque Identifier Format 340 The Opaque Identifier Format describes a subject that is identified 341 with a string with no semantics asserted beyond its usage as an 342 identifier for the subject, such as a UUID or hash used as a 343 surrogate identifier for a record in a database. Subject Identifiers 344 in this format MUST contain an id member whose value is a JSON string 345 containing the opaque string identifier for the subject. The id 346 member is REQUIRED and MUST NOT be null or empty. The Opaque 347 Identifier Format is identified by the name opaque. 349 Below is a non-normative example Subject Identifier in the Opaque 350 Identifier Format: 352 { 353 "format": "opaque", 354 "id": "11112222333344445555" 355 } 357 Figure 7: Example: Subject Identifier in the Opaque Identifier Format 359 3.2.5. Phone Number Identifier Format 361 The Phone Number Identifier Format identifies a subject using a 362 telephone number. Subject Identifiers in this format MUST contain a 363 phone_number member whose value is a string containing the full 364 telephone number of the subject, including international dialing 365 prefix, formatted according to E.164 [E164]. The phone_number member 366 is REQUIRED and MUST NOT be null or empty. The Phone Number 367 Identifier Format is identified by the name phone_number. 369 Below is a non-normative example Subject Identifier in the Email 370 Identifier Format: 372 { 373 "format": "phone_number", 374 "phone_number": "+12065550100" 375 } 377 Figure 8: Example: Subject Identifier in the Phone Number 378 Identifier Format 380 3.2.6. Aliases Identifier Format 382 The Aliases Identifier Format describes a subject that is identified 383 with a list of different Subject Identifiers. It is intended for use 384 when a variety of identifiers have been shared with the party that 385 will be interpreting the Subject Identifier, and it is unknown which 386 of those identifiers they will recognize or support. Subject 387 Identifiers in this format MUST contain an identifiers member whose 388 value is a JSON array containing one or more Subject Identifiers. 389 Each Subject Identifier in the array MUST identify the same entity. 390 The identifiers member is REQUIRED and MUST NOT be null or empty. It 391 MAY contain multiple instances of the same Identifier Format (e.g., 392 multiple Email Subject Identifiers), but SHOULD NOT contain exact 393 duplicates. This format is identified by the name aliases. 395 aliases Subject Identifiers MUST NOT be nested; i.e., the identifiers 396 member of an aliases Subject Identifier MUST NOT contain a Subject 397 Identifier in the aliases format. 399 Below is a non-normative example Subject Identifier in the Aliases 400 Identifier Format: 402 { 403 "format": "aliases", 404 "identifiers": [ 405 { 406 "format": "email", 407 "email": "user@example.com" 408 }, 409 { 410 "format": "phone_number", 411 "phone_number": "+12065550100" 412 }, 413 { 414 "format": "email", 415 "email": "user+qualifier@example.com" 416 } 417 ] 418 } 419 Figure 9: Example: Subject Identifier in the Aliases Identifier 420 Format 422 4. Subject Identifiers in JWTs 424 4.1. sub_id Claim 426 The sub JWT Claim is defined in Section 4.1.2 of [RFC7519] as 427 containing a string value, and therefore cannot contain a Subject 428 Identifier (which is a JSON object) as its value. This document 429 defines the sub_id JWT Claim, in accordance with Section 4.2 of 430 [RFC7519], as a common claim that identifies the JWT Subject using a 431 Subject Identifier. When present, the value of this claim MUST be a 432 Subject Identifier that identifies the subject of the JWT. The 433 sub_id claim MAY be included in a JWT, whether or not the sub claim 434 is present. When both the sub and sub_id claims are present in a 435 JWT, they MUST identify the same subject, as a JWT has one and only 436 one JWT Subject. 438 When processing a JWT with both sub and sub_id claims, 439 implementations MUST NOT rely on both claims to determine the JWT 440 Subject. An implementation MAY attempt to determine the JWT Subject 441 from one claim and fall back to using the other if it determines it 442 does not understand the format of the first claim. For example, an 443 implementation may attempt to use sub_id, and fall back to using sub 444 upon finding that sub_id contains a Subject Identifier whose format 445 is not recognized by the implementation. 447 Below are non-normative examples of JWTs containing the sub_id claim: 449 { 450 "iss": "issuer.example.com", 451 "sub_id": { 452 "format": "email", 453 "email": "user@example.com" 454 } 455 } 457 Figure 10: Example: JWT containing a "sub_id" claim and no "sub" 458 claim 460 { 461 "iss": "issuer.example.com", 462 "sub": "user@example.com", 463 "sub_id": { 464 "format": "email", 465 "email": "user@example.com" 466 } 467 } 469 Figure 11: Example: JWT where both the "sub" and "sub_id" claims 470 identify the JWT Subject using the same identifier 472 { 473 "iss": "issuer.example.com", 474 "sub": "liz@example.com", 475 "sub_id": { 476 "format": "email", 477 "email": "elizabeth@example.com" 478 } 479 } 481 Figure 12: Example: JWT where both the "sub" and "sub_id" claims 482 identify the JWT Subject using different values of the same 483 identifier type 485 { 486 "iss": "issuer.example.com", 487 "sub": "user@example.com", 488 "sub_id": { 489 "format": "account", 490 "uri": "acct:example.user@service.example.com" 491 } 492 } 494 Figure 13: Example: JWT where the "sub" and "sub_id" claims 495 identify the JWT Subject via different types of identifiers 497 4.2. sub_id and iss_sub Subject Identifiers 499 The sub_id claim MAY contain an iss_sub Subject Identifier. In this 500 case, the JWT's iss claim and the Subject Identifier's iss member MAY 501 be different. For example, in OpenID Connect [OpenID.Core] client 502 may construct such a JWT when sending JWTs back to its OpenID Connect 503 Identity Provider, in order to identify the JWT Subject using an 504 identifier known to be understood by both parties. Similarly, the 505 JWT's sub claim and the Subject Identifier's sub member MAY be 506 different. For example, this may be used by an OpenID Connect client 507 to communicate the JWT Subject's local identifier at the client back 508 to its Identity Provider. 510 Below are non-normative examples of a JWT where the iss claim and iss 511 member within the sub_id claim are the same, and a JWT where they are 512 different. 514 { 515 "iss": "issuer.example.com", 516 "sub_id": { 517 "format": "iss_sub", 518 "iss": "issuer.example.com", 519 "sub": "example_user" 520 } 521 } 523 Figure 14: Example: JWT with an "iss_sub" Subject Identifier 524 where JWT issuer and JWT Subject issuer are the same 526 { 527 "iss": "client.example.com", 528 "sub_id": { 529 "format": "iss_sub", 530 "iss": "issuer.example.com", 531 "sub": "example_user" 532 } 533 } 535 Figure 15: Example: JWT with an "iss_sub" Subject Identifier 536 where the JWT issuer and JWT Subject issuer are different 538 { 539 "iss": "client.example.com", 540 "sub": "client_user", 541 "sub_id": { 542 "format": "iss_sub", 543 "iss": "issuer.example.com", 544 "sub": "example_user" 545 } 546 } 548 Figure 16: Example: JWT with an "iss_sub" Subject Identifier 549 where the JWT "iss" and "sub" claims differ from the JWT 550 Subject's "iss" and "sub" members 552 5. Considerations for Specifications that Define Identifier Formats 554 Identifier Format definitions MUST NOT make assertions or 555 declarations regarding the subject being identified by the Subject 556 Identifier (e.g., an Identifier Format cannot be defined as 557 specifically identifying human end users), as such statements are 558 outside the scope of Identifier Formats and Subject Identifiers, and 559 expanding that scope for some Identifier Formats but not others would 560 harm interoperability, as applications that depend on this expanded 561 scope to disambiguate the subject type would be unable to use 562 Identifier Formats that do not provide such rules. 564 6. Privacy Considerations 566 6.1. Identifier Correlation 568 The act of presenting two or more identifiers for a single subject 569 together (e.g., within an aliases Subject Identifier, or via the sub 570 and sub_id JWT claims) may communicate more information about the 571 subject than was intended. For example, the entity to which the 572 identifiers are presented now knows that both identifiers relate to 573 the same subject, and may be able to correlate additional data based 574 on that. When transmitting Subject Identifiers, the transmitter 575 SHOULD take care that they are only transmitting multiple identifiers 576 together when it is known that the recipient already knows that the 577 identifiers are related (e.g., because they were previously sent to 578 the recipient as claims in an OpenID Connect ID Token), or when 579 correlation is essential to the use case. Implementers must consider 580 such risks, and specs that use subject identifiers must provide 581 appropriate privacy considerations of their own. 583 The considerations described in Section 6 of [RFC8417] also apply 584 when Subject Identifiers are used within SETs. The considerations 585 described in Section 12 of [RFC7519] also apply when Subject 586 Identifiers are used within JWTs. 588 7. Security Considerations 590 7.1. Confidentiality and Integrity 592 This specification does not define any mechanism for ensuring the 593 confidentiality or integrity of a Subject Identifier. Where such 594 properties are required, implementations MUST use mechanisms provided 595 by the containing format (e.g., integrity protecting SETs or JWTs 596 using JWS [RFC7515]), or at the transport layer or other layer in the 597 application stack (e.g., using TLS [RFC8446]). 599 Further considerations regarding confidentiality and integrity of 600 SETs can be found in Section 5.1 of [RFC8417]. 602 8. IANA Considerations 604 8.1. Security Event Identifier Formats Registry 606 This document defines Identifier Formats, for which IANA is asked to 607 create and maintain a new registry titled "Security Event Identifier 608 Formats". Initial values for the Security Event Identifier Formats 609 registry are given in Section 3. Future assignments are to be made 610 through the Expert Review registration policy [BCP26] and shall 611 follow the template presented in Section 8.1.2. 613 It is suggested that multiple Designated Experts be appointed who are 614 able to represent the perspectives of different applications using 615 this specification, in order to enable broadly informed review of 616 registration decisions. In cases where a registration decision could 617 be perceived as creating a conflict of interest for a particular 618 Expert, that Expert should defer to the judgment of the other 619 Experts. 621 8.1.1. Registry Location 623 (This section to be removed by the RFC Editor before publication as 624 an RFC.) 626 The authors recommend that the Identifier Formats registry be located 627 at https://www.iana.org/assignments/secevent/. 629 8.1.2. Registration Template 631 Format Name 632 The name of the Identifier Format, as described in Section 3. The 633 name MUST be an ASCII string consisting only of lower-case 634 characters ("a" - "z"), digits ("0" - "9"), underscores ("_"), and 635 hyphens ("-"), and SHOULD NOT exceed 20 characters in length. 637 Format Description 638 A brief description of the Identifier Format. 640 Change Controller 641 For formats defined in documents published by the IETF or its 642 working groups, list "IETF". For all other formats, list the name 643 of the party responsible for the registration. Contact 644 information such as mailing address, email address, or phone 645 number may also be provided. 647 Defining Document(s) 648 A reference to the document or documents that define the 649 Identifier Format. The definition MUST specify the name, format, 650 and meaning of each member that may occur within a Subject 651 Identifier of the defined format, as well as whether each member 652 is optional, required, prohibited, or the circumstances under 653 which the member may be optional, required, or prohibited. URIs 654 that can be used to retrieve copies of each document SHOULD be 655 included. 657 8.1.3. Initial Registry Contents 659 8.1.3.1. Account Identifier Format 661 * Format Name: "account" 663 * Format Description: Subject identifier based on acct URI. 665 * Change Controller: IETF 667 * Defining Document(s): Section 3 of this document. 669 8.1.3.2. Decentralized Identifier Format 671 * Format Name: "did" 673 * Format Description: Subject identifier based on a Decentralized 674 Identifier (DID) URL. 676 * Change Controller: IETF 678 * Defining Document(s): Section 3 of this document. 680 8.1.3.3. Email Identifier Format 682 * Format Name: email 684 * Format Description: Subject identifier based on email address. 686 * Change Controller: IETF 688 * Defining Document(s): Section 3 of this document. 690 8.1.3.4. Issuer and Subject Identifier Format 692 * Format Name: "iss_sub" 693 * Format Description: Subject identifier based on an issuer and 694 subject. 696 * Change Controller: IETF 698 * Defining Document(s): Section 3 of this document. 700 8.1.3.5. Opaque Identifier Format 702 * Format Name: "opaque" 704 * Format Description: Subject identifier based on an opaque string. 706 * Change Controller: IETF 708 * Defining Document(s): Section 3 of this document. 710 8.1.3.6. Phone Number Identifier Format 712 * Format Name: "phone_number" 714 * Format Description: Subject identifier based on an phone number. 716 * Change Controller: IETF 718 * Defining Document(s): Section 3 of this document. 720 8.1.3.7. Aliases Identifier Format 722 * Format Name: "aliases" 724 * Format Description: Subject identifier that groups together 725 multiple different subject identifiers for the same subject. 727 * Change Controller: IETF 729 * Defining Document(s): Section 3 of this document. 731 8.1.4. Guidance for Expert Reviewers 733 The Expert Reviewer is expected to review the documentation 734 referenced in a registration request to verify its completeness. The 735 Expert Reviewer must base their decision to accept or reject the 736 request on a fair and impartial assessment of the request. If the 737 Expert Reviewer has a conflict of interest, such as being an author 738 of a defining document referenced by the request, they must recuse 739 themselves from the approval process for that request. In the case 740 where a request is rejected, the Expert Reviewer should provide the 741 requesting party with a written statement expressing the reason for 742 rejection, and be prepared to cite any sources of information that 743 went into that decision. 745 Identifier Formats need not be generally applicable and may be highly 746 specific to a particular domain; it is expected that formats may be 747 registered for niche or industry-specific use cases. The Expert 748 Reviewer should focus on whether the format is thoroughly documented, 749 and whether its registration will promote or harm interoperability. 750 In most cases, the Expert Reviewer should not approve a request if 751 the registration would contribute to confusion, or amount to a 752 synonym for an existing format. 754 8.2. JSON Web Token Claims Registration 756 This document defines the sub_id JWT Claim, which IANA is asked to 757 register in the "JSON Web Token Claims" registry IANA JSON Web Token 758 Claims Registry [IANA.JWT.Claims] established by [RFC7519]. 760 8.2.1. Registry Contents 762 * Claim Name: "sub_id" 764 * Claim Description: Subject Identifier 766 * Change Controller: IESG 768 * Specification Document(s): Section 4.1 of this document. 770 9. References 772 9.1. Normative References 774 [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 775 Writing an IANA Considerations Section in RFCs", BCP 26, 776 RFC 8126, DOI 10.17487/RFC8126, June 2017, 777 . 779 [DID] World Wide Web Consortium (W3C), "Decentralized 780 Identifiers (DIDs) v1.0", 2021, 781 . 783 [E164] International Telecommunication Union, "The international 784 public telecommunication numbering plan", 2010, 785 . 787 [IANA.JWT.Claims] 788 IANA, "JSON Web Token Claims", n.d., 789 . 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 797 DOI 10.17487/RFC5321, October 2008, 798 . 800 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 801 DOI 10.17487/RFC5322, October 2008, 802 . 804 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 805 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 806 2014, . 808 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 809 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 810 . 812 [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, 813 DOI 10.17487/RFC7565, May 2015, 814 . 816 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, 817 "Security Event Token (SET)", RFC 8417, 818 DOI 10.17487/RFC8417, July 2018, 819 . 821 9.2. Informative References 823 [OpenID.Core] 824 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 825 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 826 . 828 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 829 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 830 . 832 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 833 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 834 2015, . 836 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 837 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 838 . 840 Acknowledgements 842 The authors would like to thank the members of the IETF Security 843 Events working group, as well as those of the OpenID Shared Signals 844 and Events Working Group, whose work provided the original basis for 845 this document. We would also like to acknowledge Aaron Parecki, 846 Denis Pinkas, Justin Richer, Mike Jones and other members of the 847 working group for reviewing this document. 849 Change Log 851 (This section to be removed by the RFC Editor before publication as 852 an RFC.) 854 Draft 00 - AB - First draft 856 Draft 01 - AB: 858 * Added reference to RFC 5322 for format of email claim. 860 * Renamed iss_sub type to iss-sub. 862 * Renamed id_token_claims type to id-token-claims. 864 * Added text specifying the nature of the subjects described by each 865 type. 867 Draft 02 - AB: 869 * Corrected format of phone numbers in examples. 871 * Updated author info. 873 Draft 03 - AB: 875 * Added account type for acct URIs. 877 * Replaced id-token-claims type with aliases type. 879 * Added email canonicalization guidance. 881 * Updated semantics for email, phone, and iss-sub types. 883 Draft 04 - AB: 885 * Added sub_id JWT Claim definition, guidance, examples. 887 * Added text prohibiting aliases nesting. 889 * Added privacy considerations for identifier correlation. 891 Draft 05 - AB: 893 * Renamed the phone type to phone-number and its phone claim to 894 phone_number. 896 Draft 06 - AB: 898 * Replaced usage of the word "claim" to describe members of a 899 Subject Identifier with the word "member", in accordance with 900 terminology in RFC7159. 902 * Renamed the phone-number type to phone_number and iss-sub to 903 iss_sub. 905 * Added normative requirements limiting the use of both sub and 906 sub_id claims together when processing a JWT. 908 * Clarified that identifier correlation may be acceptable when it is 909 a core part of the use case. 911 * Replaced references to OIDF with IETF in IANA Considerations. 913 * Recommended the appointment of multiple Designated Experts, and a 914 location for the Subject Identifier Types registry. 916 * Added "_" to list of allowed characters in the Type Name for 917 Subject Identifier Types. 919 * Clarified that Subject Identifiers don't provide confidentiality 920 or integrity protection. 922 * Added references to SET, JWT privacy and security considerations. 924 * Added section describing the difference between subject identifier 925 type and principal type that hopefully clarifies things and 926 doesn't just muddy the water further. 928 Draft 07 - AB: 930 * Emphasized that the spec is about identifiers, not the things they 931 identify: 933 - Renamed "Subject Identifier Type" to "Identifier Format". 935 - Renamed subject_type to format. 937 - Renamed "Security Event Subject Identifier Type Registry" to 938 "Security Event Identifier Format Registry". 940 - Added new section with guidance for specs defining Identifier 941 Formats, with normative prohibition on formats that describe 942 the subject itself, rather than the identifier. 944 * Clarified the meaning of "subject": 946 - Defined "subject" as applying generically and "JWT Subject" as 947 applying specifically to the subject of a JWT. 949 - Replaced most instances of the word "principal" with "subject". 951 * Added opaque Identifier Format 953 Draft 08 - JR, AB: 955 * Added did Identifier Format 957 * Alphabetized identifier format definitions 959 * Replaced "type" with "format" in places that had been missed in 960 the -07 change. (mostly IANA Considerations) 962 * Miscellaneous editorial fixes 964 Draft 09 - AB: 966 * Miscellaneous editorial fixes 968 Draft 10 - PJ: 970 * Added author 972 * Editorial nits 974 Draft 11 - PJ: 976 * Miscellaneous editorial fixes 978 * Moved aliases to the last in identifier format definitions 980 * Acknowledged individual reviewers 982 Authors' Addresses 984 Annabelle Backman (editor) 985 Amazon 986 Email: richanna@amazon.com 988 Marius Scurtescu 989 Coinbase 990 Email: marius.scurtescu@coinbase.com 992 Prachi Jain 993 Fastly 994 Email: prachi.jain1288@gmail.com