draft-ietf-secevent-subject-identifiers.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.2 (Ruby 2.6.3) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-ietf-secevent-subject-identifiers-11" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="secevent-subject-identifiers">Subject Identifiers for Security Event Tokens</title>

    <author initials="A." surname="Backman" fullname="Annabelle Backman" role="editor">
      <organization>Amazon</organization>
      <address>
        <email>richanna@amazon.com</email>
      </address>
    </author>
    <author initials="M." surname="Scurtescu" fullname="Marius Scurtescu">
      <organization>Coinbase</organization>
      <address>
        <email>marius.scurtescu@coinbase.com</email>
      </address>
    </author>
    <author initials="P." surname="Jain" fullname="Prachi Jain">
      <organization>Fastly</organization>
      <address>
        <email>prachi.jain1288@gmail.com</email>
      </address>
    </author>

    <date year="2022" month="April" day="21"/>

    <area>Security</area>
    <workgroup>Security Events Working Group</workgroup>
    <keyword>Internet-Draft</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 describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects.  It also defines a registry for defining and allocating names for such formats, as well as the <spanx style="verb">sub_id</spanx> JSON Web Token (JWT) claim.</t>



    </abstract>



  </front>

  <middle>


<section anchor="intro"><name>Introduction</name>
<t>As described in Section 1.2 of SET <xref target="RFC8417"/>, 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 host might be identified by an IP or MAC address, while a user might be identified by an email address).  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 <spanx style="verb">iss</spanx> claim and <spanx style="verb">sub</spanx> 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 - JSON <xref target="RFC7159"/> objects containing information identifying a subject - and Identifier Formats - 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>

<figure title="Example: Subject Identifier using the Email Identifier Format" anchor="figexampleintro"><artwork><![CDATA[
{
  "format": "email",
  "email": "user@example.com"
}
]]></artwork></figure>

<t>Subject Identifiers are intended to be a general-purpose mechanism for 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 <spanx style="verb">sub_id</spanx> claim (defined in this specification) to identify the JWT Subject.</t>

<figure title="Example: JWT using a Subject Identifier with the &quot;sub_id&quot; claim" anchor="figexampleintro2"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub_id": {
    "format": "phone_number",
    "phone_number": "+12065550100"
  }
}
]]></artwork></figure>

<t>Usage of Subject Identifiers also need not be limited to identifying JWT Subjects.  They are intended as a general-purpose means of expressing identifying information in an unambiguous manner.  Below is a non-normative example of a SET containing a hypothetical security event describing the interception of a message, using Subject Identifiers to identify the sender, intended recipient, and interceptor.</t>

<figure title="Example: SET with an event payload containing multiple Subject Identifiers" anchor="figexampleintro3"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "iat": 1508184845,
  "aud": "aud.example.com",
  "events": {
    "https://secevent.example.com/events/message-interception": {
      "from": {
        "format": "email",
        "email": "alice@example.com"
      },
      "to": {
        "format": "email",
        "email": "bob@example.com"
      },
      "interceptor": {
        "format": "email",
        "email": "eve@example.com"
      }
    }
  }
}

]]></artwork></figure>

</section>
<section anchor="conv"><name>Notational Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>

<section anchor="defn"><name>Definitions</name>
<t>This specification utilizes terminology defined in <xref target="RFC7159"/> and <xref target="RFC8417"/>.</t>

<t>Within this specification, the terms "Subject" and "subject" refer generically to anything being identified via one or more pieces of information.  The term "JWT Subject" refers specifically to the to the subject of a JWT. (i.e., the subject that the JWT asserts claims about)</t>

</section>
</section>
<section anchor="sub-ids"><name>Subject Identifiers</name>
<t>A Subject Identifier is a JSON <xref target="RFC7159"/> object whose contents may be used to identify a subject within some context.  An Identifier Format is a named definition of a set of information that may be used to identify a subject, and the rules for encoding that information as a Subject Identifier; they define the syntax and semantics of Subject Identifiers.  A Subject Identifier MUST conform to a specific Identifier Format, and MUST contain a <spanx style="verb">format</spanx> member whose value is the name of that Identifier Format.</t>

<t>Every Identifier Format MUST have a unique name registered in the IANA "Security Event Identifier Formats" registry established by <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 SHOULD 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 required, optional, or prohibited.  The <spanx style="verb">format</spanx> member is reserved for use as described in this specification; Identifier Formats MUST NOT declare any rules regarding the <spanx style="verb">format</spanx> member.</t>

<t>Every member within a Subject Identifier MUST match the rules specified for that 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 Formats versus Principal Types</name>
<t>Identifier Formats define how to encode identifying information for a subject.  They do not define the type or nature of the subject itself.  E.g., While the <spanx style="verb">email</spanx> Identifier Format declares that the value of the <spanx style="verb">email</spanx> member is an email address, a subject in a Security Event that is identified by an <spanx style="verb">email</spanx> 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 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 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 by <xref target="iana-formats"/>.</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 <spanx style="verb">acct</spanx> URI as defined in <xref target="RFC7565"/>.  Subject Identifiers in this format MUST contain a <spanx style="verb">uri</spanx> member whose value is the <spanx style="verb">acct</spanx> URI for the subject.  The <spanx style="verb">uri</spanx> member is REQUIRED and MUST NOT be null or empty.  The Account Identifier Format is identified by the name <spanx style="verb">account</spanx>.</t>

<t>Below is a non-normative example Subject Identifier for the Account Identifier Format:</t>

<figure title="Example: Subject Identifier for the Account Identifier Format" anchor="figexamplesubidaccount"><artwork><![CDATA[
{
  "format": "account",
  "uri": "acct:example.user@service.example.com"
}
]]></artwork></figure>

</section>
<section anchor="sub-id-email"><name>Email Identifier Format</name>
<t>The Email Identifier Format identifies a subject using an email address.  Subject Identifiers in this format MUST contain an <spanx style="verb">email</spanx> member whose value is a string containing the email address of the subject, formatted as an <spanx style="verb">addr-spec</spanx> as defined in Section 3.4.1 of <xref target="RFC5322"/>. The <spanx style="verb">email</spanx> member is REQUIRED and MUST NOT be null or empty. The value of the <spanx style="verb">email</spanx> member SHOULD identify a mailbox to which email may be delivered, in accordance with <xref target="RFC5321"/>. The Email Identifier Format is identified by the name <spanx style="verb">email</spanx>.</t>

<t>Below is a non-normative example Subject Identifier in the Email Identifier Format:</t>

<figure title="Example: Subject Identifier in the Email Identifier Format" anchor="figexamplesubidemail"><artwork><![CDATA[
{
  "format": "email",
  "email": "user@example.com"
}
]]></artwork></figure>

<section anchor="email-canon"><name>Email Canonicalization</name>
<t>Many email providers will treat multiple email addresses as equivalent. While the domain portion of an <xref target="RFC5322"/> email address is consistently treated as case-insensitive per <xref target="RFC1034"/>, some providers treat the local part of the email address as case-insensitive as well, and consider "user@example.com", "User@example.com", and "USER@example.com" as the same email address. This has led users to view these strings as equivalent, driving service providers to implement proprietary email canonicalization algorithms to ensure that email addresses entered by users resolve to the same canonical string. When receiving an Email Subject Identifier, the recipient SHOULD use their implementation's canonicalization algorithm to resolve the email address to the same string used in their system.</t>

