rfc9493xml2.original.xml   rfc9493.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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 [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-secevent-subject-identifiers-18" cate <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
gory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> -ietf-secevent-subject-identifiers-18" number="9493" submissionType="IETF" categ
<front> ory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" upda
<title abbrev="secevent-subject-identifiers">Subject Identifiers for Securit tes="" obsoletes="" xml:lang="en" version="3">
y Event Tokens</title>
<front>
<title 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="e ditor"> <author initials="A." surname="Backman" fullname="Annabelle Backman" role="e ditor">
<organization>Amazon</organization> <organization>Amazon</organization>
<address> <address>
<email>richanna@amazon.com</email> <email>richanna@amazon.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Scurtescu" fullname="Marius Scurtescu"> <author initials="M." surname="Scurtescu" fullname="Marius Scurtescu">
<organization>Coinbase</organization> <organization>Coinbase</organization>
<address> <address>
<email>marius.scurtescu@coinbase.com</email> <email>marius.scurtescu@coinbase.com</email>
</address> </address>
</author> </author>
<author initials="P." surname="Jain" fullname="Prachi Jain"> <author initials="P." surname="Jain" fullname="Prachi Jain">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>prachi.jain1288@gmail.com</email> <email>prachi.jain1288@gmail.com</email>
</address> </address>
</author> </author>
<date year="2023" month="December"/>
<date year="2023" month="June" day="24"/>
<area>Security</area> <area>Security</area>
<workgroup>Security Events Working Group</workgroup> <workgroup>Security Events</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Security events communicated within Security Event Tokens may support a varie ty of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that des cribe a subject, and named formats that define the syntax and semantics for enco ding subject identifiers as JSON objects. It also defines a registry for defini ng and allocating names for such formats, as well as the "sub_id" JSON Web Token (JWT) claim.</t> <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 as
structured information that describes a subject and named formats that
define the syntax and semantics for encoding Subject Identifiers as JSON
objects. It also establishes a registry for defining and allocating
names for such formats as well as the JSON Web Token (JWT) "sub_id"
Claim.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro">
<name>Introduction</name>
<t>As described in <xref 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,
a phone 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 and "sub" 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, if some accounts only
have email addresses associated with them while others only have phone
numbers. 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 information (e.g., an email 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>
<section anchor="intro"><name>Introduction</name> <figure anchor="figexampleintro">
<t>As described in Section 1.2 of SET <xref target="RFC8417"/>, subjects related <name>Example: Subject Identifier Using the Email Identifier Format</nam
to security events may take a variety of forms, including but not limited to a e>
JWT <xref target="RFC7519"/> principal, an IP address, a URL, etc. Different ty
pes of subjects may need to be identified in different ways (e.g., a user might
be identified by an email address or a phone number or an account number). Furt
hermore, even in the case where the type of the subject is known, there may be m
ultiple ways by which a given subject may be identified. For example, an accoun
t may be identified by an opaque identifier, an email address, a phone number, a
JWT "iss" claim and "sub" claim, etc., depending on the nature and needs of the
transmitter and receiver. Even within the context of a given transmitter and re
ceiver relationship, it may be appropriate to identify different accounts in dif
ferent ways, for example if some accounts only have email addresses associated w
ith them while others only have phone numbers. 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 - JSO
N <xref target="RFC8259"/> objects containing information identifying a subject
- and Identifier Formats - named sets of rules describing how to encode differen
t kinds of subject identifying information (e.g., an email 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 su
bject by email address, using the Email Identifier Format.</t>
<figure title="Example: Subject Identifier using the Email Identifier Format" an <sourcecode type="json"><![CDATA[{
chor="figexampleintro"><artwork><![CDATA[
{
"format": "email", "format": "email",
"email": "user@example.com" "email": "user@example.com"
} }]]></sourcecode>
]]></artwork></figure> </figure>
<t>Subject Identifiers are intended to be a general-purpose mechanism for identi
fying subjects within JSON 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
"sub_id" claim (defined in this specification) to identify the JWT Subject.</t>
<figure title="Example: JWT using a Subject Identifier with the &quot;sub_id&quo <t>Subject Identifiers are intended to be a general-purpose mechanism for
t; claim" anchor="figexampleintro2"><artwork><![CDATA[ identifying subjects within JSON 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 (defined in this specification) to identify the JWT S
ubject.</t>
<figure anchor="figexampleintro2">
<name>Example: JWT Using a Subject Identifier with the JWT "sub_id" Clai
m</name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub_id": { "sub_id": {
"format": "phone_number", "format": "phone_number",
"phone_number": "+12065550100" "phone_number": "+12065550100"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<t>Usage of Subject Identifiers also need not be limited to identifying JW
<t>Usage of Subject Identifiers also need not be limited to identifying JWT Subj T Subjects. They are intended as a general-purpose means of expressing identify
ects. They are intended as a general-purpose means of expressing identifying in ing information in an unambiguous manner. Below is a non-normative example of a
formation in an unambiguous manner. Below is a non-normative example of a SET c SET containing a hypothetical security event describing the interception of a m
ontaining a hypothetical security event describing the interception of a message essage, using Subject Identifiers to identify the sender, intended recipient, an
, using Subject Identifiers to identify the sender, intended recipient, and inte d interceptor.</t>
rceptor.</t> <figure anchor="figexampleintro3">
<name>Example: SET with an Event Payload Containing Multiple Subject Ide
<figure title="Example: SET with an event payload containing multiple Subject Id ntifiers</name>
entifiers" anchor="figexampleintro3"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"iat": 1508184845, "iat": 1508184845,
"aud": "aud.example.com", "aud": "aud.example.com",
"events": { "events": {
"https://secevent.example.com/events/message-interception": { "https://secevent.example.com/events/message-interception": {
"from": { "from": {
"format": "email", "format": "email",
"email": "alice@example.com" "email": "alice@example.com"
}, },
"to": { "to": {
"format": "email", "format": "email",
"email": "bob@example.com" "email": "bob@example.com"
}, },
"interceptor": { "interceptor": {
"format": "email", "format": "email",
"email": "eve@example.com" "email": "eve@example.com"
} }
} }
} }
} }]]></sourcecode>
</figure>
]]></artwork></figure> </section>
<section anchor="conv">
</section> <name>Notational Conventions</name>
<section anchor="conv"><name>Notational Conventions</name> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/><x NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
ref target="RFC8417"/>.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
<section anchor="defn"><name>Definitions</name> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<t>This specification utilizes terminology defined in <xref target="RFC8259"/> a <xref target="RFC8174"/> when, and only when, they appear in all capitals,
nd <xref target="RFC8417"/>.</t> as shown here.
</t>
<t>Within this specification, the terms "Subject" and "subject" refer genericall
y 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 tha
t the JWT asserts claims about).</t>
</section>
</section>
<section anchor="sub-ids"><name>Subject Identifiers</name>
<t>A Subject Identifier is a JSON <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 subje
ct, and the rules for encoding that information as a Subject Identifier; they de
fine the syntax and semantics of Subject Identifiers. A Subject Identifier MUST
conform to a specific Identifier Format, and MUST contain a "format" member who
se value is the name of that Identifier Format.</t>
<t>Every Identifier Format MUST have a unique name registered in the IANA "Secur
ity Event Identifier Formats" registry established by <xref target="iana-formats
"/>, or a Collision-Resistant Name as defined in <xref target="RFC7519"/>. Iden
tifier Formats that are expected to be used broadly by a variety of parties SHOU
LD be registered in the "Security Event Identifier Formats" registry.</t>
<t>An Identifier Format MAY describe more members than are strictly necessary to
identify a subject, and MAY describe conditions under which those members are r
equired, optional, or prohibited. The "format" member is reserved for use as de
scribed in this specification; Identifier Formats MUST NOT declare any rules reg
arding the "format" member.</t>
<t>Every member within a Subject Identifier MUST match the rules specified for t
hat member by this specification or by Subject Identifier's Identifier Format.
A Subject Identifier MUST NOT contain any members prohibited or not described by
its Identifier Format, and MUST contain all members required by its Identifier
Format.</t>
<section anchor="identifier-formats-versus-principal-types"><name>Identifier For
mats 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" Identifier Format declares that the valu
e of the "email" member is an email address, a subject in a Security Event that
is identified by an "email" Subject Identifier could be an end user who controls
that email address, the mailbox itself, or anything else that the transmitter a
nd receiver both understand to be associated with that email address. Consequen
tly Subject Identifiers remove ambiguity around how a subject is being identifie
d, and how to parse an identifying structure, but do not remove ambiguity around
how to resolve that identifier to a subject. For example, consider a directory
management API that allows callers to identify users and groups through both op
aque unique identifiers and email addresses. Such an API could use Subject Iden
tifiers to disambiguate between which of these two types of identifiers is in us
e. However, the API would have to determine whether the subject is a user or gr
oup via some other means, such as by querying a database, interpreting other par
ameters in the request, or inferring the type from the API contract.</t>
</section>
<section anchor="identifier-format-definitions"><name>Identifier Format Definiti
ons</name>
<t>The following Identifier Formats are registered in the IANA "Security Event I
dentifier Formats" registry established by <xref target="iana-formats"/>.</t>
<t>Since the subject identifier format conveys semantic information, application
s SHOULD choose the most specific possible format for the identifier in question
. For example, an email address can be conveyed using a <spanx style="verb">mail
to:</spanx> URI and the <spanx style="verb">uri</spanx> identifier format, but s
ince the value is known to be an email address, the application should prefer to
use the "email" identifier format instead.</t>
<section anchor="sub-id-acct"><name>Account Identifier Format</name>
<t>The Account Identifier Format identifies a subject using an account at a serv
ice 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 t
o a service and gets a unique identity with the service provider. Subject Identi
fiers in this format MUST contain a "uri" member whose value is the "acct" URI f
or the subject. The "uri" member is REQUIRED and MUST NOT be null or empty. Th
e 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 Identifie
r Format:</t>
<figure title="Example: Subject Identifier for the Account Identifier Format" an <section anchor="defn">
chor="figexamplesubidaccount"><artwork><![CDATA[ <name>Definitions</name>
{ <t>This specification utilizes terminology defined in <xref target="RFC8
259"/> and <xref target="RFC8417"/>.</t>
<t>Within this specification, the terms "Subject" and "subject" refer ge
nerically to anything being identified via one or more pieces of information. T
he term "JWT Subject" refers specifically to the subject of a JWT (i.e., the sub
ject that the JWT asserts claims about).</t>
</section>
</section>
<section anchor="sub-ids">
<name>Subject Identifiers</name>
<t>A Subject Identifier is a JSON object <xref target="RFC8259"/> 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 and the rules for encoding that
information as a Subject Identifier; these rules define the syntax and
semantics of Subject Identifiers. A Subject Identifier
<bcp14>MUST</bcp14> conform to a specific Identifier Format and
<bcp14>MUST</bcp14> contain a "format" member whose value is the name of
that Identifier Format.</t>
<t>Every Identifier Format <bcp14>MUST</bcp14> have a unique name
registered in the IANA "Security Event Identifier Formats" registry
established in <xref 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
<bcp14>SHOULD</bcp14> be registered in the "Security Event Identifier
Formats" registry.</t>
<t>An Identifier Format <bcp14>MAY</bcp14> describe more members than
are strictly necessary to identify a subject and <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 <bcp14>MUST NOT</bcp14> declare
any rules regarding the "format" member.</t>
<t>Every member within a Subject Identifier <bcp14>MUST</bcp14> match
the rules specified for that member by this specification or by a Subject
Identifier's Identifier Format. A Subject Identifier <bcp14>MUST
NOT</bcp14> contain any members prohibited or not described by its
Identifier Format and <bcp14>MUST</bcp14> contain all members required
by its Identifier Format.</t>
<section 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
Identifier Format declares that the value of the "email" member is an
email address, a subject in a security event that is identified by an
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, Subject Identifiers remove ambiguity
around how a subject is being identified and how to parse an
identifying structure, but they do not remove ambiguity
around how to resolve that identifier 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 Format Definitions</name>
<t>The following Identifier Formats are registered in the IANA
"Security Event Identifier Formats" registry established in <xref
target="iana-formats"/>.</t>
<t>Since the Subject Identifier Format conveys semantic information,
applications <bcp14>SHOULD</bcp14> choose the most specific possible
format for the identifier in question. For example, an email address
can be conveyed using a "mailto:" URI and the URI Identifier
Format, but since the value is known to be an email address, the
application should prefer to use the Email Identifier Format
instead.</t>
<section 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 get
s access to a service and gets a unique identity with the service provider. Subj
ect Identifiers in this format <bcp14>MUST</bcp14> contain a "uri" member whose
value is the "acct" URI for the subject. The "uri" member is <bcp14>REQUIRED</b
cp14> and <bcp14>MUST NOT</bcp14> be null or empty. The Account Identifier Form
at 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 anchor="figexamplesubidaccount">
<name>Example: Subject Identifier for the Account Identifier Format<
/name>
<sourcecode type="json"><![CDATA[{
"format": "account", "format": "account",
"uri": "acct:example.user@service.example.com" "uri": "acct:example.user@service.example.com"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-email">
<section anchor="sub-id-email"><name>Email Identifier Format</name> <name>Email Identifier Format</name>
<t>The Email Identifier Format identifies a subject using an email address. Sub <t>The Email Identifier Format identifies a subject using an email add
ject Identifiers in this format MUST contain an "email" member whose value is a ress. Subject Identifiers in this format <bcp14>MUST</bcp14> contain an "email"
string containing the email address of the subject, formatted as an "addr-spec" member whose value is a string containing the email address of the subject, for
as defined in Section 3.4.1 of <xref target="RFC5322"/>. The "email" member is R matted as an "addr-spec" as defined in <xref target="RFC5322" sectionFormat="of"
EQUIRED and MUST NOT be null or empty. The value of the "email" member MUST iden section="3.4.1"/>. The "email" member is <bcp14>REQUIRED</bcp14> and <bcp14>MUS
tify a mailbox to which email may be delivered, in accordance with <xref target= T NOT</bcp14> be null or empty. The value of the "email" member <bcp14>MUST</bcp
"RFC5321"/>. The Email Identifier Format is identified by the name "email".</t> 14> identify a mailbox to which email may be delivered, in accordance with <xref
target="RFC5321"/>. The Email Identifier Format is identified by the name "emai
<t>Below is a non-normative example Subject Identifier in the Email Identifier F l".</t>
ormat:</t> <t>Below is a non-normative example Subject Identifier in the Email Id
entifier Format:</t>
<figure title="Example: Subject Identifier in the Email Identifier Format" ancho <figure anchor="figexamplesubidemail">
r="figexamplesubidemail"><artwork><![CDATA[ <name>Example: Subject Identifier in the Email Identifier Format</na
{ me>
<sourcecode type="json"><![CDATA[{
"format": "email", "format": "email",
"email": "user@example.com" "email": "user@example.com"
} }]]></sourcecode>
]]></artwork></figure> </figure>
<section anchor="email-canon">
<section anchor="email-canon"><name>Email Canonicalization</name> <name>Email Canonicalization</name>
<t>Many email providers will treat multiple email addresses as equivalent. While <t>Many email providers will treat multiple email addresses as
the domain portion of an <xref target="RFC5322"/> email address is consistently equivalent. While the domain portion of an email address <xref
treated as case-insensitive per <xref target="RFC1034"/>, most providers treat target="RFC5322"/> is consistently treated as case-insensitive per
the local part of the email address as case-insensitive as well, and consider "u <xref target="RFC1034"/>, most providers treat the local part of
ser@example.com", "User@example.com", and "USER@example.com" as the same email a the email address as case-insensitive as well and consider
ddress. Some providers also treat dots (".") as optional; for example, "user.nam "user@example.com", "User@example.com", and "USER@example.com" as
e@example.com", "username@example.com", "u.s.e.r.name@example.com", and "u.s.e.r the same email address. Some providers also treat dots (".") as
.n.a.m.e@example.com" might all be treated as equivalent. This has led users to optional; for example, "user.name@example.com",
view these strings as equivalent, driving service providers to implement proprie "username@example.com", "u.s.e.r.name@example.com", and
tary email canonicalization algorithms to ensure that email addresses entered by "u.s.e.r.n.a.m.e@example.com" might all be treated as
users resolve to the same canonical string. Email canonicalization is not stand equivalent. This has led users to view these strings as
ardized, and there is no way for the event recipient to determine the mail provi equivalent, driving service providers to implement proprietary
der’s canonicalization method. Therefore, the recipient SHOULD apply its own can email canonicalization algorithms to ensure that email addresses
onicalization algorithm to incoming events that reproduces the translation done entered by users resolve to the same canonical string. Email
by the local email system.</t> canonicalization is not standardized, and there is no way for the
event recipient to determine the mail provider's canonicalization
</section> method. Therefore, the recipient <bcp14>SHOULD</bcp14> apply its
</section> own canonicalization algorithm to incoming events in order to
<section anchor="sub-id-iss-sub"><name>Issuer and Subject Identifier Format</nam reproduce the translation done by the local email system.</t>
e> </section>
<t>The Issuer and Subject Identifier Format identifies a subject using a pair of </section>
"iss" and "sub" members, analogous to how subjects are identified using the "is <section anchor="sub-id-iss-sub">
s" and "sub" claims in <xref target="OpenID.Core">OpenID Connect</xref> ID Token <name>Issuer and Subject Identifier Format</name>
s. These members MUST follow the formats of the "iss" member and "sub" member d <t>The Issuer and Subject Identifier Format identifies a subject
efined by <xref target="RFC7519"/>, respectively. Both the "iss" member and the using a pair of "iss" and "sub" members, analogous to how subjects
"sub" member are REQUIRED and MUST NOT be null or empty. The Issuer and Subject are identified using the JWT "iss" and "sub" Claims in <xref
Identifier Format is identified by the name "iss_sub".</t> target="OpenID.Core">OpenID Connect</xref> ID Tokens. These members
<bcp14>MUST</bcp14> follow the formats of the "iss" member and "sub"
<t>Below is a non-normative example Subject Identifier in the Issuer and Subject member defined by <xref target="RFC7519"/>, respectively. Both the
Identifier Format:</t> "iss" member and the "sub" member are <bcp14>REQUIRED</bcp14> and
<bcp14>MUST NOT</bcp14> be null or empty. The Issuer and Subject
<figure title="Example: Subject Identifier in the Issuer and Subject Identifier Identifier Format is identified by the name "iss_sub".</t>
Format" anchor="figexamplesubidisssub"><artwork><![CDATA[ <t>Below is a non-normative example Subject Identifier in the Issuer
{ and Subject Identifier Format:</t>
<figure anchor="figexamplesubidisssub">
<name>Example: Subject Identifier in the Issuer and Subject Identifi
er Format</name>
<sourcecode type="json"><![CDATA[{
"format": "iss_sub", "format": "iss_sub",
"iss": "https://issuer.example.com/", "iss": "https://issuer.example.com/",
"sub": "145234573" "sub": "145234573"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-opaque">
<section anchor="sub-id-opaque"><name>Opaque Identifier Format</name> <name>Opaque Identifier Format</name>
<t>The Opaque Identifier Format describes a subject that is identified with a st <t>The Opaque Identifier Format describes a subject that is identified
ring with no semantics asserted beyond its usage as an identifier for the subjec with a string with no semantics asserted beyond its usage as an identifier for
t, such as a UUID or hash used as a surrogate identifier for a record in a datab the subject, such as a Universally Unique Identifier (UUID) or hash used as a su
ase. Subject Identifiers in this format MUST contain an "id" member whose value rrogate identifier for a record in a database. Subject Identifiers in this form
is a JSON string containing the opaque string identifier for the subject. The at <bcp14>MUST</bcp14> contain an "id" member whose value is a JSON string conta
"id" member is REQUIRED and MUST NOT be null or empty. The Opaque Identifier Fo ining the opaque string identifier for the subject. The "id" member is <bcp14>R
rmat is identified by the name "opaque".</t> EQUIRED</bcp14> and <bcp14>MUST NOT</bcp14> be null or empty. The Opaque Identi
fier Format is identified by the name "opaque".</t>
<t>Below is a non-normative example Subject Identifier in the Opaque Identifier <t>Below is a non-normative example Subject Identifier in the Opaque I
Format:</t> dentifier Format:</t>
<figure anchor="figexamplesubidopaque">
<figure title="Example: Subject Identifier in the Opaque Identifier Format" anch <name>Example: Subject Identifier in the Opaque Identifier Format</n
or="figexamplesubidopaque"><artwork><![CDATA[ ame>
{ <sourcecode type="json"><![CDATA[{
"format": "opaque", "format": "opaque",
"id": "11112222333344445555" "id": "11112222333344445555"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-phone">
<section anchor="sub-id-phone"><name>Phone Number Identifier Format</name> <name>Phone Number Identifier Format</name>
<t>The Phone Number Identifier Format identifies a subject using a telephone num <t>The Phone Number Identifier Format identifies a subject using a tel
ber. Subject Identifiers in this format MUST contain a "phone_number" member wh ephone number. Subject Identifiers in this format <bcp14>MUST</bcp14> contain a
ose value is a string containing the full telephone number of the subject, inclu "phone_number" member whose value is a string containing the full telephone num
ding international dialing prefix, formatted according to <xref target="E164">E. ber of the subject, including an international dialing prefix, formatted accordi
164</xref>. The "phone_number" member is REQUIRED and MUST NOT be null or empty. ng to <xref target="E164">E.164</xref>. The "phone_number" member is <bcp14>REQU
The Phone Number Identifier Format is identified by the name "phone_number".</t IRED</bcp14> and <bcp14>MUST NOT</bcp14> be null or empty. The Phone Number Iden
> tifier Format is identified by the name "phone_number".</t>
<t>Below is a non-normative example Subject Identifier in the Phone Nu
<t>Below is a non-normative example Subject Identifier in the Email Identifier F mber Identifier Format:</t>
ormat:</t> <figure anchor="figexamplesubidphone">
<name>Example: Subject Identifier in the Phone Number Identifier For
<figure title="Example: Subject Identifier in the Phone Number Identifier Format mat</name>
" anchor="figexamplesubidphone"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"format": "phone_number", "format": "phone_number",
"phone_number": "+12065550100" "phone_number": "+12065550100"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-did">
<section anchor="sub-id-did"><name>Decentralized Identifier (DID) Format</name> <name>Decentralized Identifier (DID) Format</name>
<t>The Decentralized Identifier (DID) Format identifies a subject
<t>The Decentralized Identifier Format identifies a subject using a Decentralize using a DID URL as defined in <xref target="DID"/>. Subject
d Identifier (DID) URL as defined in <xref target="DID"/>. Subject Identifiers Identifiers in this format <bcp14>MUST</bcp14> contain a "url"
in this format MUST contain a "URL" member whose value is a DID URL for the DID member whose value is a DID URL for the DID Subject being
Subject being identified. The value of the "url" member MUST be a valid DID URL identified. The value of the "url" member <bcp14>MUST</bcp14> be a
and MAY be a bare DID. The "url" member is REQUIRED and MUST NOT be null or empt valid DID URL and <bcp14>MAY</bcp14> be a bare DID. The "url" member
y. The Decentralized Identifier Format is identified by the name "did".</t> is <bcp14>REQUIRED</bcp14> and <bcp14>MUST NOT</bcp14> be null or
empty. The Decentralized Identifier Format is identified by the name
<t>Below are non-normative example Subject Identifiers for the Decentralized Ide "did".</t>
ntifier Format:</t> <t>Below are non-normative example Subject Identifiers for the Decentr
alized Identifier Format:</t>
<figure title="Example: Subject Identifier for the Decentralized Identifier Form <figure anchor="figexamplesubiddidbare">
at, identifying a subject with a bare DID" anchor="figexamplesubiddidbare"><artw <name>Example: Subject Identifier for the Decentralized Identifier F
ork><![CDATA[ ormat, Identifying a Subject with a Bare DID</name>
{ <sourcecode type="json"><![CDATA[{
"format": "did", "format": "did",
"url": "did:example:123456" "url": "did:example:123456"
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplesubiddidcomplex">
<figure title="Example: Subject Identifier for the Decentralized Identifier Form <name>Example: Subject Identifier for the Decentralized Identifier F
at, identifying a subject with a DID URL with non-empty path and query component ormat, Identifying a Subject with a DID URL with Non-empty Path and Query Compon
s" anchor="figexamplesubiddidcomplex"><artwork><![CDATA[ ents</name>
{ <sourcecode type="json"><![CDATA[{
"format": "did", "format": "did",
"url": "did:example:123456/did/url/path?versionId=1" "url": "did:example:123456/did/url/path?versionId=1"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-uri">
<section anchor="sub-id-uri"><name>Uniform Resource Identifier (URI) Format</nam <name>Uniform Resource Identifier (URI) Format</name>
e> <t>The Uniform Resource Identifier (URI) Format identifies a subject u
sing a URI as defined in <xref target="RFC3986"/>. This Identifier Format makes
<t>The Uniform Resource Identifier (URI) Format identifies a subject using a URI no assumptions or guarantees with regard to the content, scheme, or reachability
as defined in <xref target="RFC3986"/>. This identifier format makes no assumpt of the URI within the field. Subject Identifiers in this format <bcp14>MUST</bc
ions or guarantees with regard to the content, scheme, or reachability of the UR p14> contain a "uri" member whose value is a URI for the subject being identifie
I within the field. Subject Identifiers in this format MUST contain a "uri" memb d. The "uri" member is <bcp14>REQUIRED</bcp14> and <bcp14>MUST NOT</bcp14> be nu
er whose value is a URI for the subject being identified. The "uri" member is RE ll or empty. The URI Format is identified by the name "uri".</t>
QUIRED and MUST NOT be null or empty. The URI format is identified by the name " <t>Below are non-normative example Subject Identifiers for the URI For
uri".</t> mat:</t>
<figure anchor="figexamplesubiduidbare">
<t>Below are non-normative example Subject Identifiers for the URI format:</t> <name>Example: Subject Identifier for the URI Format, Identifying a
Subject with a Website URI</name>
<figure title="Example: Subject Identifier for the URI Format, identifying a sub <sourcecode type="json"><![CDATA[{
ject with a website URI" anchor="figexamplesubiduidbare"><artwork><![CDATA[
{
"format": "uri", "format": "uri",
"uri": "https://user.example.com/" "uri": "https://user.example.com/"
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplesubidurnbare">
<figure title="Example: Subject Identifier for the URI Format, identifying a sub <name>Example: Subject Identifier for the URI Format, Identifying a
ject with a random URN" anchor="figexamplesubidurnbare"><artwork><![CDATA[ Subject with a Random URN</name>
{ <sourcecode type="json"><![CDATA[{
"format": "uri", "format": "uri",
"uri": "urn:uuid:4e851e98-83c4-4743-a5da-150ecb53042f" "uri": "urn:uuid:4e851e98-83c4-4743-a5da-150ecb53042f"
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="sub-id-aliases">
<section anchor="sub-id-aliases"><name>Aliases Identifier Format</name> <name>Aliases Identifier Format</name>
<t>The Aliases Identifier Format describes a subject that is identified with a l <t>The Aliases Identifier Format describes a subject that is
ist of different Subject Identifiers. It is intended for use when a variety of i identified with a list of different Subject Identifiers. It is
dentifiers have been shared with the party that will be interpreting the Subject intended for use when a variety of identifiers have been shared with
Identifier, and it is unknown which of those identifiers they will recognize or the party that will be interpreting the Subject Identifier, and it
support. Subject Identifiers in this format MUST contain an "identifiers" memb is unknown which of those identifiers they will recognize or
er whose value is a JSON array containing one or more Subject Identifiers. Each support. Subject Identifiers in this format <bcp14>MUST</bcp14>
Subject Identifier in the array MUST identify the same entity. The "identifier contain an "identifiers" member whose value is a JSON array
s" member is REQUIRED and MUST NOT be null or empty. It MAY contain multiple in containing one or more Subject Identifiers. Each Subject Identifier
stances of the same Identifier Format (e.g., multiple Email Subject Identifiers) in the array <bcp14>MUST</bcp14> identify the same entity. The
, but SHOULD NOT contain exact duplicates. This format is identified by the nam "identifiers" member is <bcp14>REQUIRED</bcp14> and <bcp14>MUST
e "aliases".</t> NOT</bcp14> be null or empty. It <bcp14>MAY</bcp14> contain
multiple instances of the same Identifier Format (e.g., multiple
<t>"aliases" Subject Identifiers MUST NOT be nested; i.e., the "identifiers" mem Email Subject Identifiers) but <bcp14>SHOULD NOT</bcp14> contain
ber of an "aliases" Subject Identifier MUST NOT contain a Subject Identifier in exact duplicates. This format is identified by the name
the "aliases" format.</t> "aliases".</t>
<t>"aliases" Subject Identifiers <bcp14>MUST NOT</bcp14> be nested,
<t>Below is a non-normative example Subject Identifier in the Aliases Identifier i.e., the "identifiers" member of an "aliases" Subject Identifier
Format:</t> <bcp14>MUST NOT</bcp14> contain a Subject Identifier in the Aliases
Identifier Format.</t>
<figure title="Example: Subject Identifier in the Aliases Identifier Format" anc <t>Below is a non-normative example Subject Identifier in the
hor="figexamplesubididtoken"><artwork><![CDATA[ Aliases Identifier Format:</t>
{ <figure anchor="figexamplesubididtoken">
<name>Example: Subject Identifier in the Aliases Identifier Format</
name>
<sourcecode type="json"><![CDATA[{
"format": "aliases", "format": "aliases",
"identifiers": [ "identifiers": [
{ {
"format": "email", "format": "email",
"email": "user@example.com" "email": "user@example.com"
}, },
{ {
"format": "phone_number", "format": "phone_number",
"phone_number": "+12065550100" "phone_number": "+12065550100"
}, },
{ {
"format": "email", "format": "email",
"email": "user+qualifier@example.com" "email": "user+qualifier@example.com"
} }
] ]
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> </section>
</section> </section>
</section> <section anchor="jwt-claims">
<section anchor="jwt-claims"><name>Subject Identifiers in JWTs</name> <name>Subject Identifiers in JWTs</name>
<section anchor="jwt-claims-sub_id">
<section anchor="jwt-claims-sub_id"><name><spanx style="verb">sub_id</spanx> Cla <name>JWT "sub_id" Claim</name>
im</name> <t>The JWT "sub" Claim is defined in <xref target="RFC7519"
<t>The "sub" JWT Claim is defined in Section 4.1.2 of <xref target="RFC7519"/> a sectionFormat="of" section="4.1.2"/> as containing a string value;
s containing a string value, and therefore cannot contain a Subject Identifier ( therefore, it cannot contain a Subject Identifier (which is a JSON
which is a JSON object) as its value. This document defines the "sub_id" JWT Cl object) as its value. This document defines the JWT "sub_id" Claim,
aim, in accordance with Section 4.2 of <xref target="RFC7519"/>, as a common cla in accordance with <xref target="RFC7519" sectionFormat="of"
im that identifies the JWT Subject using a Subject Identifier. When present, th section="4.2"/>, as a common claim that identifies the JWT Subject
e value of this claim MUST be a Subject Identifier that identifies the subject o using a Subject Identifier. When present, the value of this claim
f the JWT. The "sub_id" claim MAY be included in a JWT, whether or not the "sub <bcp14>MUST</bcp14> be a Subject Identifier that identifies the
" claim is present. When both the "sub" and "sub_id" claims are present in a JW subject of the JWT. The JWT "sub_id" Claim <bcp14>MAY</bcp14> be includ
T, they MUST identify the same subject, as a JWT has one and only one JWT Subjec ed
t.</t> in a JWT, whether or not the JWT "sub" Claim is present. When both the
JWT
<t>When processing a JWT with both "sub" and "sub_id" claims, implementations MU "sub" and "sub_id" Claims are present in a JWT, they
ST NOT rely on both claims to determine the JWT Subject. An implementation MAY <bcp14>MUST</bcp14> identify the same subject, as a JWT has one and
attempt to determine the JWT Subject from one claim and fall back to using the o only one JWT Subject.</t>
ther if it determines it does not understand the format of the first claim. For <t>When processing a JWT with both JWT "sub" and "sub_id" Claims,
example, an implementation may attempt to use "sub_id", and fall back to using implementations <bcp14>MUST NOT</bcp14> rely on both claims to
"sub" upon finding that "sub_id" contains a Subject Identifier whose format is n determine the JWT Subject. An implementation <bcp14>MAY</bcp14>
ot recognized by the implementation.</t> 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
<t>Below are non-normative examples of JWTs containing the "sub_id" claim:</t> the first claim. For example, an implementation may attempt to use
"sub_id" and fall back to using "sub" upon finding that "sub_id"
<figure title="Example: JWT containing a &quot;sub_id&quot; claim and no &quot;s contains a Subject Identifier with a format that is not recognized by
ub&quot; claim" anchor="figexamplejwtsubidemail"><artwork><![CDATA[ the implementation.</t>
{ <t>Below are non-normative examples of JWTs containing the JWT "sub_id"
Claim:</t>
<figure anchor="figexamplejwtsubidemail">
<name>Example: JWT Containing a JWT "sub_id" Claim and No "sub" Claim<
/name>
<sourcecode type="json"><![CDATA[{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub_id": { "sub_id": {
"format": "email", "format": "email",
"email": "user@example.com" "email": "user@example.com"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplejwtsamesubid">
<figure title="Example: JWT where both the &quot;sub&quot; and &quot;sub_id&quot <name>Example: JWT Where the JWT "sub" and "sub_id" Claims Identify th
; claims identify the JWT Subject using the same identifier" anchor="figexamplej e JWT Subject Using the Same Identifier</name>
wtsamesubid"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "user@example.com", "sub": "user@example.com",
"sub_id": { "sub_id": {
"format": "email", "format": "email",
"email": "user@example.com" "email": "user@example.com"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplejwtdiffsubvalues">
<figure title="Example: JWT where both the &quot;sub&quot; and &quot;sub_id&quot <name>Example: JWT Where the JWT "sub" and "sub_id" Claims Identify th
; claims identify the JWT Subject using different values of the same identifier e JWT Subject Using Different Values of the Same Identifier Type</name>
type" anchor="figexamplejwtdiffsubvalues"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "liz@example.com", "sub": "liz@example.com",
"sub_id": { "sub_id": {
"format": "email", "format": "email",
"email": "elizabeth@example.com" "email": "elizabeth@example.com"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplejwtdiffsubtype">
<figure title="Example: JWT where the &quot;sub&quot; and &quot;sub_id&quot; cla <name>Example: JWT Where the JWT "sub" and "sub_id" Claims Identify th
ims identify the JWT Subject via different types of identifiers" anchor="figexam e JWT Subject via Different Types of Identifiers</name>
plejwtdiffsubtype"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "user@example.com", "sub": "user@example.com",
"sub_id": { "sub_id": {
"format": "account", "format": "account",
"uri": "acct:example.user@service.example.com" "uri": "acct:example.user@service.example.com"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="subid-and-isssub-subject-identifiers">
<section anchor="subid-and-isssub-subject-identifiers"><name><spanx style="verb" <name>JWT "sub_id" Claim and "iss_sub" Subject Identifier</name>
>sub_id</spanx> and <spanx style="verb">iss_sub</spanx> Subject Identifiers</nam <t>The JWT "sub_id" Claim <bcp14>MAY</bcp14> contain an "iss_sub" Subjec
e> t Identifier. In this case, the JWT's "iss" Claim and the Subject Identifier's
<t>The "sub_id" claim MAY contain an "iss_sub" Subject Identifier. In this case "iss" member <bcp14>MAY</bcp14> be different. For example, an <xref target="Open
, the JWT's "iss" claim and the Subject Identifier's "iss" member MAY be differe ID.Core">OpenID Connect</xref> client may construct such a JWT when sending JWTs
nt. For example, in <xref target="OpenID.Core">OpenID Connect</xref> client may back to its OpenID Connect Identity Provider in order to identify the JWT Subje
construct such a JWT when sending JWTs back to its OpenID Connect Identity Prov ct using an identifier known to be understood by both parties. Similarly, the J
ider, in order to identify the JWT Subject using an identifier known to be under WT's "sub" Claim and the Subject Identifier's "sub" member <bcp14>MAY</bcp14> be
stood by both parties. Similarly, the JWT's "sub" claim and the Subject Identif different. For example, this may be used by an OpenID Connect client to commun
ier's "sub" member MAY be different. For example, this may be used by an OpenID icate the JWT Subject's local identifier at the client back to its Identity Prov
Connect client to communicate the JWT Subject's local identifier at the client ider.</t>
back to its Identity Provider.</t> <t>Below are non-normative examples of a JWT where the JWT "iss" Claim a
nd "iss" member within the JWT "sub_id" Claim are the same and a JWT where they
<t>Below are non-normative examples of a JWT where the "iss" claim and "iss" mem are different.</t>
ber within the "sub_id" claim are the same, and a JWT where they are different.< <figure anchor="figexamplejwtsameiss">
/t> <name>Example: JWT with an "iss_sub" Subject Identifier Where the JWT
Issuer and JWT Subject Issuer Are the Same</name>
<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where <sourcecode type="json"><![CDATA[{
JWT issuer and JWT Subject issuer are the same" anchor="figexamplejwtsameiss"><
artwork><![CDATA[
{
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub_id": { "sub_id": {
"format": "iss_sub", "format": "iss_sub",
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "example_user" "sub": "example_user"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplejwtdiffiss">
<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where <name>Example: JWT with an "iss_sub" Subject Identifier Where the JWT
the JWT issuer and JWT Subject issuer are different" anchor="figexamplejwtdiffi Issuer and JWT Subject Issuer Are Different</name>
ss"><artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "client.example.com", "iss": "client.example.com",
"sub_id": { "sub_id": {
"format": "iss_sub", "format": "iss_sub",
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "example_user" "sub": "example_user"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
<figure anchor="figexamplejwtdiffisssub">
<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where <name>Example: JWT with an "iss_sub" Subject Identifier Where the JWT
the JWT &quot;iss&quot; and &quot;sub&quot; claims differ from the JWT Subject' "iss" and "sub" Claims Differ from the JWT Subject's "iss" and "sub" Members</na
s &quot;iss&quot; and &quot;sub&quot; members" anchor="figexamplejwtdiffisssub"> me>
<artwork><![CDATA[ <sourcecode type="json"><![CDATA[{
{
"iss": "client.example.com", "iss": "client.example.com",
"sub": "client_user", "sub": "client_user",
"sub_id": { "sub_id": {
"format": "iss_sub", "format": "iss_sub",
"iss": "issuer.example.com", "iss": "issuer.example.com",
"sub": "example_user" "sub": "example_user"
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> </section>
</section> <section anchor="implementer">
<section anchor="implementer"><name>Considerations for Specifications that Defin <name>Considerations for Specifications that Define Identifier Formats</na
e Identifier Formats</name> me>
<t>Identifier Format definitions MUST NOT make assertions or declarations regard <t>Identifier Format definitions <bcp14>MUST NOT</bcp14> make assertions o
ing the subject being identified by the Subject Identifier (e.g., an Identifier r declarations regarding the subject being identified by the Subject Identifier
Format cannot be defined as specifically identifying human end users), as such s (e.g., an Identifier Format cannot be defined as specifically identifying human
tatements are outside the scope of Identifier Formats and Subject Identifiers, a end users). Such statements are outside the scope of Identifier Formats and Subj
nd expanding that scope for some Identifier Formats but not others would harm in ect Identifiers. Expanding that scope for some Identifier Formats but not others
teroperability, as applications that depend on this expanded scope to disambigua would harm interoperability because applications that depend on this expanded s
te the subject type would be unable to use Identifier Formats that do not provid cope to disambiguate the subject type would be unable to use Identifier Formats
e such rules.</t> that do not provide such rules.</t>
</section>
</section> <section anchor="privacy">
<section anchor="privacy"><name>Privacy Considerations</name> <name>Privacy Considerations</name>
<section anchor="identifier-correlation">
<section anchor="identifier-correlation"><name>Identifier Correlation</name> <name>Identifier Correlation</name>
<t>The act of presenting two or more identifiers for a single subject together ( <t>The act of presenting two or more identifiers for a single subject
e.g., within an "aliases" Subject Identifier, or via the "sub" and "sub_id" JWT together (e.g., within an "aliases" Subject Identifier or via the
claims) may communicate more information about the subject than was intended. F JWT "sub" and "sub_id" Claims) may communicate more information about
or example, the entity to which the identifiers are presented now knows that bot the subject than was intended. For example, the entity to which the
h identifiers relate to the same subject, and may be able to correlate additiona identifiers are presented now knows that both identifiers relate to
l data based on that. When transmitting Subject Identifiers, the transmitter SH the same subject and may be able to correlate additional data based on
OULD take care that they are only transmitting multiple identifiers together whe that. When transmitting Subject Identifiers, the transmitter
n it is known that the recipient already knows that the identifiers are related <bcp14>SHOULD</bcp14> take care that they are only transmitting
(e.g., because they were previously sent to the recipient as claims in an OpenID multiple identifiers together when it is known that the recipient
Connect ID Token), or when correlation is essential to the use case. Implement already knows that the identifiers are related (e.g., because they
ers must consider such risks, and specifications that use subject identifiers mu were previously sent to the recipient as claims in an OpenID Connect
st provide appropriate privacy considerations of their own.</t> ID Token) or when correlation is essential to the use case.
Implementers must consider such risks, and specifications that use
<t>The considerations described in Section 6 of <xref target="RFC8417"/> also ap Subject Identifiers must provide appropriate privacy considerations of
ply when Subject Identifiers are used within SETs. The considerations described their own.</t>
in Section 12 of <xref target="RFC7519"/> also apply when Subject Identifiers a <t>The considerations described in <xref target="RFC8417"
re used within JWTs.</t> sectionFormat="of" section="6"/> also apply when Subject Identifiers
are used within SETs. The considerations described in <xref
</section> target="RFC7519" sectionFormat="of" section="12"/> also apply when
</section> Subject Identifiers are used within JWTs.</t>
<section anchor="security"><name>Security Considerations</name> </section>
<t>This specification does not define any mechanism for ensuring the confidentia </section>
lity or integrity of a Subject Identifier. Where such properties are required, <section anchor="security">
implementations MUST use mechanisms provided by the containing format (e.g., int <name>Security Considerations</name>
egrity protecting SETs or JWTs using JWS <xref target="RFC7515"/>), or at the tr <t>This specification does not define any mechanism for ensuring the
ansport layer or other layer in the application stack (e.g., using TLS <xref tar confidentiality or integrity of a Subject Identifier. Where such
get="RFC8446"/>).</t> properties are required, implementations <bcp14>MUST</bcp14> use
mechanisms provided by the containing format (e.g., integrity protecting
<t>Further considerations regarding confidentiality and integrity of SETs can be SETs or JWTs using JSON Web Signature (JWS) <xref target="RFC7515"/>) or
found in Section 5.1 of <xref target="RFC8417"/>.</t> at the transport layer or other layer in the application stack (e.g.,
using TLS <xref target="RFC8446"/>).</t>
</section> <t>Further considerations regarding confidentiality and integrity of
<section anchor="iana"><name>IANA Considerations</name> SETs can be found in <xref target="RFC8417" sectionFormat="of"
section="5.1"/>.</t>
<section anchor="iana-formats"><name>Security Event Identifier Formats Registry< </section>
/name> <section anchor="iana">
<t>This document defines Identifier Formats, for which IANA is asked to create a <name>IANA Considerations</name>
nd maintain a new registry titled "Security Event Identifier Formats". Initial <section anchor="iana-formats">
values for the Security Event Identifier Formats registry are given in <xref tar <name>Security Event Identifier Formats Registry</name>
get="sub-ids"/>. Future assignments are to be made through the Specification Re <t>This document defines Identifier Formats, for which IANA has created
quired registration policy <xref target="BCP26"/> and shall follow the template and maintains a new registry titled "Security Event Identifier Formats". Initia
presented in <xref target="iana-formats-template"/>.</t> l values for the "Security Event Identifier Formats" registry are given in <xref
target="sub-ids"/>. Future assignments are to be made through the Specificatio
<t>It is suggested that multiple Designated Experts be appointed who are able to n Required registration policy <xref target="BCP26"/> and shall follow the templ
represent the perspectives of different applications using this specification, ate presented in <xref target="iana-formats-template"/>.</t>
in order to enable broadly informed review of registration decisions.</t> <t>It is suggested that multiple designated experts be appointed who are
able to represent the perspectives of different applications using this specifi
<section anchor="registry-location"><name>Registry Location</name> cation in order to enable broadly informed review of registration decisions.</t>
<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 <spa
nx style="verb">https://www.iana.org/assignments/secevent/</spanx>.</t>
</section>
<section anchor="iana-formats-template"><name>Registration Template</name>
<dl newline="true">
<dt>Format Name</dt>
<dd>
<t>The name of the Identifier Format, as described in <xref target="sub-ids"
/>. The name MUST be an ASCII string consisting only of lower-case characters ("
a" - "z"), digits ("0" - "9"), underscores ("_"), and hyphens ("-"), and SHOULD
NOT exceed 20 characters in length.</t>
</dd>
<dt>Format Description</dt>
<dd>
<t>A brief description of the Identifier Format.</t>
</dd>
<dt>Change Controller</dt>
<dd>
<t>For formats defined in documents published by the IETF or its working gro
ups, list "IETF". For all other formats, list the name of the party responsible
for the registration. Contact information such as mailing address, email addre
ss, or phone number must also be provided.</t>
</dd>
<dt>Defining Document(s)</dt>
<dd>
<t>A reference to the document or documents that define the Identifier Forma
t. The reference document(s) MUST specify the name, format,and meaning of each
member that may occur within a Subject Identifier of the defined format, as well
as whether each member is optional, required or conditional, and the circumstan
ces under which these optional or conditional fields would be used. URIs that ca
n be used to retrieve copies of each document SHOULD be included.</t>
</dd>
</dl>
</section>
<section anchor="iana-formats-init"><name>Initial Registry Contents</name>
<section anchor="account-identifier-format"><name>Account Identifier Format</nam
e>
<t><list style="symbols">
<t>Format Name: "account"</t>
<t>Format Description: Subject identifier based on <spanx style="verb">acct</s
panx> URI.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section 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 based on email address.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section 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 based on an issuer and subject.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section anchor="opaque-identifier-format"><name>Opaque Identifier Format</name>
<t><list style="symbols">
<t>Format Name: "opaque"</t>
<t>Format Description: Subject identifier based on an opaque string.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section anchor="phone-number-identifier-format"><name>Phone Number Identifier F
ormat</name>
<t><list style="symbols">
<t>Format Name: "phone_number"</t>
<t>Format Description: Subject identifier based on an phone number.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section anchor="decentralized-identifier-format"><name>Decentralized Identifier
Format</name>
<t><list style="symbols">
<t>Format Name: "did"</t>
<t>Format Description: Subject identifier based on a decentralized identifier
(DID).</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section anchor="uniform-resource-identifier-format"><name>Uniform Resource Iden
tifier Format</name>
<t><list style="symbols">
<t>Format Name: "uri"</t>
<t>Format Description: Subject identifier based on a uniform resource identifi
er (URI).</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
<section anchor="aliases-identifier-format"><name>Aliases Identifier Format</nam
e>
<t><list style="symbols">
<t>Format Name: "aliases"</t>
<t>Format Description: Subject identifier that groups together multiple differ
ent subject identifiers for the same subject.</t>
<t>Change Controller: IETF</t>
<t>Defining Document(s): <xref target="sub-ids"/> of this document.</t>
</list></t>
</section>
</section>
<section anchor="iana-formats-expert"><name>Guidance for Expert Reviewers</name>
<t>The Expert Reviewer is expected to review the documentation referenced in a r
egistration request to verify its completeness. The Expert Reviewer must base th
eir 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 th
emselves from the approval process for that request.</t>
<t>Identifier Formats need not be generally applicable and may be highly specifi
c to a particular domain; it is expected that formats may be registered for nich
e or industry-specific use cases. The Expert Reviewer should focus on whether th
e format is thoroughly 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, or amount to a synony
m for an existing format.</t>
</section>
</section>
<section 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 Claim, which
IANA is asked to register in the "JSON Web Token Claims" registry <xref target=
"IANA.JWT.Claims">IANA JSON Web Token Claims Registry</xref> established by <xre
f target="RFC7519"/>.</t>
<section 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 target="jwt-claims-sub_id"/> of this docum
ent.</t>
</list></t>
</section>
</section>
</section>
<section anchor="iana-formats-template">
<name>Registration Template</name>
<dl newline="true">
<dt>Format Name:</dt>
<dd>
<t>The name of the Identifier Format, as described in <xref
target="sub-ids"/>. The name <bcp14>MUST</bcp14> be an ASCII
string consisting only of lowercase characters ("a" - "z"),
digits ("0" - "9"), underscores ("_"), and hyphens ("-") and
<bcp14>SHOULD NOT</bcp14> exceed 20 characters in length.</t>
</dd>
<dt>Format Description:</dt>
<dd>
<t>A brief description of the Identifier Format.</t>
</dd>
<dt>Change 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, such as mailing address, email address, or phone
number, must also be provided.</t>
</dd>
<dt>Reference:</dt>
<dd>
<t>A reference to the document or documents that define the
Identifier Format. The reference document(s)
<bcp14>MUST</bcp14> specify the name, format, and meaning of each
member that may occur within a Subject Identifier of the defined
format as well as whether each member is optional, required, or
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 <bcp14>SHOULD</bcp14> be
included.</t>
</dd>
</dl>
</section>
<section anchor="iana-formats-init">
<name>Initial Registry Contents</name>
<section anchor="account-identifier-format">
<name>Account Identifier Format</name>
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>account</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on
"acct" URI</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="email-identifier-format">
<name>Email Identifier Format</name>
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>email</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on
an email address</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="issuer-and-subject-identifier-format">
<name>Issuer and Subject Identifier Format</name>
<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</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="opaque-identifier-format">
<name>Opaque Identifier Format</name>
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>opaque</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on an
opaque string</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="phone-number-identifier-format">
<name>Phone Number Identifier Format</name>
<dl spacing="compact" newline="false">
<dt>Format Name:</dt> <dd>phone_number</dd>
<dt>Format Description:</dt> <dd>Subject Identifier based on a
phone number</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="decentralized-identifier-format">
<name>Decentralized Identifier Format</name>
<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)</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="uniform-resource-identifier-format">
<name>Uniform Resource Identifier Format</name>
<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)</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
<section anchor="aliases-identifier-format">
<name>Aliases Identifier Format</name>
<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 for the same
subject</dd>
<dt>Change Controller:</dt> <dd>IETF</dd>
<dt>Reference:</dt> <dd><xref target="sub-ids"/> of
RFC 9493</dd>
</dl>
</section>
</section>
<section anchor="iana-formats-expert">
<name>Guidance for Expert Reviewers</name>
<t>The Expert Reviewer is expected to review the documentation referen
ced in a registration request to verify its completeness. The Expert Reviewer mu
st base their decision to accept or reject the request on a fair and impartial a
ssessment of the request. If the Expert Reviewer has a conflict of interest, suc
h 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 high
ly specific to a particular domain; it is expected that formats may be registere
d for niche or industry-specific use cases. The Expert Reviewer should focus on
whether the format is thoroughly documented and whether its registration will pr
omote or harm interoperability. In most cases, the Expert Reviewer should not a
pprove a request if the registration would contribute to confusion or amount to
a synonym for an existing format.</t>
</section>
</section>
<section anchor="json-web-token-claims-registration">
<name>JSON Web Token Claims Registration</name>
<t>This document defines the JWT "sub_id" Claim, which IANA has register
ed in the "JSON Web Token Claims" registry <xref target="IANA.JWT.Claims"/> esta
blished by <xref target="RFC7519"/>.</t>
<section anchor="registry-contents">
<name>Registry Contents</name>
<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 RFC 9493</dd>
</dl>
</section>
</section>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <references>
<name>References</name>
<reference anchor='BCP26' target='https://www.rfc-editor.org/info/rfc8126'> <references>
<front> <name>Normative References</name>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></aut
hor>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></aut
hor>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s 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 addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is 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>
<reference anchor="E164" target="https://www.itu.int/rec/T-REC-E.164-201011-I/en
">
<front>
<title>The international public telecommunication numbering plan</title>
<author >
<organization>International Telecommunication Union</organization>
</author>
<date year="2010"/>
</front>
</reference>
<reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignments/jwt
">
<front>
<title>JSON Web Token Claims</title>
<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>
</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'><organizat
ion/></author>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho
r>
<author fullname='W. Denniss' initials='W.' surname='Denniss'><organization/></a
uthor>
<author fullname='M. Ansari' initials='M.' surname='Ansari'><organization/></aut
hor>
<date month='July' year='2018'/>
<abstract><t>This specification defines the Security Event Token (SET) data stru
cture. A SET describes statements of fact from the perspective of an issuer abo
ut a subject. These statements of fact represent an event that occurred directl
y 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 t
o enable representing security- and identity-related events. A SET is a JSON We
b Token (JWT), which can be optionally signed and/or encrypted. SETs can be dist
ributed 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/></autho
r>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></a
uthor>
<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 c
laims 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) structu
re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
aims 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'><organizat
ion/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
guage-independent data interchange format. It was derived from the ECMAScript P
rogramming Language Standard. JSON defines a small set of formatting rules for
the portable representation of structured data.</t><t>This document removes inco
nsistencies 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/></a
uthor>
<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 Comm
unity, 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'><organizat
ion/></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>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'><org
anization/></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
&quot;electronic mail&quot; messages. This specification is a revision of Requ
est For Comments (RFC) 2822, which itself superseded Request For Comments (RFC)
822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updatin
g 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>
<author fullname='J. Klensin' initials='J.' surname='Klensin'><organization/></a
uthor>
<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 pre
vious documents, making all or parts of most of them obsolete. It covers the SM
TP extension mechanisms and best practices for the contemporary Internet, but do
es not provide details about particular extensions. Although SMTP was designed
as a mail transport and delivery protocol, this specification also contains info
rmation that is important to its use as a &quot;mail submission&quot; protocol f
or &quot;split-UA&quot; (User Agent) mail reading systems and mobile environment
s. [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>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organizat
ion/></author>
<author fullname='R. Fielding' initials='R.' surname='Fielding'><organization/><
/author>
<author fullname='L. Masinter' initials='L.' surname='Masinter'><organization/><
/author>
<date month='January' year='2005'/>
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of charac
ters that identifies an abstract or physical resource. This specification defin
es 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 u
se 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 possi
ble identifier. This specification does not define a generative grammar for URI
s; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
</references> <referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/bcp26">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
</referencegroup>
<references title='Informative References'> <reference anchor="E164" target="https://www.itu.int/rec/T-REC-E.164-201
011-I/en">
<front>
<title>E.164: The international public telecommunication numbering p
lan</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="November" year="2010"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="E.164"/>
</reference>
<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect- <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignm
core-1_0.html"> ents/jwt">
<front> <front>
<title>OpenID Connect Core 1.0</title> <title>JSON Web Token Claims</title>
<author initials="N." surname="Sakimura" fullname="Nat Sakimura"> <author>
<organization>Nomura Research Institute, Ltd.</organization> <organization>IANA</organization>
</author> </author>
<author initials="J." surname="Bradley" fullname="John Bradley"> </front>
<organization>Ping Identity</organization> </reference>
</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'> <reference anchor="DID" target="https://www.w3.org/TR/did-core/">
<front> <front>
<title>Domain names - concepts and facilities</title> <title>Decentralized Identifiers (DIDs) v1.0</title>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organizat <author fullname="Manu Sporny" role="editor">
ion/></author> <organization>Digital Bazaar</organization>
<date month='November' year='1987'/> </author>
<abstract><t>This RFC is the revised basic definition of The Domain Name System. <author fullname="Amy Guy" role="editor">
It obsoletes RFC-882. This memo describes the domain style names and their us <organization>Digital Bazaar</organization>
ed for host address look up and electronic mail forwarding. It discusses the cl </author>
ients and servers in the domain name system and the protocol used between them.< <author fullname="Markus Sabadello" role="editor">
/t></abstract> <organization>Danube Tech</organization>
</front> </author>
<seriesInfo name='STD' value='13'/> <author fullname="Drummond Reed" role="editor">
<seriesInfo name='RFC' value='1034'/> <organization>Evernym/Avast</organization>
<seriesInfo name='DOI' value='10.17487/RFC1034'/> </author>
</reference> <author fullname="Dave Longley">
<organization>Digital Bazaar</organization>
</author>
<author fullname="Orie Steele">
<organization>Transmute</organization>
</author>
<author fullname="Christopher Allen">
<organization>Blockchain Commons</organization>
</author>
<date month="July" year="2022"/>
</front>
</reference>
<reference anchor='RFC7515' target='https://www.rfc-editor.org/info/rfc7515'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 417.xml"/>
<title>JSON Web Signature (JWS)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho 519.xml"/>
r> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></a 259.xml"/>
uthor> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/>< 119.xml"/>
/author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month='May' year='2015'/> 565.xml"/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital si <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
gnatures or Message Authentication Codes (MACs) using JSON-based data structures 322.xml"/>
. Cryptographic algorithms and identifiers for use with this specification are <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
described in the separate JSON Web Algorithms (JWA) specification and an IANA re 321.xml"/>
gistry defined by that specification. Related encryption capabilities are descr <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ibed in the separate JSON Web Encryption (JWE) specification.</t></abstract> 986.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name='RFC' value='7515'/> 174.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/> </references>
</reference> <references>
<name>Informative References</name>
<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-
<front> connect-core-1_0.html">
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <front>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/>< <title>OpenID Connect Core 1.0 incorporating errata set 1</title>
/author> <author initials="N." surname="Sakimura" fullname="Nat Sakimura">
<date month='August' year='2018'/> <organization>Nomura Research Institute, Ltd.</organization>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security </author>
(TLS) protocol. TLS allows client/server applications to communicate over the <author initials="J." surname="Bradley" fullname="John Bradley">
Internet in a way that is designed to prevent eavesdropping, tampering, and mess <organization>Ping Identity</organization>
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs </author>
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 <author initials="M." surname="Jones" fullname="Michael B. Jones">
implementations.</t></abstract> <organization>Microsoft</organization>
</front> </author>
<seriesInfo name='RFC' value='8446'/> <author initials="B." surname="de Medeiros" fullname="Breno de Medei
<seriesInfo name='DOI' value='10.17487/RFC8446'/> ros">
</reference> <organization>Google</organization>
</author>
<author initials="C." surname="Mortimore" fullname="Chuck Mortimore"
>
<organization>Salesforce</organization>
</author>
<date year="2014" month="November"/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
</references>
</references> </references>
<section numbered="false" anchor="acknowledgements">
<section numbered="no" anchor="acknowledgements"><name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank the members of the IETF Security Events worki <t>The authors would like to thank the members of the IETF Security
ng group, as well as those of the OpenID Shared Signals and Events Working Group Events Working Group, as well as those of the OpenID Shared Signals and
, whose work provided the original basis for this document. Events Working Group, whose work provided the original basis for this
We would also like to acknowledge Aaron Parecki, Denis Pinkas, Justin Richer, Mi document. We would also like to acknowledge <contact fullname="Aaron
ke Jones and other members of the working group for reviewing this document.</t> Parecki"/>, <contact fullname="Denis Pinkas"/>, <contact
fullname="Justin Richer"/>, <contact fullname="Mike Jones"/>, and other
</section> members of the working group for reviewing this document.</t>
<section numbered="no" anchor="change-log"><name>Change Log</name> </section>
<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="v
erb">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, ex
amples.</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">p
hone-number</spanx> and its <spanx style="verb">phone</spanx> claim to <spanx st
yle="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 Identif
ier 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 sty
le="verb">iss_sub</spanx>.</t>
<t>Added normative requirements limiting the use of both <spanx style="verb">s
ub</spanx> and <spanx style="verb">sub_id</spanx> claims together when processin
g a JWT.</t>
<t>Clarified that identifier correlation may be acceptable when it is a core p
art 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 Identi
fier Types.</t>
<t>Clarified that Subject Identifiers don't provide confidentiality or integri
ty 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 t
han 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 cha
nge. (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> </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> </rfc>
 End of changes. 48 change blocks. 
1387 lines changed or deleted 803 lines changed or added

This html diff was produced by rfcdiff 1.48.