<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.6.10) -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-secevent-subject-identifiers-18" number="9493" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
<front>
<title abbrev="secevent-subject-identifiers">Subject abbrev="Security Event Subject Identifiers">Subject Identifiers for
Security Event Tokens</title>
<seriesInfo name="RFC" value="9493"/>
<author initials="A." surname="Backman" fullname="Annabelle Backman" role="editor">
<organization>Amazon</organization>
<address>
<email>richanna@amazon.com</email>
</address>
</author>
<author initials="M." surname="Scurtescu" fullname="Marius Scurtescu">
<organization>Coinbase</organization>
<address>
<email>marius.scurtescu@coinbase.com</email>
</address>
</author>
<author initials="P." surname="Jain" fullname="Prachi Jain">
<organization>Fastly</organization>
<address>
<email>prachi.jain1288@gmail.com</email>
</address>
</author>
<date year="2023" month="June" day="24"/> month="December"/>
<area>Security</area>
<workgroup>Security Events Working Group</workgroup>
<keyword>Internet-Draft</keyword> Events</workgroup>
<keyword>jwt</keyword>
<abstract>
<t>Security events communicated within Security Event Tokens may support
a variety of identifiers to identify subjects related to the event.
This specification formalizes the notion of subject identifiers Subject Identifiers as
structured information that describe describes a subject, subject and named formats that
define the syntax and semantics for encoding subject identifiers Subject Identifiers as JSON
objects. It also defines establishes a registry for defining and allocating
names for such formats, formats as well as the "sub_id" JSON Web Token (JWT) claim.</t> "sub_id"
Claim.</t>
</abstract>
</front>
<middle>
<section anchor="intro"><name>Introduction</name> anchor="intro">
<name>Introduction</name>
<t>As described in Section 1.2 of SET <xref target="RFC8417"/>, target="RFC8417" sectionFormat="of"
section="1.2"/> ("<xref target="RFC8417" format="title"/>"), subjects
related to security events may take a variety of forms, including but
not limited to a JWT <xref target="RFC7519"/> principal, an IP address,
a URL, etc. Different types of subjects may need to be identified in
different ways (e.g., a user might be identified by an email address or address,
a phone number number, or an account number). Furthermore, even in the case
where the type of the subject is known, there may be multiple ways by
which a given subject may be identified. For example, an account may be
identified by an opaque identifier, an email address, a phone number, a
JWT "iss" claim Claim and "sub" claim, Claim, etc., depending on the nature and needs
of the transmitter and receiver. Even within the context of a given
transmitter and receiver relationship, it may be appropriate to identify
different accounts in different ways, for example example, if some accounts only
have email addresses associated with them while others only have phone
numbers. Therefore Therefore, it can be necessary to indicate within a SET the
mechanism by which a subject is being identified.</t>
<t>To address this problem, this specification defines Subject
Identifiers - as JSON <xref target="RFC8259"/> objects containing
information identifying a subject - and defines Identifier Formats - as named
sets of rules describing how to encode different kinds of subject identifying
subject-identifying information (e.g., an email address, address or an issuer and
subject pair) as a Subject Identifier.</t>
<t>Below is a non-normative example of a Subject Identifier that
identifies a subject by email address, using the Email Identifier
Format.</t>
<figure title="Example: anchor="figexampleintro">
<name>Example: Subject Identifier using Using the Email Identifier Format" anchor="figexampleintro"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "email",
"email": "user@example.com"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<t>Subject Identifiers are intended to be a general-purpose mechanism for identifying subjects within JSON objects objects, and their usage need not be limited to SETs. Below is a non-normative example of a JWT that uses a Subject Identifier in the JWT "sub_id" claim Claim (defined in this specification) to identify the JWT Subject.</t>
<figure title="Example: anchor="figexampleintro2">
<name>Example: JWT using Using a Subject Identifier with the "sub_id" claim" anchor="figexampleintro2"><artwork><![CDATA[
{ JWT "sub_id" Claim</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub_id": {
"format": "phone_number",
"phone_number": "+12065550100"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<t>Usage of Subject Identifiers also need not be limited to identifying JWT Subjects. They are intended as a general-purpose means of expressing identifying information in an unambiguous manner. Below is a non-normative example of a SET containing a hypothetical security event describing the interception of a message, using Subject Identifiers to identify the sender, intended recipient, and interceptor.</t>
<figure title="Example: anchor="figexampleintro3">
<name>Example: SET with an event payload containing multiple Event Payload Containing Multiple Subject Identifiers" anchor="figexampleintro3"><artwork><![CDATA[
{ Identifiers</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"iat": 1508184845,
"aud": "aud.example.com",
"events": {
"https://secevent.example.com/events/message-interception": {
"from": {
"format": "email",
"email": "alice@example.com"
},
"to": {
"format": "email",
"email": "bob@example.com"
},
"interceptor": {
"format": "email",
"email": "eve@example.com"
}
}
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="conv"><name>Notational anchor="conv">
<name>Notational Conventions</name>
<t>The
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP 14 BCP 14 <xref target="RFC2119"/><xref target="RFC8417"/>.</t> target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<section anchor="defn"><name>Definitions</name> anchor="defn">
<name>Definitions</name>
<t>This specification utilizes terminology defined in <xref target="RFC8259"/> and <xref target="RFC8417"/>.</t>
<t>Within this specification, the terms "Subject" and "subject" refer generically to anything being identified via one or more pieces of information. The term "JWT Subject" refers specifically to the subject of a JWT (i.e., the subject that the JWT asserts claims about).</t>
</section>
</section>
<section anchor="sub-ids"><name>Subject anchor="sub-ids">
<name>Subject Identifiers</name>
<t>A Subject Identifier is a JSON object <xref target="RFC8259"/> object whose
contents may be used to identify a subject within some context. An
Identifier Format is a named definition of a set of information that may
be used to identify a subject, subject and the rules for encoding that
information as a Subject Identifier; they these rules define the syntax and
semantics of Subject Identifiers. A Subject Identifier MUST
<bcp14>MUST</bcp14> conform to a specific Identifier Format, Format and MUST
<bcp14>MUST</bcp14> contain a "format" member whose value is the name of
that Identifier Format.</t>
<t>Every Identifier Format MUST <bcp14>MUST</bcp14> have a unique name
registered in the IANA "Security Event Identifier Formats" registry
established by in <xref target="iana-formats"/>, target="iana-formats"/> or a Collision-Resistant
Name as defined in <xref target="RFC7519"/>. Identifier Formats that
are expected to be used broadly by a variety of parties SHOULD
<bcp14>SHOULD</bcp14> be registered in the "Security Event Identifier
Formats" registry.</t>
<t>An Identifier Format MAY <bcp14>MAY</bcp14> describe more members than
are strictly necessary to identify a subject, subject and MAY <bcp14>MAY</bcp14>
describe conditions under which those members are required, optional, or
prohibited. The "format" member is reserved for use as described in
this specification; Identifier Formats MUST NOT <bcp14>MUST NOT</bcp14> declare
any rules regarding the "format" member.</t>
<t>Every member within a Subject Identifier MUST <bcp14>MUST</bcp14> match
the rules specified for that member by this specification or by a Subject
Identifier's Identifier Format. A Subject Identifier MUST NOT <bcp14>MUST
NOT</bcp14> contain any members prohibited or not described by its
Identifier Format, Format and MUST <bcp14>MUST</bcp14> contain all members required
by its Identifier Format.</t>
<section anchor="identifier-formats-versus-principal-types"><name>Identifier anchor="identifier-formats-versus-principal-types">
<name>Identifier Formats versus Principal Types</name>
<t>Identifier Formats define how to encode identifying information for
a subject. Unlike Principal Types, they do not define the type or
nature of the subject itself. For example, while the "email" Email
Identifier Format declares that the value of the "email" member is an
email address, a subject in a Security Event security event that is identified by an "email"
Email Subject Identifier could be an end user who controls that
email address, the mailbox itself, or anything else that the
transmitter and receiver both understand to be associated with that
email address. Consequently Consequently, Subject Identifiers remove ambiguity
around how a subject is being identified, identified and how to parse an
identifying structure, but they do not remove ambiguity
around how to resolve that identifier to for a subject. For example,
consider a directory management API that allows callers to identify
users and groups through both opaque unique identifiers and email
addresses. Such an API could use Subject Identifiers to disambiguate
between which of these two types of identifiers is in use. However,
the API would have to determine whether the subject is a user or group
via some other means, such as by querying a database, interpreting
other parameters in the request, or inferring the type from the API
contract.</t>
</section>
<section anchor="identifier-format-definitions"><name>Identifier anchor="identifier-format-definitions">
<name>Identifier Format Definitions</name>
<t>The following Identifier Formats are registered in the IANA
"Security Event Identifier Formats" registry established by in <xref
target="iana-formats"/>.</t>
<t>Since the subject identifier format Subject Identifier Format conveys semantic information,
applications SHOULD <bcp14>SHOULD</bcp14> choose the most specific possible
format for the identifier in question. For example, an email address
can be conveyed using a <spanx style="verb">mailto:</spanx> "mailto:" URI and the <spanx style="verb">uri</spanx> identifier format, URI Identifier
Format, but since the value is known to be an email address, the
application should prefer to use the "email" identifier format Email Identifier Format
instead.</t>
<section anchor="sub-id-acct"><name>Account anchor="sub-id-acct">
<name>Account Identifier Format</name>
<t>The Account Identifier Format identifies a subject using an account at a service provider, identified with an "acct" URI as defined in <xref target="RFC7565"/>. An account is an arrangement or agreement through which a user gets access to a service and gets a unique identity with the service provider. Subject Identifiers in this format MUST <bcp14>MUST</bcp14> contain a "uri" member whose value is the "acct" URI for the subject. The "uri" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or empty. The Account Identifier Format is identified by a value of "account" in the "format" member.</t>
<t>Below is a non-normative example Subject Identifier for the Account Identifier Format:</t>
<figure title="Example: anchor="figexamplesubidaccount">
<name>Example: Subject Identifier for the Account Identifier Format" anchor="figexamplesubidaccount"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "account",
"uri": "acct:example.user@service.example.com"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-email"><name>Email anchor="sub-id-email">
<name>Email Identifier Format</name>
<t>The Email Identifier Format identifies a subject using an email address. Subject Identifiers in this format MUST <bcp14>MUST</bcp14> contain an "email" member whose value is a string containing the email address of the subject, formatted as an "addr-spec" as defined in Section 3.4.1 of <xref target="RFC5322"/>. target="RFC5322" sectionFormat="of" section="3.4.1"/>. The "email" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or empty. The value of the "email" member MUST <bcp14>MUST</bcp14> identify a mailbox to which email may be delivered, in accordance with <xref target="RFC5321"/>. The Email Identifier Format is identified by the name "email".</t>
<t>Below is a non-normative example Subject Identifier in the Email Identifier Format:</t>
<figure title="Example: anchor="figexamplesubidemail">
<name>Example: Subject Identifier in the Email Identifier Format" anchor="figexamplesubidemail"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "email",
"email": "user@example.com"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<section anchor="email-canon"><name>Email anchor="email-canon">
<name>Email Canonicalization</name>
<t>Many email providers will treat multiple email addresses as
equivalent. While the domain portion of an <xref target="RFC5322"/> email address <xref
target="RFC5322"/> is consistently treated as case-insensitive per
<xref target="RFC1034"/>, most providers treat the local part of
the email address as case-insensitive as well, well and consider
"user@example.com", "User@example.com", and "USER@example.com" as
the same email address. Some providers also treat dots (".") as
optional; for example, "user.name@example.com",
"username@example.com", "u.s.e.r.name@example.com", and
"u.s.e.r.n.a.m.e@example.com" might all be treated as
equivalent. This has led users to view these strings as
equivalent, driving service providers to implement proprietary
email canonicalization algorithms to ensure that email addresses
entered by users resolve to the same canonical string. Email
canonicalization is not standardized, and there is no way for the
event recipient to determine the mail provider’s provider's canonicalization
method. Therefore, the recipient SHOULD <bcp14>SHOULD</bcp14> apply its
own canonicalization algorithm to incoming events that reproduces in order to
reproduce the translation done by the local email system.</t>
</section>
</section>
<section anchor="sub-id-iss-sub"><name>Issuer anchor="sub-id-iss-sub">
<name>Issuer and Subject Identifier Format</name>
<t>The Issuer and Subject Identifier Format identifies a subject
using a pair of "iss" and "sub" members, analogous to how subjects
are identified using the JWT "iss" and "sub" claims Claims in <xref
target="OpenID.Core">OpenID Connect</xref> ID Tokens. These members MUST
<bcp14>MUST</bcp14> follow the formats of the "iss" member and "sub"
member defined by <xref target="RFC7519"/>, respectively. Both the
"iss" member and the "sub" member are REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT
<bcp14>MUST NOT</bcp14> be null or empty. The Issuer and Subject
Identifier Format is identified by the name "iss_sub".</t>
<t>Below is a non-normative example Subject Identifier in the Issuer
and Subject Identifier Format:</t>
<figure title="Example: anchor="figexamplesubidisssub">
<name>Example: Subject Identifier in the Issuer and Subject Identifier Format" anchor="figexamplesubidisssub"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "iss_sub",
"iss": "https://issuer.example.com/",
"sub": "145234573"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-opaque"><name>Opaque anchor="sub-id-opaque">
<name>Opaque Identifier Format</name>
<t>The Opaque Identifier Format describes a subject that is identified with a string with no semantics asserted beyond its usage as an identifier for the subject, such as a UUID Universally Unique Identifier (UUID) or hash used as a surrogate identifier for a record in a database. Subject Identifiers in this format MUST <bcp14>MUST</bcp14> contain an "id" member whose value is a JSON string containing the opaque string identifier for the subject. The "id" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or empty. The Opaque Identifier Format is identified by the name "opaque".</t>
<t>Below is a non-normative example Subject Identifier in the Opaque Identifier Format:</t>
<figure title="Example: anchor="figexamplesubidopaque">
<name>Example: Subject Identifier in the Opaque Identifier Format" anchor="figexamplesubidopaque"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "opaque",
"id": "11112222333344445555"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-phone"><name>Phone anchor="sub-id-phone">
<name>Phone Number Identifier Format</name>
<t>The Phone Number Identifier Format identifies a subject using a telephone number. Subject Identifiers in this format MUST <bcp14>MUST</bcp14> contain a "phone_number" member whose value is a string containing the full telephone number of the subject, including an international dialing prefix, formatted according to <xref target="E164">E.164</xref>. The "phone_number" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or empty. The Phone Number Identifier Format is identified by the name "phone_number".</t>
<t>Below is a non-normative example Subject Identifier in the Email Phone Number Identifier Format:</t>
<figure title="Example: anchor="figexamplesubidphone">
<name>Example: Subject Identifier in the Phone Number Identifier Format" anchor="figexamplesubidphone"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "phone_number",
"phone_number": "+12065550100"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-did"><name>Decentralized anchor="sub-id-did">
<name>Decentralized Identifier (DID) Format</name>
<t>The Decentralized Identifier (DID) Format identifies a subject
using a Decentralized Identifier (DID) DID URL as defined in <xref target="DID"/>. Subject
Identifiers in this format MUST <bcp14>MUST</bcp14> contain a "URL" "url"
member whose value is a DID URL for the DID Subject being
identified. The value of the "url" member MUST <bcp14>MUST</bcp14> be a
valid DID URL and MAY <bcp14>MAY</bcp14> be a bare DID. The "url" member
is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or
empty. The Decentralized Identifier Format is identified by the name
"did".</t>
<t>Below are non-normative example Subject Identifiers for the Decentralized Identifier Format:</t>
<figure title="Example: anchor="figexamplesubiddidbare">
<name>Example: Subject Identifier for the Decentralized Identifier Format, identifying Identifying a subject Subject with a bare DID" anchor="figexamplesubiddidbare"><artwork><![CDATA[
{ Bare DID</name>
<sourcecode type="json"><![CDATA[{
"format": "did",
"url": "did:example:123456"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplesubiddidcomplex">
<name>Example: Subject Identifier for the Decentralized Identifier Format, identifying Identifying a subject Subject with a DID URL with non-empty path Non-empty Path and query components" anchor="figexamplesubiddidcomplex"><artwork><![CDATA[
{ Query Components</name>
<sourcecode type="json"><![CDATA[{
"format": "did",
"url": "did:example:123456/did/url/path?versionId=1"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-uri"><name>Uniform anchor="sub-id-uri">
<name>Uniform Resource Identifier (URI) Format</name>
<t>The Uniform Resource Identifier (URI) Format identifies a subject using a URI as defined in <xref target="RFC3986"/>. This identifier format Identifier Format makes no assumptions or guarantees with regard to the content, scheme, or reachability of the URI within the field. Subject Identifiers in this format MUST <bcp14>MUST</bcp14> contain a "uri" member whose value is a URI for the subject being identified. The "uri" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST NOT</bcp14> be null or empty. The URI format Format is identified by the name "uri".</t>
<t>Below are non-normative example Subject Identifiers for the URI format:</t> Format:</t>
<figure title="Example: anchor="figexamplesubiduidbare">
<name>Example: Subject Identifier for the URI Format, identifying Identifying a subject Subject with a website URI" anchor="figexamplesubiduidbare"><artwork><![CDATA[
{ Website URI</name>
<sourcecode type="json"><![CDATA[{
"format": "uri",
"uri": "https://user.example.com/"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplesubidurnbare">
<name>Example: Subject Identifier for the URI Format, identifying Identifying a subject Subject with a random URN" anchor="figexamplesubidurnbare"><artwork><![CDATA[
{ Random URN</name>
<sourcecode type="json"><![CDATA[{
"format": "uri",
"uri": "urn:uuid:4e851e98-83c4-4743-a5da-150ecb53042f"
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="sub-id-aliases"><name>Aliases anchor="sub-id-aliases">
<name>Aliases Identifier Format</name>
<t>The Aliases Identifier Format describes a subject that is
identified with a list of different Subject Identifiers. It is
intended for use when a variety of identifiers have been shared with
the party that will be interpreting the Subject Identifier, and it
is unknown which of those identifiers they will recognize or
support. Subject Identifiers in this format MUST <bcp14>MUST</bcp14>
contain an "identifiers" member whose value is a JSON array
containing one or more Subject Identifiers. Each Subject Identifier
in the array MUST <bcp14>MUST</bcp14> identify the same entity. The
"identifiers" member is REQUIRED <bcp14>REQUIRED</bcp14> and MUST NOT <bcp14>MUST
NOT</bcp14> be null or empty. It MAY <bcp14>MAY</bcp14> contain
multiple instances of the same Identifier Format (e.g., multiple
Email Subject Identifiers), Identifiers) but SHOULD NOT <bcp14>SHOULD NOT</bcp14> contain
exact duplicates. This format is identified by the name
"aliases".</t>
<t>"aliases" Subject Identifiers MUST NOT <bcp14>MUST NOT</bcp14> be nested; nested,
i.e., the "identifiers" member of an "aliases" Subject Identifier MUST NOT
<bcp14>MUST NOT</bcp14> contain a Subject Identifier in the "aliases" format.</t> Aliases
Identifier Format.</t>
<t>Below is a non-normative example Subject Identifier in the
Aliases Identifier Format:</t>
<figure title="Example: anchor="figexamplesubididtoken">
<name>Example: Subject Identifier in the Aliases Identifier Format" anchor="figexamplesubididtoken"><artwork><![CDATA[
{ Format</name>
<sourcecode type="json"><![CDATA[{
"format": "aliases",
"identifiers": [
{
"format": "email",
"email": "user@example.com"
},
{
"format": "phone_number",
"phone_number": "+12065550100"
},
{
"format": "email",
"email": "user+qualifier@example.com"
}
]
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
</section>
</section>
<section anchor="jwt-claims"><name>Subject anchor="jwt-claims">
<name>Subject Identifiers in JWTs</name>
<section anchor="jwt-claims-sub_id"><name><spanx style="verb">sub_id</spanx> anchor="jwt-claims-sub_id">
<name>JWT "sub_id" Claim</name>
<t>The "sub" JWT "sub" Claim is defined in Section 4.1.2 of <xref target="RFC7519"/> target="RFC7519"
sectionFormat="of" section="4.1.2"/> as containing a string value, and therefore value;
therefore, it cannot contain a Subject Identifier (which is a JSON
object) as its value. This document defines the "sub_id" JWT "sub_id" Claim,
in accordance with Section 4.2 of <xref target="RFC7519"/>, target="RFC7519" sectionFormat="of"
section="4.2"/>, as a common claim that identifies the JWT Subject
using a Subject Identifier. When present, the value of this claim MUST
<bcp14>MUST</bcp14> be a Subject Identifier that identifies the
subject of the JWT. The JWT "sub_id" claim MAY Claim <bcp14>MAY</bcp14> be included
in a JWT, whether or not the JWT "sub" claim Claim is present. When both the JWT
"sub" and "sub_id" claims Claims are present in a JWT, they MUST
<bcp14>MUST</bcp14> identify the same subject, as a JWT has one and
only one JWT Subject.</t>
<t>When processing a JWT with both JWT "sub" and "sub_id" claims, Claims,
implementations MUST NOT <bcp14>MUST NOT</bcp14> rely on both claims to
determine the JWT Subject. An implementation MAY <bcp14>MAY</bcp14>
attempt to determine the JWT Subject from one claim and fall back to
using the other if it determines it does not understand the format of
the first claim. For example, an implementation may attempt to use "sub_id",
"sub_id" and fall back to using "sub" upon finding that "sub_id"
contains a Subject Identifier whose with a format that is not recognized by
the implementation.</t>
<t>Below are non-normative examples of JWTs containing the JWT "sub_id" claim:</t>
Claim:</t>
<figure title="Example: anchor="figexamplejwtsubidemail">
<name>Example: JWT containing Containing a "sub_id" claim JWT "sub_id" Claim and no "sub" claim" anchor="figexamplejwtsubidemail"><artwork><![CDATA[
{ No "sub" Claim</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub_id": {
"format": "email",
"email": "user@example.com"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplejwtsamesubid">
<name>Example: JWT where both Where the "sub" JWT "sub" and "sub_id" claims identify "sub_id" Claims Identify the JWT Subject using Using the same identifier" anchor="figexamplejwtsamesubid"><artwork><![CDATA[
{ Same Identifier</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub": "user@example.com",
"sub_id": {
"format": "email",
"email": "user@example.com"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplejwtdiffsubvalues">
<name>Example: JWT where both Where the "sub" JWT "sub" and "sub_id" claims identify "sub_id" Claims Identify the JWT Subject using different values Using Different Values of the same identifier type" anchor="figexamplejwtdiffsubvalues"><artwork><![CDATA[
{ Same Identifier Type</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub": "liz@example.com",
"sub_id": {
"format": "email",
"email": "elizabeth@example.com"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplejwtdiffsubtype">
<name>Example: JWT where Where the "sub" JWT "sub" and "sub_id" claims identify "sub_id" Claims Identify the JWT Subject via different types Different Types of identifiers" anchor="figexamplejwtdiffsubtype"><artwork><![CDATA[
{ Identifiers</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub": "user@example.com",
"sub_id": {
"format": "account",
"uri": "acct:example.user@service.example.com"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
<section anchor="subid-and-isssub-subject-identifiers"><name><spanx style="verb">sub_id</spanx> anchor="subid-and-isssub-subject-identifiers">
<name>JWT "sub_id" Claim and <spanx style="verb">iss_sub</spanx> "iss_sub" Subject Identifiers</name> Identifier</name>
<t>The JWT "sub_id" claim MAY Claim <bcp14>MAY</bcp14> contain an "iss_sub" Subject Identifier. In this case, the JWT's "iss" claim Claim and the Subject Identifier's "iss" member MAY <bcp14>MAY</bcp14> be different. For example, in an <xref target="OpenID.Core">OpenID Connect</xref> client may construct such a JWT when sending JWTs back to its OpenID Connect Identity Provider, Provider in order to identify the JWT Subject using an identifier known to be understood by both parties. Similarly, the JWT's "sub" claim Claim and the Subject Identifier's "sub" member MAY <bcp14>MAY</bcp14> be different. For example, this may be used by an OpenID Connect client to communicate the JWT Subject's local identifier at the client back to its Identity Provider.</t>
<t>Below are non-normative examples of a JWT where the JWT "iss" claim Claim and "iss" member within the JWT "sub_id" claim Claim are the same, same and a JWT where they are different.</t>
<figure title="Example: anchor="figexamplejwtsameiss">
<name>Example: JWT with an "iss_sub" "iss_sub" Subject Identifier where Where the JWT issuer Issuer and JWT Subject issuer are Issuer Are the same" anchor="figexamplejwtsameiss"><artwork><![CDATA[
{ Same</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com",
"sub_id": {
"format": "iss_sub",
"iss": "issuer.example.com",
"sub": "example_user"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplejwtdiffiss">
<name>Example: JWT with an "iss_sub" "iss_sub" Subject Identifier where Where the JWT issuer Issuer and JWT Subject issuer are different" anchor="figexamplejwtdiffiss"><artwork><![CDATA[
{ Issuer Are Different</name>
<sourcecode type="json"><![CDATA[{
"iss": "client.example.com",
"sub_id": {
"format": "iss_sub",
"iss": "issuer.example.com",
"sub": "example_user"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
<figure title="Example: anchor="figexamplejwtdiffisssub">
<name>Example: JWT with an "iss_sub" "iss_sub" Subject Identifier where Where the JWT "iss" "iss" and "sub" claims differ "sub" Claims Differ from the JWT Subject's "iss" "iss" and "sub" members" anchor="figexamplejwtdiffisssub"><artwork><![CDATA[
{ "sub" Members</name>
<sourcecode type="json"><![CDATA[{
"iss": "client.example.com",
"sub": "client_user",
"sub_id": {
"format": "iss_sub",
"iss": "issuer.example.com",
"sub": "example_user"
}
}
]]></artwork></figure>
}]]></sourcecode>
</figure>
</section>
</section>
<section anchor="implementer"><name>Considerations anchor="implementer">
<name>Considerations for Specifications that Define Identifier Formats</name>
<t>Identifier Format definitions MUST NOT <bcp14>MUST NOT</bcp14> make assertions or declarations regarding the subject being identified by the Subject Identifier (e.g., an Identifier Format cannot be defined as specifically identifying human end users), as such users). Such statements are outside the scope of Identifier Formats and Subject Identifiers, and expanding Identifiers. Expanding that scope for some Identifier Formats but not others would harm interoperability, as interoperability because applications that depend on this expanded scope to disambiguate the subject type would be unable to use Identifier Formats that do not provide such rules.</t>
</section>
<section anchor="privacy"><name>Privacy anchor="privacy">
<name>Privacy Considerations</name>
<section anchor="identifier-correlation"><name>Identifier anchor="identifier-correlation">
<name>Identifier Correlation</name>
<t>The act of presenting two or more identifiers for a single subject
together (e.g., within an "aliases" Subject Identifier, Identifier or via the
JWT "sub" and "sub_id" JWT claims) Claims) may communicate more information about
the subject than was intended. For example, the entity to which the
identifiers are presented now knows that both identifiers relate to
the same subject, subject and may be able to correlate additional data based on
that. When transmitting Subject Identifiers, the transmitter SHOULD
<bcp14>SHOULD</bcp14> take care that they are only transmitting
multiple identifiers together when it is known that the recipient
already knows that the identifiers are related (e.g., because they
were previously sent to the recipient as claims in an OpenID Connect
ID Token), Token) or when correlation is essential to the use case.
Implementers must consider such risks, and specifications that use subject identifiers
Subject Identifiers must provide appropriate privacy considerations of
their own.</t>
<t>The considerations described in Section 6 of <xref target="RFC8417"/> target="RFC8417"
sectionFormat="of" section="6"/> also apply when Subject Identifiers
are used within SETs. The considerations described in Section 12 of <xref target="RFC7519"/>
target="RFC7519" sectionFormat="of" section="12"/> also apply when
Subject Identifiers are used within JWTs.</t>
</section>
</section>
<section anchor="security"><name>Security anchor="security">
<name>Security Considerations</name>
<t>This specification does not define any mechanism for ensuring the
confidentiality or integrity of a Subject Identifier. Where such
properties are required, implementations MUST <bcp14>MUST</bcp14> use
mechanisms provided by the containing format (e.g., integrity protecting
SETs or JWTs using JWS JSON Web Signature (JWS) <xref target="RFC7515"/>), target="RFC7515"/>) or
at the transport layer or other layer in the application stack (e.g.,
using TLS <xref target="RFC8446"/>).</t>
<t>Further considerations regarding confidentiality and integrity of
SETs can be found in Section 5.1 of <xref target="RFC8417"/>.</t> target="RFC8417" sectionFormat="of"
section="5.1"/>.</t>
</section>
<section anchor="iana"><name>IANA anchor="iana">
<name>IANA Considerations</name>
<section anchor="iana-formats"><name>Security anchor="iana-formats">
<name>Security Event Identifier Formats Registry</name>
<t>This document defines Identifier Formats, for which IANA is asked to create has created and maintain maintains a new registry titled "Security Event Identifier Formats". Initial values for the Security "Security Event Identifier Formats Formats" registry are given in <xref target="sub-ids"/>. Future assignments are to be made through the Specification Required registration policy <xref target="BCP26"/> and shall follow the template presented in <xref target="iana-formats-template"/>.</t>
<t>It is suggested that multiple Designated Experts designated experts be appointed who are able to represent the perspectives of different applications using this specification, specification in order to enable broadly informed review of registration decisions.</t>
<section anchor="registry-location"><name>Registry Location</name>
<t>(This section to be removed by the RFC Editor before publication as an RFC.)</t>
<t>The authors recommend that the Identifier Formats registry be located at <spanx style="verb">https://www.iana.org/assignments/secevent/</spanx>.</t>
</section>
<section anchor="iana-formats-template"><name>Registration anchor="iana-formats-template">
<name>Registration Template</name>
<dl newline="true">
<dt>Format Name</dt> Name:</dt>
<dd>
<t>The name of the Identifier Format, as described in <xref
target="sub-ids"/>. The name MUST <bcp14>MUST</bcp14> be an ASCII
string consisting only of lower-case lowercase characters ("a" - "z"),
digits ("0" - "9"), underscores ("_"), and hyphens ("-"), ("-") and SHOULD NOT
<bcp14>SHOULD NOT</bcp14> exceed 20 characters in length.</t>
</dd>
<dt>Format Description</dt> Description:</dt>
<dd>
<t>A brief description of the Identifier Format.</t>
</dd>
<dt>Change Controller</dt> Controller:</dt>
<dd>
<t>For formats defined in documents published by the IETF or its
working groups, list "IETF". For all other formats, list the
name of the party responsible for the registration. Contact information
information, such as mailing address, email address, or phone number
number, must also be provided.</t>
</dd>
<dt>Defining Document(s)</dt>
<dt>Reference:</dt>
<dd>
<t>A reference to the document or documents that define the
Identifier Format. The reference document(s) MUST
<bcp14>MUST</bcp14> specify the name, format,and format, and meaning of each
member that may occur within a Subject Identifier of the defined format,
format as well as whether each member is optional, required required, or conditional,
conditional and the circumstances under which these optional or
conditional fields would be used. URIs that can be used to
retrieve copies of each document SHOULD <bcp14>SHOULD</bcp14> be
included.</t>
</dd>
</dl>
</section>
<section anchor="iana-formats-init"><name>Initial anchor="iana-formats-init">
<name>Initial Registry Contents</name>
<section anchor="account-identifier-format"><name>Account anchor="account-identifier-format">
<name>Account Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "account"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>account</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on <spanx style="verb">acct</spanx> URI.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref
"acct" URI</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="email-identifier-format"><name>Email anchor="email-identifier-format">
<name>Email Identifier Format</name>
<t><list style="symbols">
<t>Format Name: <spanx style="verb">email</spanx></t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>email</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on
an email address.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref address</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="issuer-and-subject-identifier-format"><name>Issuer anchor="issuer-and-subject-identifier-format">
<name>Issuer and Subject Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "iss_sub"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>iss_sub</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on an
issuer and subject.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref subject</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="opaque-identifier-format"><name>Opaque anchor="opaque-identifier-format">
<name>Opaque Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "opaque"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>opaque</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on an
opaque string.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref string</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="phone-number-identifier-format"><name>Phone anchor="phone-number-identifier-format">
<name>Phone Number Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "phone_number"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>phone_number</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on an a
phone number.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref number</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="decentralized-identifier-format"><name>Decentralized anchor="decentralized-identifier-format">
<name>Decentralized Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "did"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>did</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on a
decentralized identifier (DID).</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref (DID)</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="uniform-resource-identifier-format"><name>Uniform anchor="uniform-resource-identifier-format">
<name>Uniform Resource Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "uri"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>uri</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on a uniform resource identifier (URI).</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref
Uniform Resource Identifier (URI)</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
<section anchor="aliases-identifier-format"><name>Aliases anchor="aliases-identifier-format">
<name>Aliases Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "aliases"</t>
<t>Format Description: Subject identifier
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>aliases</dd>
<dt>Format Description:</dt> <dd>Subject Identifier that groups
together multiple different subject identifiers Subject Identifiers for the same subject.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref
subject</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of this document.</t>
</list></t>
RFC 9493</dd>
</dl>
</section>
</section>
<section anchor="iana-formats-expert"><name>Guidance anchor="iana-formats-expert">
<name>Guidance for Expert Reviewers</name>
<t>The Expert Reviewer is expected to review the documentation referenced in a registration request to verify its completeness. The Expert Reviewer must base their decision to accept or reject the request on a fair and impartial assessment of the request. If the Expert Reviewer has a conflict of interest, such as being an author of a defining document referenced by the request, they must recuse themselves from the approval process for that request.</t>
<t>Identifier Formats need not be generally applicable and may be highly specific to a particular domain; it is expected that formats may be registered for niche or industry-specific use cases. The Expert Reviewer should focus on whether the format is thoroughly documented, documented and whether its registration will promote or harm interoperability. In most cases, the Expert Reviewer should not approve a request if the registration would contribute to confusion, confusion or amount to a synonym for an existing format.</t>
</section>
</section>
<section anchor="json-web-token-claims-registration"><name>JSON anchor="json-web-token-claims-registration">
<name>JSON Web Token Claims Registration</name>
<t>This document defines the <spanx style="verb">sub_id</spanx> JWT "sub_id" Claim, which IANA is asked to register has registered in the "JSON Web Token Claims" registry <xref target="IANA.JWT.Claims">IANA JSON Web Token Claims Registry</xref> target="IANA.JWT.Claims"/> established by <xref target="RFC7519"/>.</t>
<section anchor="registry-contents"><name>Registry anchor="registry-contents">
<name>Registry Contents</name>
<t><list style="symbols">
<t>Claim Name: "sub_id"</t>
<t>Claim Description: Subject Identifier</t>
<t>Change Controller: IETF</t>
<t>Specification Document(s): <xref
<dl spacing="compact" newline="false">
<dt>Claim Name:</dt> <dd>sub_id</dd>
<dt>Claim Description:</dt> <dd>Subject Identifier</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref
target="jwt-claims-sub_id"/> of this document.</t>
</list></t> RFC 9493</dd>
</dl>
</section>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='BCP26' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></author>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/bcp26">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</referencegroup>
<reference anchor="E164" target="https://www.itu.int/rec/T-REC-E.164-201011-I/en">
<front>
<title>The
<title>E.164: The international public telecommunication numbering plan</title>
<author >
<organization>International Telecommunication Union</organization>
<author>
<organization>ITU-T</organization>
</author>
<date month="November" year="2010"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="E.164"/>
</reference>
<reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignments/jwt">
<front>
<title>JSON Web Token Claims</title>
<author >
<author>
<organization>IANA</organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="DID" target="https://www.w3.org/TR/did-core/">
<front>
<title>Decentralized Identifiers (DIDs) v1.0</title>
<author >
<organization>World Wide Web Consortium (W3C)</organization> fullname="Manu Sporny" role="editor">
<organization>Digital Bazaar</organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor='RFC8417' target='https://www.rfc-editor.org/info/rfc8417'>
<front>
<title>Security Event Token (SET)</title>
<author fullname='P. Hunt' initials='P.' role='editor' surname='Hunt'><organization/></author>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='W. Denniss' initials='W.' surname='Denniss'><organization/></author>
<author fullname='M. Ansari' initials='M.' surname='Ansari'><organization/></author>
<date month='July' year='2018'/>
<abstract><t>This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8417'/>
<seriesInfo name='DOI' value='10.17487/RFC8417'/>
</reference>
<reference anchor='RFC7519' target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>
<reference anchor='RFC8259' target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organization/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC7565' target='https://www.rfc-editor.org/info/rfc7565'>
<front>
<title>The 'acct' URI Scheme</title>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.</t></abstract>
</front>
<seriesInfo name='RFC' value='7565'/>
<seriesInfo name='DOI' value='10.17487/RFC7565'/>
</reference>
<reference anchor='RFC5322' target='https://www.rfc-editor.org/info/rfc5322'>
<front>
<title>Internet Message Format</title> fullname="Amy Guy" role="editor">
<organization>Digital Bazaar</organization>
</author>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'><organization/></author>
<date month='October' year='2008'/>
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor='RFC5321' target='https://www.rfc-editor.org/info/rfc5321'>
<front>
<title>Simple Mail Transfer Protocol</title> fullname="Markus Sabadello" role="editor">
<organization>Danube Tech</organization>
</author>
<author fullname='J. Klensin' initials='J.' surname='Klensin'><organization/></author>
<date month='October' year='2008'/>
<abstract><t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5321'/>
<seriesInfo name='DOI' value='10.17487/RFC5321'/>
</reference>
<reference anchor='RFC3986' target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> fullname="Drummond Reed" role="editor">
<organization>Evernym/Avast</organization>
</author>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organization/></author> fullname="Dave Longley">
<organization>Digital Bazaar</organization>
</author>
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/></author> fullname="Orie Steele">
<organization>Transmute</organization>
</author>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/></author> fullname="Christopher Allen">
<organization>Blockchain Commons</organization>
</author>
<date month='January' year='2005'/>
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t></abstract> month="July" year="2022"/>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8417.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7565.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references title='Informative References'>
<references>
<name>Informative References</name>
<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html">
<front>
<title>OpenID Connect Core 1.0</title> 1.0 incorporating errata set 1</title>
<author initials="N." surname="Sakimura" fullname="Nat Sakimura">
<organization>Nomura Research Institute, Ltd.</organization>
</author>
<author initials="J." surname="Bradley" fullname="John Bradley">
<organization>Ping Identity</organization>
</author>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
</author>
<author initials="B." surname="de Medeiros" fullname="Breno de Medeiros">
<organization>Google</organization>
</author>
<author initials="C." surname="Mortimore" fullname="Chuck Mortimore">
<organization>Salesforce</organization>
</author>
<date year="2014" month="November"/>
</front>
</reference>
<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organization/></author>
<date month='November' year='1987'/>
<abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>
<reference anchor='RFC7515' target='https://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</reference>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
</references>
</references>
<section numbered="no" anchor="acknowledgements"><name>Acknowledgements</name> numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>The authors would like to thank the members of the IETF Security
Events working group, Working Group, as well as those of the OpenID Shared Signals and
Events Working Group, whose work provided the original basis for this
document. We would also like to acknowledge Aaron Parecki, Denis Pinkas, Justin Richer, Mike Jones <contact fullname="Aaron
Parecki"/>, <contact fullname="Denis Pinkas"/>, <contact
fullname="Justin Richer"/>, <contact fullname="Mike Jones"/>, and other
members of the working group for reviewing this document.</t>
</section>
<section numbered="no" anchor="change-log"><name>Change Log</name>
<t>(This section to be removed by the RFC Editor before publication as an RFC.)</t>
<t>Draft 00 - AB - First draft</t>
<t>Draft 01 - AB:</t>
<t><list style="symbols">
<t>Added reference to RFC 5322 for format of <spanx style="verb">email</spanx> claim.</t>
<t>Renamed <spanx style="verb">iss_sub</spanx> type to <spanx style="verb">iss-sub</spanx>.</t>
<t>Renamed <spanx style="verb">id_token_claims</spanx> type to <spanx style="verb">id-token-claims</spanx>.</t>
<t>Added text specifying the nature of the subjects described by each type.</t>
</list></t>
<t>Draft 02 - AB:</t>
<t><list style="symbols">
<t>Corrected format of phone numbers in examples.</t>
<t>Updated author info.</t>
</list></t>
<t>Draft 03 - AB:</t>
<t><list style="symbols">
<t>Added <spanx style="verb">account</spanx> type for <spanx style="verb">acct</spanx> URIs.</t>
<t>Replaced <spanx style="verb">id-token-claims</spanx> type with <spanx style="verb">aliases</spanx> type.</t>
<t>Added email canonicalization guidance.</t>
<t>Updated semantics for <spanx style="verb">email</spanx>, <spanx style="verb">phone</spanx>, and <spanx style="verb">iss-sub</spanx> types.</t>
</list></t>
<t>Draft 04 - AB:</t>
<t><list style="symbols">
<t>Added <spanx style="verb">sub_id</spanx> JWT Claim definition, guidance, examples.</t>
<t>Added text prohibiting <spanx style="verb">aliases</spanx> nesting.</t>
<t>Added privacy considerations for identifier correlation.</t>
</list></t>
<t>Draft 05 - AB:</t>
<t><list style="symbols">
<t>Renamed the <spanx style="verb">phone</spanx> type to <spanx style="verb">phone-number</spanx> and its <spanx style="verb">phone</spanx> claim to <spanx style="verb">phone_number</spanx>.</t>
</list></t>
<t>Draft 06 - AB:</t>
<t><list style="symbols">
<t>Replaced usage of the word "claim" to describe members of a Subject Identifier with the word "member", in accordance with terminology in RFC8259.</t>
<t>Renamed the <spanx style="verb">phone-number</spanx> type to <spanx style="verb">phone_number</spanx> and <spanx style="verb">iss-sub</spanx> to <spanx style="verb">iss_sub</spanx>.</t>
<t>Added normative requirements limiting the use of both <spanx style="verb">sub</spanx> and <spanx style="verb">sub_id</spanx> claims together when processing a JWT.</t>
<t>Clarified that identifier correlation may be acceptable when it is a core part of the use case.</t>
<t>Replaced references to OIDF with IETF in IANA Considerations.</t>
<t>Recommended the appointment of multiple Designated Experts, and a location for the Subject Identifier Types registry.</t>
<t>Added "_" to list of allowed characters in the Type Name for Subject Identifier Types.</t>
<t>Clarified that Subject Identifiers don't provide confidentiality or integrity protection.</t>
<t>Added references to SET, JWT privacy and security considerations.</t>
<t>Added section describing the difference between subject identifier type and principal type that hopefully clarifies things and doesn't just muddy the water further.</t>
</list></t>
<t>Draft 07 - AB:</t>
<t><list style="symbols">
<t>Emphasized that the spec is about identifiers, not the things they identify:
<list style="symbols">
<t>Renamed "Subject Identifier Type" to "Identifier Format".</t>
<t>Renamed <spanx style="verb">subject_type</spanx> to <spanx style="verb">format</spanx>.</t>
<t>Renamed "Security Event Subject Identifier Type Registry" to "Security Event Identifier Format Registry".</t>
<t>Added new section with guidance for specs defining Identifier Formats, with normative prohibition on formats that describe the subject itself, rather than the identifier.</t>
</list></t>
<t>Clarified the meaning of "subject":
<list style="symbols">
<t>Defined "subject" as applying generically and "JWT Subject" as applying specifically to the subject of a JWT.</t>
<t>Replaced most instances of the word "principal" with "subject".</t>
</list></t>
<t>Added <spanx style="verb">opaque</spanx> Identifier Format</t>
</list></t>
<t>Draft 08 - JR, AB:</t>
<t><list style="symbols">
<t>Added <spanx style="verb">did</spanx> Identifier Format</t>
<t>Alphabetized identifier format definitions</t>
<t>Replaced "type" with "format" in places that had been missed in the -07 change. (mostly IANA Considerations)</t>
<t>Miscellaneous editorial fixes</t>
</list></t>
<t>Draft 09 - AB:</t>
<t><list style="symbols">
<t>Miscellaneous editorial fixes</t>
</list></t>
<t>Draft 10 - PJ:</t>
<t><list style="symbols">
<t>Added author</t>
<t>Editorial nits</t>
</list></t>
<t>Draft 11 - PJ:</t>
<t><list style="symbols">
<t>Miscellaneous editorial fixes</t>
<t>Moved aliases to the last in identifier format definitions</t>
<t>Acknowledged individual reviewers</t>
</list></t>
<t>Draft 12 - PJ:</t>
<t><list style="symbols">
<t>Restore the DID format that was removed in -11</t>
<t>Added a generic "URI" format</t>
<t>Normative advice on choosing the format</t>
</list></t>
<t>Draft 13 - PJ:</t>
<t><list style="symbols">
<t>Editorial nits found during AD review</t>
</list></t>
<t>Draft 14 - PJ:</t>
<t><list style="symbols">
<t>Fix IANA issues found during AD review</t>
</list></t>
<t>Draft 15 - PJ:</t>
<t><list style="symbols">
<t>Fix issues found during review</t>
</list></t>
<t>Draft 16 - PJ:</t>
<t><list style="symbols">
<t>Change controller updated to IETF</t>
</list></t>
<t>Draft 17 -PJ:</t>
<t><list style="symbols">
<t>Fixed nits identified during IESG reviews</t>
</list></t>
<t>Draft 18 -PJ:</t>
<t><list style="symbols">
<t>Fixed issues identified during IESG reviews</t>
</list></t>
</section>
</back>
<!-- ##markdown-source:
H4sIALBAl2QAA81923LbSJLoO78Cy34Ye5ekRVlyu9UxsaOW3bNy+HZkORwb
PRNWESiKaIMABwVIZjs0sb9xfu98yclbXXCjJHd7Yv1gm0BdszKz8o7pdDqq
0irTR9G7evGrjqvoNNF5lS5TXZpoWZTROx3XZVpto+dX8CI6Lz7p3IzUYlHq
q6PI6Fjj86nh7tPUdx8lRZyrNYydlGoJr3S1nO7qMJ0/HSWqgg77e/uPp3tP
pvsHoxgeXBblFuaqklG6KY+iqqxNtb+398Pe/mikSq2O3CpH10X56bIs6s1R
a+Um+gCv0vwy+iu+Hn3SW2ibHEWneaXLXFfTZ7jK0chUKk8+qqzIYSFbbUab
9Cj6pSriSWSKsir10sD/tmv8z99h/rpaFeXRKJqOIviT5uYoOp5FP6n401rl
9IyBcJznaqGzTDfeFeWlytPfVJUWObRZq98KfqHXKs2OojKNVwp6/kXRq1lc
rOl1WeCh6SStinLUmPzVLHoHG6+0ietg+leqTGvTetWc/aRI84UyOpx/Td1m
xnb7SyyNaCWNid/OohcqDbf8tlTxKvVPm9P9rEyVbcPJNtR+9iu0n+8/ffqX
S3zME+VFuYZ+VxogHf108nb/yVF09vPJ0/n+E3jwfP7k4IhGEmw+X2lYFB4s
TaayaFMvsjSOKp1pGHBd52lMr6K8Xi90iYixyeRQKlVe6uooWlXVxhw9enR9
fT1Lq3oGIz4qdfzofHr2/GT6fAazTvf35nvz+fT0kea+Dh8i2bHFMLuQ884K
3uepHLrF/vke/Dw9fn08e/HhfHaSqXRtGvt78e7N6+iDXjA9RtxieO0qVzNY
yiNlTHqZr5EcHv16XQ0uGGaG389OnzUmfQa0m1elytLfdNJgFA+gqXkYXc1n
e4OLuH5MSzg/e5SkyTQuSv1oaH6g1CyJPgBroD2eFDlSXlqvowcfHp88bIBq
fz4apfkyRI83G52fPpudwBSN9fNzHC5HTofvo6EVF9A2TWbAFx6ZjY6NPIB1
U2da/3T+cW+2qtZZsKDXxZVGfMJDPOjubyrbZIp5DaSqPqXrulT2ORPOa1V1
3hBkXhf4KDrTRqsyXgFqGdhcXelJ9LJKZqO+WV4ANypVkultc5IXxSpvv6FJ
3iIx8PECR+0bEnjMC+CPpjngK+RVOot+ar2lQeFlWZgCOWzPgNAFDvuVTnQK
rZrD/lTqvOh7TeP+tSguM9076MkseoV4s4azag55sqrjT92XNOA7lWkD+BTD
oNPpNFILAzgfw7rdhaL5QvFUDORwnVarNO+/LoGLbiNTbzYwYaSiK+CpGpoU
yyi4/aKqsD+xMd2OJip1RsPDywp4Gs08i4C/pSZCxIS+wkWIBJA0DbXMC3oK
c8hYjbkU9IZrNK7qEgZ39AMdqhXgXgKsvkwXGhYrvScR3IoEvYRnqoxtukxz
TVOabV6pz9TQAEeHyWKWIXQeFwki1cBSiJsVvGPY3CkAKTOFDA0tAAqXKax3
S6PRYxwNJ1JZViAA4CcujuczNZCGrHKCE1zDvYv/4irHsIiPaTJu89AHwGof
RjFy0lnER79OkwRxCxh4WSQALQTQl+9S/Hkz+nPwZ3RsHNAQnogH1Ho+28cz
ePf8PPry5d/wxjqYf39zM+k9YdNCMESbSn3STZzBjcG20jzOaoLqoq7wuKMs
XacykopgNzLj94fzH25u4HKFHulGZXiU0enbSCVJqQ0CKHp/9nIS6SoG4D9L
l0tdIu5W2w3A0yMQryfXPAMghztF2nHiOl6rLVwJenY5w7FrA9xwnV6uqlaf
xRYXQle/XQtQIPTYrIB7yL1MT/JIxXFRw9D88CGs82cQSFa6RPKdELxwDXi+
MQgn0TW8YqTEXeAmCEEt+pnoU15c5xN8Cu1wX7C2dZ1V6QYENNoALO96BRwN
FnSZ4vi2t7T2O8HVIJZ/VmvoPQnX22kruy426h918LycdGAxaUFiIoc6To0Z
M54SBSA+y28+wwlgIlxWhBoFwwSEDyB0JmE4P2MBAowtN4A0IJ/QSxBuNOy1
nBH7sjyNoFqAEPO5wo4WHkOdGaMB+c0q3QCeOiiozaYsAA0B3RvMzmOOgM10
8WnCjIRBHKWAlMVa+/ZFnm2jlbrSTRgi8zCmiFPHonEzazxYGKXA0w/7huAG
RnSOyLFEKQH2EMP5wB7g8odxFbAi3AEAGbm/BZQiOkdwrTWK7alZh2gUoN9C
4+kEKDQanReOCirk7gCrRabXE/7V5PWWM/YpbVNmbMJt9g+R9oW30ikqZp4h
z7cnQUzVLXNKp+qHRiQnvj+Ve8DoijCprOHGtOwPx1gV1wgeYvs6OEhQvxLT
cyVt2wuyzKNDEswNgAJqQTo70kal5UNk8aoHKADdn3QGi0rxfV7kU6dOOJQi
xO525UvOHZQJ4AMn21pdbXAjeP7P6UUHdrCQf/7zn6MvIHCMebfjo2hMo4wn
+JD/C8+Qa/5F1oYa0Hh0w12Pou+W6aW8oZuIxds/j5/zsz5V/vaVjW9AvunB
JlWyIpUnju0D/etcgxow3dTlpjAhtiORhofqrg6hkPCmp/ODJaW4PHWp+WrB
iwwmCe4yoCmUCu52gsgh6chqIv4+WAhHc3IAs9IHTFMJv25T3MMGw8LuOJEM
Hp4qMucj+gcwdBYeIJ2vzHkUfSGZM0AC4j0fmfdQ26j1DNr8x3x/78nh4SHo
h3tjaHIzjBT7HazABTMa9ELFMsfob7LIvwlkEDPe0/mgHNOHIiirDZxdiAsB
xAyJsHrbRC+i3i5uwS2DU+vPG6SygG922Aay4DyqgTst0su6qFFiAXWtvDP2
IPsOeKSKVtsN3hIgyYLm3hTPQoZXWXNDrDdW7FawdINws3yhD3ZtrDIIiXLi
YQKXarpJoQUL4G6SorwH1qWEYvPDvafzpwdPDw7poaoRD/GfbgeWPz2aWq3Y
Wu/CHo+48SPZ7TSEgxsBUb2E0f3vAQ4orxwfBI0m1k1GyE1ubOtxVdx/2EWx
2D1oAOj7jw4Q6R19ZP9Gwh2i3Mddfg5YSeSJ9yGh3kZts0IlIa464bUHzZCE
XxeVtUCdFDmOghIaaDMwxlVTmQnUGrSjfQI6RVOpicav3r87H0/43+j1G/r/
2fP/8/707Pkz/P+7/zp++dL9h1uM4Meb9y/lPf7P9zx58+rV89fPuPOr4/8e
M5aP37w9P33z+vjl2HJjtCXXaxIRS23VDzwi4AkVs46G+vXTydtofiBC0P4c
FaBQ/QLaeUZapAUCMP/8BnW+8M+oR8uuq1R0bNA90rzIisttFFwdDbEL99Ka
9oMVqdsjT1ggh1EBznKGYyfg8y+QRoFTE4dEhpSREKryLQ552ZEpo6tURSjQ
wp2MalIEfCRmjS5gmsyJaeJoHLBomS1YpcwXKlLuyn2QzvRs0nhHt7C9KUEK
1yUKoGSojNSiqKuHs36R48t3MMQ0TUwvVo6Oe+90ZOxDci8I4HiTkApj1WrA
H5AQGndUINqJtEI6hmg+AKfjvCs3yZVC8nDiUIoBA/JxC9gMlFvnn1jRSETr
hg2FBdJgzAGh90ccYHurfab/Usfd9sGZCB8ggrOzncGiRxc0vAvbA/kUNLf8
Ey5HUu/5aK5UhtqwWK4AmKygqqpXhAbdFPSv7lHQVKTIKRACUlSwaSy2HunS
CneaDNxAZU1bXVfTGXvDkzaVWmSpWbEK/+UL2tSnYmNCew5ZLk6KDNrAoUzP
tEnRk1RFr3EJxJ9aTILtMmjv6qpYtHdkdSD1wBE42ZtwZlEC7wdiRFNCaBja
qLJCFUW47KJv5/fZNIC6F+WBUXsLIXEWPkxadk7Lhu5pXGXblr48gOmNAQFX
EuHLNQpDoj5XK5YGeSKco9T/qFPYGsB+wzcbnQLozSuQyiqyyyBra6NcijY3
YEdXbMpEmHbujy5//rHvmOw9CJ2Bs5GFZSs0C0BUZWKFw9YaHBJbKnD2gwGS
g77xKuAIsjTZAXMVHmqx7TMYFPSiO/qfTA+F7aJ93Kyj5nzrDsRDHedCRcDD
E2ZOq56J+hhElrkh7fkO9gco9pwJwNWA5P/Wmjujc7Rjtu/22/70jSystGnd
GNJFlsQQBM0BpO/zLP2k28uaCJMuBGSOV7PZsrSWu7YBszI6W7btjmzVInRj
UbSHdgVRjb+emffKBLajJ5U+s6RbBqFsk6Hw9WS6Jk87dA9mxUWdJWRagMkA
JchkDDcDoUVZZLLa1jrIzgZPFsVnAYjYh0Qe0pnRfpuD1soFKHjMacjzb40c
HbNhewEAfXRMApLCPrI+4kIUXhd4HZE+ijBSZQFTEQrttAcyaQimAV83BJuG
ZcW6byZk/xcM2jUhjATrLrIr3TJqlXKTO1xtYBWcgUmRD6soAXKMQSPaol4N
uh4J5MdvT+W6ykDFBhEP/m2rtnigbO+h2Aw8T/j3csXAF2O4XNkN3xD0aBl0
YXnv0L0D4MCZGXWQhQ+o10lqGBpop13o6lqjYZuuFMZ5RJLrwns7wvlTskTD
6DDrfxXXoHyVjHc49TVNTfIGzqNZIyDfAxqW2x4H8YQAaAkGJJ2TgElmaLZz
TNh1pcj7AMAoxSSbKJA+lNETr/SQdZ96AnqAiFHRevmSR84JAguRA/AkXZb2
HiK2gpq42wWRmCIjVpfnRYGWdBcOOiKFcVkgJngncoOJ8s39zQUy1C2A0+rm
KfgBuSHu/kpvjZOHQxY+QYdFJjeok6riVVEYHnZdmMrLv5vCmHSRaTs0X8wh
PuNm6WBI7Wq7jJqOMHE38Pp04ix3F9iqKo4uovdnp05NuACwXXS3x6zBODg4
MZu8X5bTdRg8Ng22HpkVYfqG1U/oVZvmNdOFa5rD+Sp0a3z33XfRsXjDuvhl
db2piuPqhrBnuHGvFV4A411uyIkiFO9S2DWIJVcpW9T8fWRtKWOcdMyA7JXP
nxyifH7sx+b7UJVwlwj3wwvnstT8w3I16/Ahgr9ELwkMQI6dIlgbsUN62WR9
gP/OGNvex6yXzVmBdRnoQYHKBcixS98KwGBx1l8FJECHA0Ana/Hx4htKhegc
q0F8Q7Reb6qtdN5xnB0hwcsiY4H42OktHQH6Votuj6Bh9ze4qKNeB41dDNlG
ERj8rDqyRj7y1shZzW712gB008Si1B2cN7euGu17SGcDvh1PZUSvTGZDbXcT
WVsCujc25m0Rs4WQilRHmCwwbVLgSzNMoCEOT2QqMQQSZUPDKbLmcYu0bVzG
49nBbI7jMK0fPt7fR1o/75WB74rw57eI09Q1UIKt9ApsgVkG71LsQ4nOUEBF
YTBlFlQmClk5cQe37rld9+CJtunMGVlkeV9JTEKZA9P2U9LXuzqJaBg+d6GZ
3YsTgrEUc6Jg02jhlNhUIBiaaRrji5vRK9R0eW7LiNGjCWdflRpVb2t77wYf
RKjEAk5Q2NYHp6AlxRrJAQPCrLkQr53/dKjYQvjUsBxuKlY2aF5Gd4x3mcJ9
q+E1HdkGtslDzfceH6BtigQVv3JeNC4DY6cyshtZjG1O2ze8hFOxhuKUg+4p
TqLx++4zMmi/f/f8rPHcxmYZxMoWj3mHMrJfPHkbeQdJAZfng/FsTI5/awT6
MYwUmfDCZoju7dXhi97nMzPTs94+tHr3fqZm61mziQQ6oRljocNTCtGA3Aor
eJjpRFQj4ABXqb4WfYRZYAt9JlFSplek+rWEAta1cA0khXCQja7Q6MawjNv4
rbLLAgTt1dqwJcPUpe5RcQGDdc5y+sIqcU6FLPyJufFl5TOhq868sG/UUknR
RuvYb1bT5Tgseo3hPu7KY3eXc4I2FS1rAHCA+H//839Nd1LQjVZFEoTzTERJ
soOKZI8iL1uaUDgehhlH/sBpk5GBI/UIdqXeUJigRGCSxSGTgB30wwjrZaJj
QJstUDTFGyI3OvVxLT0srX2Zp8ZgFgVf53fquutupwgaEr0ovsxHlok5Ds9J
ZcUletUBAGhQcMEd5MX3V4wPNmmPJe4f4Hy/NIOx//7guyBq+2EEbzh0lqXI
wPJLdyhrmDSFDUa1Ny7NKPdtexNOECCF0dvgJ4jVaGcH/pah4PpTIfJ3Zzgb
OeIfwt7vIx/c7aCGr2xY0Eec//dd2ndZRf8NbuefBHEHNjygG3/wyIW9YLv5
weH+44PD7x/vuOJhDPj3Pnf8XfZiJeQ3bGraQVVsjGKiGmxtbdshHfUYPlnR
tBIt/cqLwPfGXlE8Yb0tMLoD8JhDoViMTbs6gBN5raFIRe/fA7XAa7hRVuwg
Uryusiwu0erVGgbDqVGWZPOtNS19pTCPAVRDkjz5Y/vFeTH5ycvhfVoNNJjm
vgro4CHuIDJe3u+ksaGJ++lKpmSyosicOfzZhz+P4c8B/DmEPzsIR0B6d7oZ
Wp+llbcUDfuaw7B3UAxFqTHB3NJl5/2DmVlhAO7XIGQrZO6eOuYSsae9jI6u
6ePumwlmSQqyAmaRgZCRfm7opKS60SxF9AuljcF9hzlrD0Xj7F31PRXP22A/
jO2N2f+FymAn5PGWgMdB1Ofzugfq74aVJYChfDdKd3vYoYMkTW7YAD7Y8S50
cMus789edqyV8IICCb6CXmC4YTKBcWk+y5Txt52jE8HeY/2oy5btY8GpLFma
uLGt/59eLVCagjcza3f8ajPMrUcwTA5wjkAFkZABruiuVGA8pHZPfwTD9xAE
ziw2xkx+WxPj0Rwlpyc7iAAaE/juYVC8ZZWThsOxGR0VHNb4ppe6b98MJoI+
grePNqpa/Sf67YGTniZ/nu/eJYiV8Ovzv26jFlVFgMunhGcRrppQkRx1mA24
Aa6CcbPCP97nKcVJnYHKXJdx46p98P7stMtC6jIVFnLnvjt5yZBr4/EPT5+w
2TCkA+e9WatPmlRxEFDr9Yb9X+i4rBXotJXWHM8vMS7WFCDxdSCaxiu91uR9
LLWKV2qRZimHKGE7XFSQWQQTZ8kf7ddQfe6MAZ71te6Nc9nL8laOghO4e/Xr
GIqfqP8uxSlC94RVycj61VDIhmmrvj8HwWXdiYau9cKkFXUY4BftHdRlflTD
ko4O9NPDuf7h6fTp4/hgevD9weOpOkzUdH64p+PF4eO9g/3lrl2V+TfbFVBD
Uqyh/WtL88dZqtButsvVyU3E2znY/n46ZpYasuH6ZKveqM5T7m6zC2z42/VK
58OJyRTisMC4CbNSZZBIR5bjLa+KzOFhVLaVqrvrkFQGWkqdsy86iMhAQg6n
pwgpGh711ssceHhESb6UT/3Veqtre4sCi97ebagqhCHV/aGzz4Hp7ZA+ecSm
M8hbv8kD7PXe7jLvowCfcrSm3blzVKB/Hn1J3pWGc3eRUBLxXD+W73t2/ZBj
DXyAv5sTaBGaJjXHE2hjs9dvZ5tCKGM0j7ofvafdAIE2oHT9GPmI9F4osstl
17A9AY+70sncSEsbnPg79KhBtjDgoJa5xXrgd3sU/UJJJz4LZyB9ZZc7LsiM
6RmnJ3HtDqlru0bctbL/+EcNm8XN9awR/v77DstiUlGi/z30xMFjQHbfm7yA
OY4fzjGJ4dfrasr27qHsGs5nGF1wvt0FV3Fp9Jzyq3ZmCt0cbIXG5Arul/b6
uQ9mUoGgUQtANVKBnT2EWF/gkEFnCTpC0GezkwYeMPv2TJMTL8gvh0ZNGtgS
vkvlsVnM1qbOVRnshnq93n5bnU1N2OyJRTmgASd1tpN3q1UjcXNHPiQs9gNe
iphzSEJtK1Q2lVyWQK/tgUvf/EHujCzHMnvTSEgVpZjNTVqstdB64gIMJdDa
uyRiiwiyaruJhXNnUDPrFvGTsQtHegUz0dU7cFH5CH4jSUDo0sTLEcenpHr8
0cyTFZgWsWRyckc6Wlrk4AIn3sEp8XiOO5eapuIBZDsdP2G4DMrkaQ5H0EZr
HdybOztz8CRuzFdgWJK7V8WfODbO2bjpkNIlSjpuPEO/Cs2O0DDs2PmyLGYs
U3hlC5J0wgVb68eYkWD9KNRZCE6GFsnArjcYrZ7mPrnIg55pfiCPmsUlf41z
/LFIaO4qb67zdi2IJBJioS3rbBMhjv6InOvwotl9AfZnWgOjDsJS+hKuG1y2
nVnN9TgKfh6mW99jZ70L/hdsG2vt4NZ7d83VVxzXsfvD7bZhYJqcpcucHb/x
Ys1XgChLf/v9ENIYC7AA3ntnMKE2BrPQvWG+Oai87icThrJ9YOXBIPB/AZqF
UZP3jpu8HagUyj4M0t8BTYzMT7plkEK5+iYQ23D0C3GLX/SpJ/fIPRoNCAIN
1VU88P1Sy6kovjGlC8jW/mQ6ZYP6VXPX0FrtWQhx0GhfRLdHcsQZxdisWYfm
rBVxXtvTyqnsgZSIMO6SQsGxVbLv1AZIv/Vx3ZjclnBc+i300fSohzHwcg8X
BV1bRI2STInmhXSdZqrMtg1wBgLXbnCGwSK3gZNOLkwP5tSpFhQEpFURVqBr
7xmm5kCjYMsS9Sf9Qzh3AHvHi1q1KK5TnCpEpsDo20JxJd2RU7G40hqYK4V4
uP0Rt38YyXLrOJ4NypuPyLtuvSNTM8D2JQXhb3YVf+u1QPD+sUNQ8ihEbPs4
gF8fZ+cT/98EHDzKPwQ4Fu1vB5DDnntCyL/mbf3vgBx0++OAR43Di9Lfkgw1
nzPWZDF9HSVSD6F8IuHBorKhufldmJcsgZPPOO+1Y2VBM4rTH3S5045ypz89
GW5JUAfEqZRrKrpI0VnW98WJs7LqZnL3kHvJqkB9BhNX4Ky7IjG4UAYA23NU
qwpH6JNY1esgaxbtsNga71fQKyuCHGv3RV3hWfCK44KrIvaAvD+OzjBb1p83
KtAUeRw8Vspk7BnN1qaUWns2Z7Jcs6MAupfiHmRDQphxJ/VFsZYhFzKEy5EX
gMXnaOp2gmd4HCQgXtvU4jpXmJwnunHPSnk2TqOVgGKGI2Xcw43ztkyvVLyN
Wkj95bsNvxgsohNiHQhFtjzigFhIIqBiA5FYZAje14XzOoTeEckzhyZZsPXi
kk1Egme2vsBugzd5bFH4HTAVkUJLXOGhyHNe+uB1hVVJsMRL8zywOMS18u6n
rvRj3R8+I4ZMCMF2AzsVFRy7JjlOTo8Et7A111ZtxKp7sxVszRamFMyI5XA0
BsCnNq5LVRjrgNKYFHCxZjWXUj5Q3Wviw8Al8VzcI1TTNVY25t7JN2Q0a4zq
HTahQ8yeLsnOqa9n6oYLgttVVmqVbEMw9cHUVqEVhFnoWEmW5za61gz0q7So
DazQiPTZmsgE4d1dodVGdD8kLKOVx54WcAuYcABrApDL2LiAmENTT/0tAAJy
bSqfecI0mppPwqJMzwWDI1k0DHdOI1liD8uTCkm7WWQwVqgxTv4aTVnnHPUQ
tugtAvzE26q5EBRnsXDCAYGiz5WAx0JKgC0tzXUQ7zrpvMfs/xWzoko2C2pf
d7ifrYo3eDv3ldFyFlApecGlRMIqkpSUYm9YrDjE56Y4kqQkJnJZSljJsAW/
FCa+oauGyuM0a8f0mpXrsKilsRjiLvTAqrds+En9oqBLhQeBnAHODVdMyi1r
oi8+vJMULTiZw5sbJoqwUgWVCs/Uls38bErmn9aJHCZoV6jKyRp4hvOXdoan
BwdPYAY4QymZ3MYeL8y0wWwrDjo401YkNX1JhSUChDsMEyql4FkUwe2Huf0d
tMF0/f4CX6NbywBEZ7YKAI/j0v7vW+VFSrx1PFLdKbn+MN9JtCH0dZlPXJgp
pjwvuVFS6yfL9bUvV0CienKXEgdkw0mJD4oZz4al3A4XNx3iOFdpppgvIwXV
bqhwNteC9p+CCGrqrRVJiJzGTnM2yPbMluSRifjppgBMxIwa+i6H1L0zK3Q4
BIk66JvImLfa65vWFh7g1DaiAg4crGLqy0ty6TMrdzfiM40boEvr+ecNVZfj
GtNFSoNj/RgqySSXO2ZnsX+LIleA10nGj2nGzTREUGuD7lbrC+1OmmVLW5eL
xSCCEiX1YYnkEF6gSlCRMCPlERw2vyx49NEDZplCWHw0XNrF8SCgseg5ff4F
XpKjlr9w4mvC5dhm9pCvKf4KhSEHzXqt88SLArvwaMHpahTFXkUXt35UxBYI
fXTR3Buv6tyiQJNs/amPUN29MhsVg1q7BxqkqERYQ23EX3Xx1eF6Vj7pFPJq
4L7r75y2eXT87uT0NEgIwBxbjvLJiOUB+upySkXl4T7ASin0wZOxGkfTaPzb
GFh3kl6mlIm6R89+wGdsUcSvhOCLj/iIKvpsNyv8IMSD8dQ+CkJm9OcYy+ju
74VTwSYynV9WK+TgtioL7pDiMgEqx4B4qV7Kvl392V4AwRgnKyxegQwZSytl
uoQhUAy3iXRBEIHli4Zxy9ZaoZGfn/9M1zDWdpYPK3FtnwnHoo2xxVhEfGQF
fIctLTulRlXrQDmeDJPx8CCkmIrImR6PuPJSpeJmHUSbEYXuGjL32nom3Rri
jQQPEgJJNFq4nNrEVQiFgZ4JGB6YhwRuqoOiqagKC6ru/kA7gYNZ+/MY3cNg
Yc4Pl/iJGEWZ5/iYKJtVMqGrRiuOR1tGGGVrrayuxGQRw3Wxs7ScQN2e+NLT
kP1ghg01CCdITVBwzxVpK0pfuU9lvoJlnJawKRtt1qzoh3mddqjWABwWbAL9
3aDC+P7sVAArUogtollqoGBgPTDGJmWWTmt2R+OLItqICuFQ9rJ1XPjE1glt
cSk0E9m6AYOlOEajf48CphW4wfyLgHx98FFgpnfK5gU6y6jSzwx6dwj3iKgQ
3vRh6lHI+lzMigXHrFH/4PZdXBANXXzFHprZ/N9oG3dJAe2ejLXUfsWuej9C
8K12N5So192RJBF+3YYaOZnfai+7M6+6O2rEEX7dvhpJhd9oW7ckmHT3hdkx
X7MdFB6DmYI2lB72rfa3Kx1laIvo8P+qLdYyWWknC3eJuS/fapeD4Z49XF3M
qHffIN1atvyhteA5bcbrH312KpfIElgwvw0Qor/WKcdb4pysWMGpox7Dtbkb
V6Km91JQqtk2YmO9tsWLRRcKxSUW25z4IyGODVVJKhlSfRRdoiiU8ofXAGZw
SVOBmL7JSaZDlBJ7nVW5qAJbjHX9OTtJDNOuZCIj4BJLYZDxY01hACojZ5Ax
LOQtwx6z6JR/t5ewknDUfAlamRQCx1oqJkjeZ48RlpQj9YxNWe77Zk52CUAk
4rer8EgGWtotaHZisV0bnaFa63x2ZNm8UpmNvPRFg+0meivpht/0kM9ygE4k
+jEK54EJfZVertA0bKshUqU7Al5cZ6qUgkc/irXaI8aKKyXSfDJUUB0S15mD
rKjZ4pfUKKBN3STWQDyABFK3cAlgxMDURmFOH7aIgEdzR7Z1ALdVaWyH1KvE
jJaUjQLAXBeV5tILPQ4tDsah2ku0yEkvmsgiEcx8TJpogLExtagWzk3tqWxn
uqgrcVzky9qQXQK1rTVXlqNig9u8yLdsUkU/4WdRb22SQjTq/ZRoQ2+/g1Vt
wI6Gi3dxUkFk94AdzZ68y6noXVtQBPQXGmLnDrZ/f/Bd60uqD7vFQ4N67C2b
jNUG8ArgQHu5AcQr5h738n9PVTu5ddPK1mLZ3XSAXuYNp0AhPaPRcYzOnkwn
XKPSdKysaGVheUgnfx7nxfimYSNiDKNy1aTgqvwTHYctwWONC2gCaH9kuWEL
aH17EcOFpa84h95xPtk7NORl7Hru+1jzRGKNcXBvjKcY6zK9TFFdBF6fWr7W
gMsH6wMmDd9uSnkQRceqBKC/hZXEn9IJnGMOA7xN808KSPZFjfQSnSETKifR
K+xPHzflKHe+xJtwaYCAlsR3n7MkBocmKPGyuBztPJ4/1iBIX7qO9vaiaXT8
E/z1M0WaJ/z9a3k5p5dHiPbHCX+JKLB64GRYqI6258PWRU2UoHXoeqb50xg+
PpLDNgt6gvh80WyWfKQknY+M8GHzZEpvhBSoGy+MvksolhLrMOotmx6aBvHj
bWgfwPFnbtP7ftPkqKc7ym+v8X3AiHPbKBQOF/N+k7CdlK9ytEz5gR+3oXkh
ZgHZIYLRa/uGYbLJVMxAaW5dIhsw0OdC5NAL2YgdfqDu26UId+F6m59qlROc
RBe02YuJC2+duuMzfl8HnX11uH0QYTNxC5g0QBeco/2OAB6k3xzm9IlSym0H
/LNL//m5lBxdzsHsl3zol2zRjq4p3q9HOPo95cO+kIxV45pJfpFtJxrqhZ/m
STiNnGRtP6MmbCLBwDKM+eeUE/tFDc9Odn+pjUfg5uPedKnwI0UpkT9+GGfW
u3W31SYEPoYQCPCg8DTtj8UHiYpdkC2h9EE4S5o13wIUq3FBY9HIFm9cAk8Y
49DOGJrxrVtymFW7mn0YV2AjPEjmJ6E1CJpA8bzUjfqXLuYgPDfH+iix6M3p
s58ZvHQDAlx7PJzcX3wtAmfxTVklYocny8bAZoX/uPNQKBl9RyL4Zos9i/FH
QiubGE7V+eFx07OAY+IA/JUais8bmKEH5H3hA0mR/8mHVOz021sXORJn55Ix
8uXHCTESS+786SKROOIOwHkMe0u2vs9nNezYfwagq2oz8uM07nPJQg+44RVI
91gkaotYWtqUPi7VCV0wqAF3/yuqY+s6SfhivlYo0i7Z+e4ZxPeeQTxfb0Bb
JIOO88rhhUY4SnFUgTFg4pL+ZGpSAW1IIH5n3lP3eOA0CTPG3azWWaP3hcDn
I0KASZ7vwotZa5amY3pgUidT8+y3ebN9c55NOIy+dgdMNHgZ2isQaMYr0H1u
fCniYvmUu2/QaZa3P20uHDmMYrNfGgG0Y11S5a2Aqjal6NBT4z7mxgf1TFwv
/htvEgRJkkz4pTeKxGt8ny1seZePtNlDE6ZGimmnDgDfKQ75xwwvtzxPZRds
Lr7oM5YJhj/FbxGfTVoCQoJcvtsJ3mdABUCabcPmshOoG/LmMWUzyTIlChs5
G72Wg1yphOtXrOHK8h+dmAINxiSAz6IHCA6AXQ8rfwjTvUpNDHqMyjXWP9Uk
ZqfkpfqsjdvwD56k79RhjhL42xcBdFh4RJbgesCefYe577B7BnhPyoGIUBYn
MkWHfit4AxUyoc9cAzuvVSaaDOY02RXt+xWdgZRWSFQ51kySkbk8iDJOYYH5
p/O537PFc6xGdmrrJ8Dr145KVUIFjzGvGz+/4Qr2NfBt/tgvpQk+iVVKOKDs
+Jlsw3U88B1/Tj9bu4Th2JudPQ+bPfs6tXo88T1E+YudPSCqRSaH0yLLgO0E
d4WfBbkgbioINJepTp+/+6vM5w/oaauvrPGW3v8fTJomlhqKAAA=
-->
</rfc>