</section>
</section>
<section anchor="sub-id-iss-sub"><name>Issuer and Subject Identifier Format</name>
<t>The Issuer and Subject Identifier Format identifies a subject using a pair of <spanx style="verb">iss</spanx> and <spanx style="verb">sub</spanx> members, analagous to how subjects are identified using the <spanx style="verb">iss</spanx> and <spanx style="verb">sub</spanx> claims in <xref target="OpenID.Core">OpenID Connect</xref> ID Tokens.  These members MUST follow the formats of the <spanx style="verb">iss</spanx> member and <spanx style="verb">sub</spanx> member defined by <xref target="RFC7519"/>, respectively.  Both the <spanx style="verb">iss</spanx> member and the <spanx style="verb">sub</spanx> member are REQUIRED and MUST NOT be null or empty. The Issuer and Subject Identifier Format is identified by the name <spanx style="verb">iss_sub</spanx>.</t>

<t>Below is a non-normative example Subject Identifier in the Issuer and Subject Identifier Format:</t>

<figure title="Example: Subject Identifier in the Issuer and Subject Identifier Format" anchor="figexamplesubidisssub"><artwork><![CDATA[
{
  "format": "iss_sub",
  "iss": "http://issuer.example.com/",
  "sub": "145234573"
}
]]></artwork></figure>

</section>
<section anchor="sub-id-opaque"><name>Opaque Identifier Format</name>
<t>The Opaque Identifier Format describes a subject that is identified with a string with no semantics asserted beyond its usage as an identifier for the subject, such as a UUID or hash used as a surrogate identifier for a record in a database.  Subject Identifiers in this format MUST contain an <spanx style="verb">id</spanx> member whose value is a JSON string containing the opaque string identifier for the subject.  The <spanx style="verb">id</spanx> member is REQUIRED and MUST NOT be null or empty.  The Opaque Identifier Format is identified by the name <spanx style="verb">opaque</spanx>.</t>

<t>Below is a non-normative example Subject Identifier in the Opaque Identifier Format:</t>

<figure title="Example: Subject Identifier in the Opaque Identifier Format" anchor="figexamplesubidopaque"><artwork><![CDATA[
{
  "format": "opaque",
  "id": "11112222333344445555"
}
]]></artwork></figure>

</section>
<section anchor="sub-id-phone"><name>Phone Number Identifier Format</name>
<t>The Phone Number Identifier Format identifies a subject using a telephone number.  Subject Identifiers in this format MUST contain a <spanx style="verb">phone_number</spanx> member whose value is a string containing the full telephone number of the subject, including international dialing prefix, formatted according to <xref target="E164">E.164</xref>. The <spanx style="verb">phone_number</spanx> member is REQUIRED and MUST NOT be null or empty. The Phone Number Identifier Format is identified by the name <spanx style="verb">phone_number</spanx>.</t>

<t>Below is a non-normative example Subject Identifier in the Email Identifier Format:</t>

<figure title="Example: Subject Identifier in the Phone Number Identifier Format" anchor="figexamplesubidphone"><artwork><![CDATA[
{
  "format": "phone_number",
  "phone_number": "+12065550100"
}
]]></artwork></figure>

</section>
<section anchor="sub-id-aliases"><name>Aliases Identifier Format</name>
<t>The Aliases Identifier Format describes a subject that is identified with a list of different Subject Identifiers. It is intended for use when a variety of identifiers have been shared with the party that will be interpreting the Subject Identifier, and it is unknown which of those identifiers they will recognize or support.  Subject Identifiers in this format MUST contain an <spanx style="verb">identifiers</spanx> member whose value is a JSON array containing one or more Subject Identifiers.  Each Subject Identifier in the array MUST identify the same entity.  The <spanx style="verb">identifiers</spanx> member is REQUIRED and MUST NOT be null or empty.  It MAY contain multiple instances of the same Identifier Format (e.g., multiple Email Subject Identifiers), but SHOULD NOT contain exact duplicates.  This format is identified by the name <spanx style="verb">aliases</spanx>.</t>

<t><spanx style="verb">aliases</spanx> Subject Identifiers MUST NOT be nested; i.e., the <spanx style="verb">identifiers</spanx> member of an <spanx style="verb">aliases</spanx> Subject Identifier MUST NOT contain a Subject Identifier in the <spanx style="verb">aliases</spanx> format.</t>

<t>Below is a non-normative example Subject Identifier in the Aliases Identifier Format:</t>

<figure title="Example: Subject Identifier in the Aliases Identifier Format" anchor="figexamplesubididtoken"><artwork><![CDATA[
{
  "format": "aliases",
  "identifiers": [
    {
      "format": "email",
      "email": "user@example.com"
    },
    {
      "format": "phone_number",
      "phone_number": "+12065550100"
    },
    {
      "format": "email",
      "email": "user+qualifier@example.com"
    }
  ]
}
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="jwt-claims"><name>Subject Identifiers in JWTs</name>

<section anchor="jwt-claims-sub_id"><name><spanx style="verb">sub_id</spanx> Claim</name>
<t>The <spanx style="verb">sub</spanx> JWT Claim is defined in Section 4.1.2 of <xref target="RFC7519"/> as containing a string value, and therefore cannot contain a Subject Identifier (which is a JSON object) as its value.  This document defines the <spanx style="verb">sub_id</spanx> JWT Claim, in accordance with Section 4.2 of <xref target="RFC7519"/>, as a common claim that identifies the JWT Subject using a Subject Identifier.  When present, the value of this claim MUST be a Subject Identifier that identifies the subject of the JWT.  The <spanx style="verb">sub_id</spanx> claim MAY be included in a JWT, whether or not the <spanx style="verb">sub</spanx> claim is present.  When both the <spanx style="verb">sub</spanx> and <spanx style="verb">sub_id</spanx> claims are present in a JWT, they MUST identify the same subject, as a JWT has one and only one JWT Subject.</t>

<t>When processing a JWT with both <spanx style="verb">sub</spanx> and <spanx style="verb">sub_id</spanx> claims, implementations MUST NOT rely on both claims to determine the JWT Subject.  An implementation MAY attempt to determine the JWT Subject from one claim and fall back to using the other if it determines it does not understand the format of the first claim.  For example, an implementation may attempt to use <spanx style="verb">sub_id</spanx>, and fall back to using <spanx style="verb">sub</spanx> upon finding that <spanx style="verb">sub_id</spanx> contains a Subject Identifier whose format is not recognized by the implementation.</t>

<t>Below are non-normative examples of JWTs containing the <spanx style="verb">sub_id</spanx> claim:</t>

<figure title="Example: JWT containing a &quot;sub_id&quot; claim and no &quot;sub&quot; claim" anchor="figexamplejwtsubidemail"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub_id": {
    "format": "email",
    "email": "user@example.com"
  }
}
]]></artwork></figure>

<figure title="Example: JWT where both the &quot;sub&quot; and &quot;sub_id&quot; claims identify the JWT Subject using the same identifier" anchor="figexamplejwtsamesubid"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub": "user@example.com",
  "sub_id": {
    "format": "email",
    "email": "user@example.com"
  }
}
]]></artwork></figure>

<figure title="Example: JWT where both the &quot;sub&quot; and &quot;sub_id&quot; claims identify the JWT Subject using different values of the same identifier type" anchor="figexamplejwtdiffsubvalues"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub": "liz@example.com",
  "sub_id": {
    "format": "email",
    "email": "elizabeth@example.com"
  }
}
]]></artwork></figure>

<figure title="Example: JWT where the &quot;sub&quot; and &quot;sub_id&quot; claims identify the JWT Subject via different types of identifiers" anchor="figexamplejwtdiffsubtype"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub": "user@example.com",
  "sub_id": {
    "format": "account",
    "uri": "acct:example.user@service.example.com"
  }
}
]]></artwork></figure>

</section>
<section anchor="subid-and-isssub-subject-identifiers"><name><spanx style="verb">sub_id</spanx> and <spanx style="verb">iss_sub</spanx> Subject Identifiers</name>
<t>The <spanx style="verb">sub_id</spanx> claim MAY contain an <spanx style="verb">iss_sub</spanx> Subject Identifier.  In this case, the JWT's <spanx style="verb">iss</spanx> claim and the Subject Identifier's <spanx style="verb">iss</spanx> member MAY be different.  For example, in <xref target="OpenID.Core">OpenID Connect</xref> client may construct such a JWT when sending JWTs back to its OpenID Connect Identity Provider, in order to identify the JWT Subject using an identifier known to be understood by both parties.  Similarly, the JWT's <spanx style="verb">sub</spanx> claim and the Subject Identifier's <spanx style="verb">sub</spanx> member MAY be different.  For example, this may be used by an OpenID Connect client to communicate the JWT Subject's local identifier at the client back to its Identity Provider.</t>

<t>Below are non-normative examples of a JWT where the <spanx style="verb">iss</spanx> claim and <spanx style="verb">iss</spanx> member within the <spanx style="verb">sub_id</spanx> claim are the same, and a JWT where they are different.</t>

<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where JWT issuer and JWT Subject issuer are the same" anchor="figexamplejwtsameiss"><artwork><![CDATA[
{
  "iss": "issuer.example.com",
  "sub_id": {
    "format": "iss_sub",
    "iss": "issuer.example.com",
    "sub": "example_user"
  }
}
]]></artwork></figure>

<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where the JWT issuer and JWT Subject issuer are different" anchor="figexamplejwtdiffiss"><artwork><![CDATA[
{
  "iss": "client.example.com",
  "sub_id": {
    "format": "iss_sub",
    "iss": "issuer.example.com",
    "sub": "example_user"
  }
}
]]></artwork></figure>

<figure title="Example: JWT with an &quot;iss_sub&quot; Subject Identifier where the JWT &quot;iss&quot; and &quot;sub&quot; claims differ from the JWT Subject's &quot;iss&quot; and &quot;sub&quot; members" anchor="figexamplejwtdiffisssub"><artwork><![CDATA[
{
  "iss": "client.example.com",
  "sub": "client_user",
  "sub_id": {
    "format": "iss_sub",
    "iss": "issuer.example.com",
    "sub": "example_user"
  }
}
]]></artwork></figure>

</section>
</section>
<section anchor="implementer"><name>Considerations for Specifications that Define Identifier Formats</name>
<t>Identifier Format definitions MUST NOT make assertions or declarations regarding the subject being identified by the Subject Identifier (e.g., an Identifier Format cannot be defined as specifically identifying human end users), as such statements are outside the scope of Identifier Formats and Subject Identifiers, and expanding that scope for some Identifier Formats but not others would harm interoperability, as applications that depend on this expanded scope to disambiguate the subject type would be unable to use Identifier Formats that do not provide such rules.</t>

</section>
<section anchor="privacy"><name>Privacy Considerations</name>

<section anchor="identifier-correlation"><name>Identifier Correlation</name>
<t>The act of presenting two or more identifiers for a single subject together (e.g., within an <spanx style="verb">aliases</spanx> Subject Identifier, or via the <spanx style="verb">sub</spanx> and <spanx style="verb">sub_id</spanx> JWT claims) may communicate more information about the subject than was intended.  For example, the entity to which the identifiers are presented now knows that both identifiers relate to the same subject, and may be able to correlate additional data based on that.  When transmitting Subject Identifiers, the transmitter SHOULD take care that they are only transmitting multiple identifiers together when it is known that the recipient already knows that the identifiers are related (e.g., because they were previously sent to the recipient as claims in an OpenID Connect ID Token), or when correlation is essential to the use case.  Implementers must consider such risks, and specs that use subject identifiers must provide appropriate privacy considerations of their own.</t>

<t>The considerations described in Section 6 of <xref target="RFC8417"/> also apply when Subject Identifiers are used within SETs.  The considerations described in Section 12 of <xref target="RFC7519"/> also apply when Subject Identifiers are used within JWTs.</t>

</section>
</section>
<section anchor="security"><name>Security Considerations</name>

<section anchor="confidentiality-and-integrity"><name>Confidentiality and Integrity</name>
<t>This specification does not define any mechanism for ensuring the confidentiality or integrity of a Subject Identifier.  Where such properties are required, implementations MUST use mechanisms provided by the containing format (e.g., integrity protecting SETs or JWTs using JWS <xref target="RFC7515"/>), or at the transport layer or other layer in the application stack (e.g., using TLS <xref target="RFC8446"/>).</t>

<t>Further considerations regarding confidentiality and integrity of SETs can be found in Section 5.1 of <xref target="RFC8417"/>.</t>

</section>
</section>
<section anchor="iana"><name>IANA Considerations</name>

<section anchor="iana-formats"><name>Security Event Identifier Formats Registry</name>
<t>This document defines Identifier Formats, for which IANA is asked to create and maintain a new registry titled "Security Event Identifier Formats".  Initial values for the Security Event Identifier Formats registry are given in <xref target="sub-ids"/>.  Future assignments are to be made through the Expert Review registration policy <xref target="BCP26"/> and shall follow the template presented in <xref target="iana-formats-template"/>.</t>

<t>It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.  In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.</t>

<section anchor="registry-location"><name>Registry Location</name>
<t>(This section to be removed by the RFC Editor before publication as an RFC.)</t>

<t>The authors recommend that the Identifier Formats registry be located at <spanx style="verb">https://www.iana.org/assignments/secevent/</spanx>.</t>

</section>
<section anchor="iana-formats-template"><name>Registration 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 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 may also be provided.</t>
  </dd>
  <dt>Defining Document(s)</dt>
  <dd>
    <t>A reference to the document or documents that define the Identifier Format.  The definition 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, prohibited, or the circumstances under which the member may be optional, required, or prohibited. URIs that can 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</name>

<t><list style="symbols">
  <t>Format Name: "account"</t>
  <t>Format Description: Subject identifier based on <spanx style="verb">acct</spanx> URI.</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) URL.</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 Format</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="aliases-identifier-format"><name>Aliases Identifier Format</name>

<t><list style="symbols">
  <t>Format Name: "aliases"</t>
  <t>Format Description: Subject identifier that groups together multiple different 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 registration request to verify its completeness. The Expert Reviewer must base their decision to accept or reject the request on a fair and impartial assessment of the request. If the Expert Reviewer has a conflict of interest, such as being an author of a defining document referenced by the request, they must recuse themselves from the approval process for that request. In the case where a request is rejected, the Expert Reviewer should provide the requesting party with a written statement expressing the reason for rejection, and be prepared to cite any sources of information that went into that decision.</t>

<t>Identifier Formats need not be generally applicable and may be highly specific to a particular domain; it is expected that formats may be registered for niche or industry-specific use cases. The Expert Reviewer should focus on whether the format is thoroughly documented, 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 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 <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 <xref 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: IESG</t>
  <t>Specification Document(s): <xref target="jwt-claims-sub_id"/> of this document.</t>
</list></t>

</section>
</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='BCP26' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></author>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>


<reference anchor="E164" target="http://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="http://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'><organization/></author>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='W. Denniss' initials='W.' surname='Denniss'><organization/></author>
<author fullname='M. Ansari' initials='M.' surname='Ansari'><organization/></author>
<date month='July' year='2018'/>
<abstract><t>This specification defines the Security Event Token (SET) data structure.  A SET describes statements of fact from the perspective of an issuer about a subject.  These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject.  This specification is intended to enable representing security- and identity-related events.  A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8417'/>
<seriesInfo name='DOI' value='10.17487/RFC8417'/>
</reference>



<reference anchor='RFC7519' target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>



<reference anchor='RFC7159' target='https://www.rfc-editor.org/info/rfc7159'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organization/></author>
<date month='March' year='2014'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='RFC' value='7159'/>
<seriesInfo name='DOI' value='10.17487/RFC7159'/>
</reference>



<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference anchor='RFC7565' target='https://www.rfc-editor.org/info/rfc7565'>
<front>
<title>The 'acct' URI Scheme</title>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.</t></abstract>
</front>
<seriesInfo name='RFC' value='7565'/>
<seriesInfo name='DOI' value='10.17487/RFC7565'/>
</reference>



<reference anchor='RFC5322' target='https://www.rfc-editor.org/info/rfc5322'>
<front>
<title>Internet Message Format</title>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'><organization/></author>
<date month='October' year='2008'/>
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of &quot;electronic mail&quot; messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>



<reference anchor='RFC5321' target='https://www.rfc-editor.org/info/rfc5321'>
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname='J. Klensin' initials='J.' surname='Klensin'><organization/></author>
<date month='October' year='2008'/>
<abstract><t>This document is a specification of the basic protocol for Internet electronic mail transport.  It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete.  It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions.  Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a &quot;mail submission&quot; protocol for &quot;split-UA&quot; (User Agent) mail reading systems and mobile environments.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5321'/>
<seriesInfo name='DOI' value='10.17487/RFC5321'/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-core-1_0.html">
  <front>
    <title>OpenID Connect Core 1.0</title>
    <author initials="N." surname="Sakimura" fullname="Nat Sakimura">
      <organization>Nomura Research Institute, Ltd.</organization>
    </author>
    <author initials="J." surname="Bradley" fullname="John Bradley">
      <organization>Ping Identity</organization>
    </author>
    <author initials="M." surname="Jones" fullname="Michael B. Jones">
      <organization>Microsoft</organization>
    </author>
    <author initials="B." surname="de Medeiros" fullname="Breno de Medeiros">
      <organization>Google</organization>
    </author>
    <author initials="C." surname="Mortimore" fullname="Chuck Mortimore">
      <organization>Salesforce</organization>
    </author>
    <date year="2014" month="November"/>
  </front>
</reference>




<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname='P.V. Mockapetris' initials='P.V.' surname='Mockapetris'><organization/></author>
<date month='November' year='1987'/>
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>



<reference anchor='RFC7515' target='https://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></author>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></author>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</reference>



<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>




    </references>


<section numbered="no" anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors would like to thank the members of the IETF Security Events working group, as well as those of the OpenID Shared Signals and Events Working Group, whose work provided the original basis for this document.
We would also like to acknowledge Aaron Parecki, Denis Pinkas, Justin Richer, Mike Jones and other members of the working group for reviewing this document.</t>

</section>
<section numbered="no" anchor="change-log"><name>Change Log</name>
<t>(This section to be removed by the RFC Editor before publication as an RFC.)</t>

<t>Draft 00 - AB - First draft</t>

<t>Draft 01 - AB:</t>

<t><list style="symbols">
  <t>Added reference to RFC 5322 for format of <spanx style="verb">email</spanx> claim.</t>
  <t>Renamed <spanx style="verb">iss_sub</spanx> type to <spanx style="verb">iss-sub</spanx>.</t>
  <t>Renamed <spanx style="verb">id_token_claims</spanx> type to <spanx style="verb">id-token-claims</spanx>.</t>
  <t>Added text specifying the nature of the subjects described by each type.</t>
</list></t>

<t>Draft 02 - AB:</t>

<t><list style="symbols">
  <t>Corrected format of phone numbers in examples.</t>
  <t>Updated author info.</t>
</list></t>

<t>Draft 03 - AB:</t>

<t><list style="symbols">
  <t>Added <spanx style="verb">account</spanx> type for <spanx style="verb">acct</spanx> URIs.</t>
  <t>Replaced <spanx style="verb">id-token-claims</spanx> type with <spanx style="verb">aliases</spanx> type.</t>
  <t>Added email canonicalization guidance.</t>
  <t>Updated semantics for <spanx style="verb">email</spanx>, <spanx style="verb">phone</spanx>, and <spanx style="verb">iss-sub</spanx> types.</t>
</list></t>

<t>Draft 04 - AB:</t>

<t><list style="symbols">
  <t>Added <spanx style="verb">sub_id</spanx> JWT Claim definition, guidance, examples.</t>
  <t>Added text prohibiting <spanx style="verb">aliases</spanx> nesting.</t>
  <t>Added privacy considerations for identifier correlation.</t>
</list></t>

<t>Draft 05 - AB:</t>

<t><list style="symbols">
  <t>Renamed the <spanx style="verb">phone</spanx> type to <spanx style="verb">phone-number</spanx> and its <spanx style="verb">phone</spanx> claim to <spanx style="verb">phone_number</spanx>.</t>
</list></t>

<t>Draft 06 - AB:</t>

<t><list style="symbols">
  <t>Replaced usage of the word "claim" to describe members of a Subject Identifier with the word "member", in accordance with terminology in RFC7159.</t>
  <t>Renamed the <spanx style="verb">phone-number</spanx> type to <spanx style="verb">phone_number</spanx> and <spanx style="verb">iss-sub</spanx> to <spanx style="verb">iss_sub</spanx>.</t>
  <t>Added normative requirements limiting the use of both <spanx style="verb">sub</spanx> and <spanx style="verb">sub_id</spanx> claims together when processing a JWT.</t>
  <t>Clarified that identifier correlation may be acceptable when it is a core part of the use case.</t>
  <t>Replaced references to OIDF with IETF in IANA Considerations.</t>
  <t>Recommended the appointment of multiple Designated Experts, and a location for the Subject Identifier Types registry.</t>
  <t>Added "_" to list of allowed characters in the Type Name for Subject Identifier Types.</t>
  <t>Clarified that Subject Identifiers don't provide confidentiality or integrity protection.</t>
  <t>Added references to SET, JWT privacy and security considerations.</t>
  <t>Added section describing the difference between subject identifier type and principal type that hopefully clarifies things and doesn't just muddy the water further.</t>
</list></t>

<t>Draft 07 - AB:</t>

<t><list style="symbols">
  <t>Emphasized that the spec is about identifiers, not the things they identify:
  <list style="symbols">
      <t>Renamed "Subject Identifier Type" to "Identifier Format".</t>
      <t>Renamed <spanx style="verb">subject_type</spanx> to <spanx style="verb">format</spanx>.</t>
      <t>Renamed "Security Event Subject Identifier Type Registry" to "Security Event Identifier Format Registry".</t>
      <t>Added new section with guidance for specs defining Identifier Formats, with normative prohibition on formats that describe the subject itself, rather than the identifier.</t>
    </list></t>
  <t>Clarified the meaning of "subject":
  <list style="symbols">
      <t>Defined "subject" as applying generically and "JWT Subject" as applying specifically to the subject of a JWT.</t>
      <t>Replaced most instances of the word "principal" with "subject".</t>
    </list></t>
  <t>Added <spanx style="verb">opaque</spanx> Identifier Format</t>
</list></t>

<t>Draft 08 - JR, AB:</t>

<t><list style="symbols">
  <t>Added <spanx style="verb">did</spanx> Identifier Format</t>
  <t>Alphabetized identifier format definitions</t>
  <t>Replaced "type" with "format" in places that had been missed in the -07 change. (mostly IANA Considerations)</t>
  <t>Miscellaneous editorial fixes</t>
</list></t>

<t>Draft 09 - AB:</t>

<t><list style="symbols">
  <t>Miscellaneous editorial fixes</t>
</list></t>

<t>Draft 10 - PJ:</t>

<t><list style="symbols">
  <t>Added author</t>
  <t>Editorial nits</t>
</list></t>

<t>Draft 11 - PJ:</t>

<t><list style="symbols">
  <t>Miscellaneous editorial fixes</t>
  <t>Moved aliases to the last in identifier format definitions</t>
  <t>Acknowledged individual reviewers</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIALy0YWIAA809a3PbRpLf+Stw9IdYtyQtyY8kSm3dKrKTlcuvs+VyXWVT
1hAYkohAgIsBJDMu7W+/fs0DL0py4q3VB1siMDM9Pf2e7uZ0Oh1VaZXpo+hd
Pf9Nx1V0mui8ShepLk20KMronY7rMq220bNLeBCdFRc6NyM1n5f68igyOtb4
+dTw8Gnqh4+SIs7VGuZOSrWAR7paTHcNmB4cjBJVwYDD/cPD6f6j6eHBKIYP
lkW5hbWqZJRuyqOoKmtTHe7vf79/OBqpUqsjB+XoqigvlmVRb45akJvoAzxK
82X0Mz4eXegtvJscRad5pctcV9OnCOVoZCqVJx9VVuQAyFab0SY9in6pingS
maKsSr0w8Nt2jb/8CuvX1aooj0bRdBTBT5qbo+h4Fv2o4ou1yukzRsJxnqu5
zjLdeFaUS5Wnv6sqLXJ4Z61+L/iBXqs0O4rKNF4pGPk3RY9mcbGmx2WBh6aT
tCrKUWPxl7PoHWy80iaug+VfqjKtTetRc/WTIs3nyuhw/TUNmxk77G+xvESQ
NBZ+M4ueqzTc8ptSxavUf9pc7idlqmwbLrah92e/wfsHh99997clfswL5UW5
hnGXGjAd/Xjy5vDJUfT2p5PvDg6fwAfPDp48OqKZhJrPVhqAwoOlxVQWbep5
lsZRpTMNE67rPI3pUZTX67kukTA2mRxKpcqlro6iVVVtjh48uLq6mqVVPYMJ
H5Q6fnA2ffvsZPpsBotOD/cP9g8OpqcPNA915BDJhi2BWTjOOgC8z1M5c0v8
B/vw5+nxq+PZ8w9ns5NMpWvT2N7zd69fRR/0nNkx4jcGQVe5mgEkD5Qx6TJf
IzM8+O2qGoQXFoa/n54+baz5FDg3r0qVpb/rpCEm7sOrZi+6PJjtd2AwAsTV
QwLh7O2DJE2mcVHqB0PrA59mSfQBBANt8aTIke/Seh3d//DwZK+BKRAQozRf
hMTxeqPz06ezE1iiAT9/jtPlKOfwedQHMQBcwKtpMgOh8MBsdGzkAwCbxhL4
04OP+7NVtc4CeF4VlxqJCY/wUXd7U9kls8sr4FN1ka7rUtnPmWteqarzhBDz
qsCPorfaaFXGKyAsA3urKz2JXlTJbNS3ynMQRaVKMr1tLvK8WOXtJ7TIG+QE
Pl0Qp31TgoB5DsLRNCd8iYJKZ9GPrac0KTwsC1OgeO2ZEIbAWb/UiU7hrea0
P5Y6L/oe07w/F8Uy072Tnsyil0g2azir5pQnqzq+6D6kCd+pTBsgpxgmnU6n
kZobIPkY4HbaRLM28TwM3HCVVqs079eVIEK3kak3G1gwUtElCFQNrxSLKFB9
UVXYP/FlUo0mKnVG08PDCgQarTyLQLilJkLChLEiQ4gDkDMNvZkX9CmsIXM1
1lIwGnRoXNUlTO7YBwZUK6C9BOR8mc41ACujJxGoRMJewitVxr66SHNNS5pt
XqlP9KIBcQ6LxWxA6DwuEiSqAVBIlhW8Y9jcKSApM4VMDW8AFpYpwLul2ehj
nA0XUllWIALgTwSO1zM1sIZAOcEFrkDp4v8I5TkA8TFNztsS9D4I2r0oRjk6
i/jo12mSIG2B+C6LBLCFCPp8L8U/r0d/DX5Gx8YhDfGJdEBvH8wO8QzePTuL
Pn/+L1RXjw6+vb6e9J6waREYkk2lLnSTZnBjsK00j7OasDqvKzzuKEvXqcyk
ItiNrPjt44Pvr69Bs8KIdKMyPMro9E2kkqTUBhEUvX/7YhLpKgbkP00XC10i
7VbbDeDTExDDk2teAYjDnSLtOHEDr9QWNIKeLWc496owFWByuapaY+ZbAQRO
7OXxiYfnapVmuOfagBwdHkkWgx21B6D/BAbKSpfI0RNCIYKFRx6DsQKzAnT0
J24M90U0aynSRBd5cZVP8FN4D7cKi67rrEo3AA3tCdYF2IC2VLRMcX47Wt72
ICI0SPif1BpGE8ZVHBd13vOubKfYqH/WweflpLNJROdmBaJVLJaJnPN5asw5
ky4xBZK4/M3HOgHiBP1F1FIwTsAaAd5nroYjNRYhIOtyA3QEBgs9BGtHw17L
GUk0K+YIqwVYNZ8qHGjxMTSYiRz4wazSDZCuw4LabMoCKBM4oCH/PDEJ2kyX
xCYsWxjFUQp0Wqy1f7/Is220Upe6iUOUJ8YUceqkNm5mLURX4OmHY0N0g2w6
Q+JYoN0Ae4jhfGAPYA/AvAqkE+4AkIwKwSJKEesjutYazfjUrEMyCshvrvF0
AhIajc4KCzXMAK8AruaZXk/4r6b4t8Kyz4mbsqwTcXDwGMWBiFs6RcXyNFQD
9iRIzjowp3SqfmokclIFU1ENRldESWUNStRKRJxjVVwhekgT6OAgwR1LTI+W
2rYBsvKkwxIFkhog0NRCdHamjUrLPZT6qgcpgN0fdQZApfg8L/Kpcy8cSRFh
d4ey3nMHZQL8wMm2oKsNbgTP/xk96OAOAPnXv/41+gw2yJh3Oz6KxjTLeIIf
8q/wGYrDvwls6BGNR9c89Ci6t0iX8oSUExu8fx0/48/6XPubIRtfg8nTQ02q
ZMcqT5wmAP7XuQbHYLqpy01hQmpHJg0P1WkT4ZBQ+dP5AUgpgqeWmrUN6jZY
JFBvwFNoKNzuBFFC0pHVxPx9uBCJ5kwDFqX3macSftzmuL2GwMLhuJBMHp4q
kCYeH1PoLDxAOl9eE974TGZoQAQkez6y7KF3o9Zn8M5fDg73nzx+/Bgcxv0x
vHI9TBSHHapAgJkMerFihWP0DwHyH2PGDFLGezofNG36SATNt4GzC2khwJgh
q1Zvm+RF3NulLdAyuLT+tEEuC+RmR2ygCM6jGqTTPF3WRY1GDHhw5a2pB8V3
ICPBntluUEuAcQuufNNiCwVeZcMPsd5YS1wB6AbxZuVCH+7aVGUQE+XE4wSU
arpJ4Q22yd0iRXkHqkuJxA4e73938N2j7x49pg9VjXSI/3UHsEnqydR69jaa
F454wC8/kN1OQzy4GZDUS5jd/z0gAeWRk4Pg5MS6KQj5lWv79rgq7j7tvJjv
njRA9N1nB4z0zj6y/yLjDnHuw648B6ok9kR9SKS3UdusUElIq8547SEzZOFX
RWVDUidFjrOghQYODsxx2fRvAk8H42oXwKcYOjXR+OX7d2fjCf8fvXpNv799
9r/vT98+e4q/v/v78YsX7hd+YwR/vH7/Qp7jb37kyeuXL5+9esqDXx7/35ip
fPz6zdnp61fHL8ZWGmNsuV6TiVhq65HgEYFMqFh0NDwytn4OD9AZAkZ5Sl6k
3TFI+vwafb7wZ9TjZddVKj42OBppXmTFchsFeqJhYyHgodcHy36w9nN75glb
3zArIFUObMxbN/YvMD1BLJM4ROmTkcWp8i1OuewYkNFlqiK0XkEBo08UgdCI
2aMLJCSLXVo4GgfyWFYLoJT1CMyi4TxZNTuL7qczPZs0HpLqteoRTG9dotVJ
4cpIzYu62us3Mz7fgxmmaWJ6KXF03KvHUZgP2bpgdKP2ILfFetdAM2AVNPRS
YM6JhUJ+hXg7gK7jvGsriRohGzhxlMWIAZu4hXPGyY3rT6w5JOZ0I5TCRmgw
54Ch+wNOsL0xTNOvyHG3fXgmZgeM4OocbrBU0kUN78KOQNkEr58z3OegECla
ykdzqTL0gCWABchkp1RVvWYz+KPgc3WPgpYi502B4k/Rqaa5OIikS2vQaQpz
A7M1Q3Zd72bs40/aVGqepWbFbvvnzxhZn0qoCcM66I2ANM3gHTiU6VttUrxN
qqJXCALJpLasoPAMhr26bhXtHcUbWDpwBM7eJpqZlyDvgScxfBDGhzaqrNAt
Eck679v5XTYNqO4leRDOPlBIAoYPk8DOCWwYnsZVtm35yAOU3pgQaCUR8Vyj
ASQuc7ViC5AXwjVK/c86ha0B7jeszegUwFdegSVWUSwGJVyb5FIMvYE0uuSI
JuK0ozO6YvqHvmOyug8Gg2CjqMpWeBaQqMrEGoQtGBwRWy5wMYMBloOx8SqQ
CAKa7IClCk813/YFCQp60J39G9PDYbt4HzfruDnfugPxWMe10Pj3+ISV06pn
oT4BkWVuSnu+g+MBiz1nAng1YO2/sVHP6AzDmW0Vf9NP38wiSpsRjSH/Y0EC
QcjcujhJIahxMplDkqWNyrWDk5XR2QJGP6MYyAcKVRE9kX153sOcQonGq18W
rjKzHeh5oS/W6NYnmmxKDNY/phvHtFP3kE5c1FlC8QJYDM6cArwg+uncyyIT
aFtwUPAMPpkXnwQTEvQRu0dnRvttDoYg5+C1sSih630buejEAtsAANrx/hGo
EPaR9XEP0ui6QH1DTibiSJUFLEU0sjPIx7QvpASC2xBuGuESe00zoTi/kM6u
BWEmgLvILnUrUlWKqnbE2AhRwxmYFAWtihLgtxjcnC06y+DAkZV9/OZU9FEG
fjOYcPB/21/FA+UgDiVg4HnC/8sVI18i3KKTG3dAMKIVpQXw3uE1DqADV2bS
QRk94DMnqWFsYPB1rqsrjdFq0hlM80gkV4W/1QjXTym8DLPDqn8vrsCjKpnu
cOkrWpoMClxHs+VPFwoYLW5fI8i9BaCWcEBWOFmQFFvm4MWEr6gUXSkAMkqJ
syYKzAtl9MR7MhSyp5FAHmBDVAQva3EUjWCREDuA0NFlaRUNyRN0r90uiMUU
Raa6Qi0KvKHbiMgReYGLAinBXxY3pCSr5q9uccF27t27Fx3L5Up3Z9aNmKo4
rq4J7uGXe4O6EiHzNzjIAxFaDmmsUeNdphyg8ZLQuubnuOh59P7t6YDp9+Qx
mX59NG3Nj0Vg1QYGNCBwl/UcrMymgW4qoeYEMMj67F4Zo47H640alDEKivWm
2srgHRhsawRnyp8L+s5vE3rvUR52G4NrH/VG0mVVDmLBnuWz6shGYyisLqc5
uzG8DkhME0sIt4iy3wg1BmKQggeC8J5+ST4yAQ+9u5t821rtzkSXt82GFt0p
svdhsSAGRUkL4cIt22YiS0nEhngGXpyi3XreYhp7p/5w9mh2gPMwFz1+eHiI
XHTWa9fclq7PbjCRxJsKfBdrk4BSYD3D+xS3PtEZmh2o4lMWHWWi8pgvBj3k
BxbywTMdZigG8AvZSQTywLL9vPTlt1LENoyf23DNbuCEZSzPnCjYNManJK0Q
WIZWmsb44Hr0Eh0UXtsKa7x8gtOvSo0ekw2Tdu+JI/Q9gCoo6cab3UmxRobA
dB4b5UGR/j+OGFsknxq2rkzFJiStywSPqQnTFMxLeExHtoFt8lQH+w8fUaYI
Gg8ecgYawcDMl4zcfUuzzWX7ppdkGLY7ncnXPcVJNH7f/YzCke/fPXvb+Nxm
1hikypaUoRDqCl7IdCLmIfDLZaqvxCZjkdFC9iRKyvSSzN+WmmV7E5cmo5Sz
B3SFkQVeOW5Tg8qWBRgbq7Vhd83Upe4x8+G8dc62ytwass6MLvz+3PwCOdIF
WJrsZoikZbrs0vVErDa5v7EypSb/BS893cYI9G/Mjt00zfz20YcQi1CmmBEz
FqxktkCMa7GeTv3leQ8zthVRagymbrMqutXQXXqJrumRfjmJxaeviP+PRKcy
tcSrO9gVOjjuBpmuCr1w9Dfa7bkk3Ay7/6WZA/rr/XtBsuheBE84ZY8NnSDU
RKqDLV5awibBWW1BK4quaG/CKTEyYH3Qb4IniIE94MwMbasfC7lx7Uxnr6f9
h7D3u+i22x3UsLIBgD7i+n9M3dwGin7dI+vL7SVfbkqubveO84G7WsfXDh49
Pnz46PG3D3foJpgD/r+LcrrNVqxx95o93x1Mxb4x89Tg2zaWFrJRTxyGvQ/L
9/RXXgSxfr6EwQPW2wJvkIGMOd2CLbC0a746a836rSp6/x6YBR6DcF+xcFEM
V1kWS3TCW9NgFicaQRxNsp7uF9qhmKQxZITS/U+/JSoRCHk4vE/rIwXL3NVF
GjzEHTzG4P1BFhtauJ+teEnhKrr9P4CfQ/h5CD+P4Ocx/OxgHEHp7flmCD7L
K28o4+4VZbjs4hjKhGGGuWHITvWD1SBhkt+XeeNhWs5d3aMFUk8bjI6b5NN9
m0UtSQrGAVaulKBjPjXcKfI5aJUi+oVqVUDdYZ3MnjhLvVDf0We6CffD1N5Y
/d/oxXTSqm5IqhokfT6vO5D+blxZBjjOUoXm6K5YFr8i4azB9++mLzLwT5Ds
fHJm743wKQ+32Uj26uwKreDB2gaKns4xJGtWqgwSb8l92TJU5JOFWRyWQ/os
aUp9IlDqnDK3w2Av8l24PF2B0/Sog5Z5+jvdtkhJxhfrIPfuDcpIlaXahmwf
ZmX0X7s/U7CXYUriGQmkZrIYuWA5Fu54HdYF8y7K7JRveu3OnbcMXmWFAQ0f
0cG1u0Qoibtu3JBzZPb4hsMnBLk1geng1aTeZJRbbWwBzOLmmCPzxjlWdLg/
ek+7gQINzlHyQ+STWXqxyH7/rml7Lkt3pZ+6mRb2YvMPyMRBsTAQJ+XXrSXg
dgvPfqEkNZ+1N5DutismFGTS9czTk+h6i1TXXTPuguwv/6xhs7i5Hhjh3193
eAlJRbVCd5D5g8eA4r438Qlzoj+cYQLUb1fVlF3XoWw8zoUaucRlKgNtjJzy
o3ZyG2kOdigxL4vHpb3h1kczKWJqlBMp00yLFduGRJ9LXJJaiVjleGm5kwfu
s/j2QpOTtiiBHx0Umtgyvkv9s1UPjextt6He0KvfVmdTE3ZhsK4PXuAk8Hay
fyvRe0f+NABLoSHMUaaYVusWPpU0OBYSlEV/i2KDVt6dgGOFfTOBHeU26VM0
HbV4XvD2xN1dSpKGjy7ElhAEaruJuYtM0Gs2wuEX42iMjApWItU7oKh89o+R
PH2MFKJyxPmpCAf/aObVC06LWDK/eSAdLQE5COCkFV4LZH6paSmeQLbTuOtt
p/dTFmBzOsI2Wt6gN3cO5ntZ3Jiv2FpgxstcxRc40sex+OI3XaCl4+Yz9FcB
/+PRhRkNLixlKWORwiNb09ipSGvBjxcXAfxo1FkMToaAZGTXG8x0SXOfmOhR
zzw/UHfB5pJX45zaIBaaU+VNOJ1WRHrrVYpkkZAIbXlaTYI4+jNqNEJFs1sB
9ldmgKAO7kb6CjQaUrZdicH1ewV/HpZn3GFnvQD/G7aN5bq49d5dc7Wmkzp2
f7jdNg5MU7J0hbOTN96s+QIUZenvfxxDGgP5c5C9t0YTemOwCukN89VR5X0/
WTC07cNEou1G/xvILLy8v/P1/c1IpSyZYZT+AWxi0k/SraQO7errwGwjbWUj
7H3uyR3yFkcDhkDDdR1eCj0+cXxjykSSrX1jOmXG/a65e1G8JDFCHDbaiujm
S5k4o9uyNfvQnBAngWh7WjmVSUlJmXFKCg3HVtMPBrTaRm984g4mxiacHncD
fzSj4xx3kJRs1sNFQWqLuFESsTG8kK7TTJXZtoHOwODajc7w3ucmdNLJhaUF
nJXZwoKgtCrCJhbtPcPSfMUcbFmunmV8iOcOYm+pqFWL4zrF7CExBeXnLRJX
MhwlFZsrrYm5stDj7c/Q/uGl1I3zeDEoTz6i7LpRR6ZmQOxLjtk/LBQglnpN
LNw/DghKpEPCth8H+OuT7Hzi/0nIwaP8U5Bjyf5mBDnquSOG/GPe1n8G5vDC
809DHr0cKkqvJRlrPh21KWL6BsqlO2L5RHJUxGWjfnRhTYPkjD/lXPqeRNTP
95z/oMudcZRb/fQkzyZBKaFzKdfUt4VuWukBNa7BnHyBulkYYj36Tg2fuEB9
ARPXEKELkQRcKA2N4zmqVchn9Rz1ZqjXQUI+xmHxbdSv4FdWhDn27ou6wrNg
iOOCu6j05f723okbFsv600YFniLPQ117ir74sXHtbaQ3h03HLtd8UQDDSzVP
M1A9HEjYcJjY0wb3PuHGJ6AcGQBsVkFLt3PHw+MgA/HKVi3UuZpn2vrGPZDy
apyhLwlLjEeq1gGN86ZML1W8jVpE/fnehh8MFt2GVAdGkW2nMmAWkgmoOEAk
ERnC91Xhbh3C2xGpUYFXsmDrxZJDREJntjZpd8CbUtHR+B0IFZFDS1JhT+w5
b30wXGFFI1aHNs8DC8uulL9+6lo/9vrDp2VSCCEsNvBxKmpQcEV2nJweGW7h
29yeqZlQFRat2UY2QhmxHI7GVKzU3tGqSkWY7SBEqFxYzVWrDHQDkKrgoKZF
rkeoLVSsSl/5wvYNBc0as/oLm0bBhJwu2c6p73/kpgvS1FRWapVsQzT14dQ2
shKCmetYSWbbNrrSjPTLtKgNQGjE+mwtZIJMra7RapOz9ojKCPLY8wJuAfP4
ACZAucyNAMScZnLqtQAYyLWpfPoj82hqLkREUce/yPYM6e1aRhNYHg+7GAkn
u8mFxdmPxky3K4xgIYO23uhtH/bEh6i5hJxba6CM2zIG+m4Q8DTI9rdN6bhd
ym0XPeiJ9n/BquiJzYKueR2hZ5tnDCpl0v4LRrvKqMwJ2w/BES6p0+tNfnC3
SZKNmkrpHZcuhp1qKD/UauW4tTqV2cjiQ92BmLNLEfwbUk9UjtusVe0NRddh
4xxjycsZAUEkcNG4W/VAwZAKTxGlCRw6QkwOMXuvzz+8k9xiONbH19fMSGHh
HHUozNSWrwY4/Mx/2otnr13ROgD3T2DgFc5e2BW+e/ToCawABCBt2dqk5w2g
NpptVxOHZ9qKdNtaUJ1bQK2Pw1oA6bMQRaAxsdSoQ3NYPdTfUGB0Y1VS9NYW
JfE8rgrprlWlQpudW6zuktzjjPUYbQjvx8wFF4LHlEYuWii1d2u5vvLVU2Te
J7epuKK4T0qyU0J/NifuZry45ZDGuRMc1TgZaeBwTc35uN+cb0Ab9O1YK7Iq
uVaQEno+IdsAwilTXOZnqtsUQICYR0stgKXLhlnh3USQnovXGBnLY6vpCaTw
3Kb2JSoj47wWUy+XdPvP4t8pz6ca4Sb9xrAZaV9XpDQ5VrFS5bfYAaW2V2GU
5ALyUfJ8TTPFpmGt2nB1tzdIGKLSbIba8n+2mKgvECELu6+F+AKvg3oRGI7s
xXQbzb6b6n/T1+lusOFNeimlCkhufA2BHAtgS18LzJoHbchmJAW94hocHUHU
hDEpJ2pWNHdCnUxESf9WJ0viAwk2s9gRNEuKumO9FwXjZHSf5btIAaYjLot1
AhMEQvSM+mPDQ7qJ5hbQvmFGju/M9lghc6deQzdQ67XOE2/r7CL6OVdiUMpd
FZ2HLY97+y7bjkkPzpt7Y6jOLOE2ZYyn1RH685dmo2Lw2/fBRRafDxtMjLjt
tW+d0QP5pKczTsCobry7lc6j43cnp6dB9iJWsnAaU0byGZhOl1PqsgnKC6tM
qSf0WI2jaTT+fQx6JkmXGCS8DxDjZ9/jZxwyxU7K+OAjfkTV0NvNCpvm3h9P
7UdBTpD+FGNfscP9cCnYRKbzZbVCdWMrWnGH1BECsHIM7JLqhezbNeTqRRDM
cQIqeKlRe2BZeqZLmAL9DJv0H2RJWCFumLZsnSrN/OzsJ7IZsNmddJ7nuugJ
J9uN8Y2x+DAowJjyF1b200tV60A5YQ4LB/AgUBJYQR0yM1etVypuNomx6dt4
H0WsbIvsu00VG9modDeMNuDcleIkrokSzPNUsHDf7BG2qXeQxpwL4XGn6zAO
4lDW7iDcPQu2WoOWOkSWLB19opdNexWXTCvOsltEGtPoJHbsmu4UMSi0nc02
BNX2mBeecWwnYZtAES4A4si3IPGmnu+JQXglSy4tAQU2f67Z38SWnFjPsm/K
Vn+T929PBZdiJNmeQqUGngVhA0y7SVn1EMDuNHyPGJskYkuCxBZwcvfEtk1q
ySU8F1uPN1jkOhr9dxSIqeBmzz8IGNbnUwU3D85/9qXNMxjdYdUj4jt40kec
R6Gwc2k4Fh0z2cdQn/vB3SRp8iU7UcMrYUP9PezL/LX2OJAy3dmbVJl+we6a
lYBfaRu3qcLpnpcNsH/JmfX1mv1auxuqlejuSOo4vmxDjbKYr7WX3cnv3R01
0j+/bF+Nuo6vtK3B/M4emScptrffDMl020rFhuycT+K9iL4IlStpCkKWXwcJ
0c91ygmWuGbDdeNGfg2Foem5NDJovhtxdN51OhOPJrQf2Ixx5oXkNDbcGOmK
QnXGukQzIeUvawCcgQqTsuTu4hTSQ/KRSJ1zh7BrToyNP1Hvlloi0a79Ckvy
BZaxUuRiTS6Qyuj2x5jQs5ERs+h00XVzNdXSDXhXQccYbduRkLvCcSj3nQhO
swcoEnPUdYuhiCztFjwdCdGujc7QOXWXdBTTvFSZTbX0Hcb8Jjrd9ZXDCXVX
+41OctK7VXEEbQg1AJCqmcjIlcKUqxJD37m/jQob//JAZaTXFi9KPjMeBpmr
ekMlJxgxSSsO+pmiLru9MHl/V5oSWMlw5U5aRAb9bcbCJsfSpxh8IvHq0TgP
7ghW6XKFsW/bKpG6MQX+MrcV+EHC8Z4REArrechUQWcd3HUOpqPm8GRSo7k2
dYvYCPgA0csxLIBsMPO20dTI52UioWFsJts6ArO9q+yA1LvEjEsqt4HjXReV
5jrRnhs7jkms8SsiCMidtIJoZrJsUJplrXBtep9aHqXzupKbmXxRG6IM9LbW
3MGFGmJt8yLfcvwXL0I/iXtrqzCiUe+XLTX89luEAAeCfkOp6wNBP3vyrpNj
L2xBA6VfaIqdO9j+ev9e67um9rqNl4Jmla2YjPUNUOVxJYFoPElxcB/36jvP
VUPa6d3P8KRx699WUd16h15lBadAOUuj0XGMt1mZTri7memEhDHKwpaDTv46
zovxdSNGxBSWpRfi4ar8IvDdXN4khQDa30LXiAW0vp8G86FlrNx+veOCuXcY
fsz4br3v2+wmkkyNk/ubAwqnlekyxWtI0G2pleMNvHywl9zk4ttNKY+i6FiV
gPQ3AEl8kU7gHHOY4E2aXyhg2ec18kv0FoVQOYle4nj6AihO42ejpYmXBgpE
cCOzu/hncGhCEi+K5Wjn8fy5AUH6KsBofz+aRsc/wj8/USp9wl8QKA8P6OER
kv1xwq3Zg7AHLobtYGh7Pi/f9hXirHwY+lZz32Cflcl5qQV9gvR83nwt+UhV
SB+Z4MPXkyk9EVagYQwYfVGLRE2s1uztNRmGBvHbLDBagPPP3KYP/aYpE4F0
lN9e4wtTIi7eo1w/BOb9JuE4KZsuqHr9xA/b2HQdw6SdHYzwvr9hnGwyFTNS
mluX1A00IHy+Am/ETj/QL2YpxmwIb/PrrOQEJ1LCLNUR7rA43dfv61FnXx1p
HwS4Jg6ASQN1wTna0A8VYLjN5Ww6+XcHbqIX/vs4UrqVczfoHuTHHmRLdqSm
eL+e4OjvqS0gV9JLwr4mBVRFt9RblnkSLiMnWdvvlRAxkWDmHBY1cE2NbTfs
xcnur67gGfj1cW89WNjIPSX2x67hs96tu602MfAxxEBAB0XYNsUei8+ClXge
h0LpGzIsa9asBXbXM7WSONolUTPWuiXnkbU7gYaJEzaFhXwcMlqDrBB0R0rd
6DLlkirCc3OijyqnXp8+/YnRSxoQ8NpzHcvj5a5F8Cw3atZp2nH/ZpN8s8J/
Ad5Qrhz1/g0aWtuzGH8ksrKV79TZFD5u3izgnDgBt/CmBMSBFXpQ3pcokRT5
Nz55ZGeSgb3PR+bsKBkjX4UzIUFi2Z37uovFEXcQznNYLdn6whIbUYh9C9Vu
aIGJH5dxXykn/IAbXoF1jx0ttkilpa1Z5BZfMAQzMHD3v6H7ua6ThBXzlUKT
dsGZAl5AfOsFxLP1BrxjCpO6WzlUaESjlCgWBD8mrqpRliaX1+Y84ndxeu4e
D5wmUca4W7Y7a4w+F/x8RAwwy7MuPJ+1Vmneog8s6mxqXv2mq3f/Oq8mEkZf
uQMmHlyG8RlObnIBg76cA2kZZOWU0zd4aZa3v/5RJHKYpme7NAPZsS+p8lbG
WJtTdHhp477wgg/qqdzC+O/BkCxPsmTCb8Og9nSN77AI3+z7IgsLsfsGCzk0
EWrkmHYaHbBOccQ/Znw58DyX2YY+fcFBofDv8MvZ3k5aBkKCUr47CJ5nwAXA
msQHAUsuOpnIoWweU7mWgClp5ijZ6LEc5Eol3KBjDSrLN+ydAg/GZIDPovuI
DsBdjyjfg+VepiYGP0blGnu18fdSYxhskX7Sxm34e8/StxpwgBb4m+cBdth4
RJHgRsCe/YADP2D3CvCcnAMxoSxNZIoO/Ub0Bi5kQt/7B+K8Vpl4Mli09f+h
73iWXH0AAA==

-->

</rfc>