<?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.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-hardt-xauth-protocol-14" category="std" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>The Grant Negotiation and Authorization Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-hardt-xauth-protocol-14"/>
    <author initials="D." surname="Hardt" fullname="Dick Hardt" role="editor">
      <organization>SignIn.Org</organization>
      <address>
        <postal>
          <country>United States</country>
        </postal>
        <email>dick.hardt@gmail.com</email>
      </address>
    </author>
    <date year="2020" month="August" day="15"/>
    <area>Security</area>
    <abstract>
      <t>Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol may be extended on many dimensions.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t><strong>EDITOR NOTE</strong></t>
      <t><em>This document captures a number of concepts that may be adopted by the proposed GNAP working group. Please refer to this document as:</em></t>
      <t><strong>XAuth</strong></t>
      <t><em>The use of GNAP in this document is not intended to be a declaration of it being endorsed by the GNAP working group.</em></t>
      <t>This document describes the core Grant Negotiation and Authorization Protocol (GNAP). The protocol supports the widely deployed use cases supported by OAuth 2.0 <xref target="RFC6749" format="default"/> &amp; <xref target="RFC6750" format="default"/>, OpenID Connect <xref target="OIDC" format="default"/> - an extension of OAuth 2.0, as well as other extensions. Related documents include: GNAP - Advanced Features <xref target="GNAP_Advanced" format="default"/> and JOSE Authentication <xref target="JOSE_Authentication" format="default"/> that describes the JOSE mechanisms for client authentication.</t>
      <t>The technology landscape has changed since OAuth 2.0 was initially drafted. More interactions happen on mobile devices than PCs. Modern browsers now directly support asymetric cryptographic functions. Standards have emerged for signing and encrypting tokens with rich payloads (JOSE) that are widely deployed.</t>
      <t>GNAP simplifies the overall architectural model, takes advantage of today's technology landscape, provides support for all the widely deployed use cases, offers numerous extension points, and addresses many of the security issues in OAuth 2.0 by passing parameters securely between parties rather than via a browser redirection.</t>
      <t>While GNAP is not backwards compatible with OAuth 2.0, it strives to minimize the migration effort.</t>
      <t>The suggested pronunciation of GNAP is "guh-nap".</t>
      <section anchor="the-grant" numbered="true" toc="default">
        <name>The Grant</name>
        <t>The Grant is at the center of the protocol between a client and a server. A Grant Client requests a Grant from a Grant Server. The Grant Client and Grant Server negotiate the Grant. The Grant Server acquires authorization to grant the Grant to the Grant Client. The Grant Server then returns the Grant to the Grant Client.</t>
        <t>The Grant Request may contain information about the User, the Grant Client, the interaction modes supported by the Grant Client, the requested identity claims, and the requested resource access. Extensions may define additional information to be included in the Grant Request.</t>
      </section>
      <section anchor="ProtocolRoles" numbered="true" toc="default">
        <name>Protocol Roles</name>
        <t>There are three roles in GNAP: the Grant Client (GC), the Grant Server (GS), and the Resource Server (RS). Below is how the roles interact:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    +--------+                               +------------+
    | Grant  | - - - - - - -(1)- - - - - - ->|  Resource  |
    | Client |                               |   Server   |
    |  (GC)  |       +---------------+       |    (RS)    |
    |        |--(2)->|     Grant     |       |            |
    |        |<-(3)->|     Server    |- (6) -|            |
    |        |<-(4)--|      (GS)     |       |            |
    |        |       +---------------+       |            |
    |        |                               |            |
    |        |--------------(5)------------->|            |
    +--------+                               +------------+
]]></artwork>
        <t>(1) The GC may query the RS to determine what the RS requires from a GS for resource access. This step is not in scope for this document.</t>
        <t>(2) The GC makes a Grant request to the GS (Create Grant <xref target="CreateGrant" format="default"/>). How the GC authenticates to the GS is not in scope for this document. One mechanism is <xref target="JOSE_Authentication" format="default"/>.</t>
        <t>(3) The GC and GS may negotiate the Grant.</t>
        <t>(4) The GS returns a Grant to the GC (Grant Response <xref target="GrantResponse" format="default"/>).</t>
        <t>(5) The GC accesses resources at the RS (RS Access <xref target="RSAccess" format="default"/>).</t>
        <t>(6) The RS evaluates access granted by the GS to determine access granted to the GC. This step is not in scope for this document.</t>
      </section>
      <section anchor="human-interactions" numbered="true" toc="default">
        <name>Human Interactions</name>
        <t>The Grant Client may be interacting with a human end-user (User), and the Grant Client may need to get authorization to release the Grant from the User, or from the owner of the resources at the Resource Server, the Resource Owner (RO)</t>
        <t>Below is when the human interactions may occur in the protocol:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    +--------+                               +------------+
    |  User  |                               |  Resource  |
    |        |                               | Owner (RO) |
    +--------+                               +------------+
        +     +                             +      
        +      +                           +      
       (A)     (B)                       (C)       
        +        +                       +        
        +         +                     +         
    +--------+     +                   +     +------------+
    | Grant  | - - -+- - - -(1)- - - -+- - ->|  Resource  |
    | Client |       +               +       |   Server   |
    |  (GC)  |       +---------------+       |    (RS)    |
    |        |--(2)->|     Grant     |       |            |
    |        |<-(3)->|     Server    |- (6) -|            |
    |        |<-(4)--|      (GS)     |       |            |
    |        |       +---------------+       |            |
    |        |                               |            |
    |        |--------------(5)------------->|            |
    +--------+                               +------------+

Legend
+ + + indicates an interaction with a human
----- indicates an interaction between protocol roles
]]></artwork>
        <t>Steps (1) - (6) are the same as <xref target="ProtocolRoles" format="default"/>. The addition of the human interactions (A) - (C) are <strong>bolded</strong> below.</t>
        <t><strong>(A) The User is interacting with a GC, and the GC needs resource access and/or identity claims (a Grant)</strong></t>
        <t>(1) The GC may query the RS to determine what the RS requires from a GS for resource access</t>
        <t>(2) The GC makes a Grant request to the GS</t>
        <t>(3) The GC and GS may negotiate the Grant</t>
        <t><strong>(B) The GS may interact with the User for grant authorization</strong></t>
        <t><strong>(C) The GS may interact with the RO for grant authorization</strong></t>
        <t>(4) The GS returns a Grant to the GC</t>
        <t>(5) The GC accesses resources at the RS</t>
        <t>(6) The RS evaluates access granted by the GS to determine access granted to the GC</t>
        <t>Alternatively, the Resource Owner could be a legal entity that has a software component that the Grant Server interacts with for Grant authorization. This interaction is not in scope of this document.</t>
      </section>
      <section anchor="trust-model" numbered="true" toc="default">
        <name>Trust Model</name>
        <t>In addition to the User and the Resource Owner, there are three other entities that are part of the trust model:</t>
        <ul spacing="normal">
          <li>
            <strong>Client Owner</strong> (CO) - the legal entity that owns the Grant Client.</li>
          <li>
            <strong>Grant Server Owner</strong> (GSO) - the legal entity that owns the Grant Server.</li>
          <li>
            <strong>Claims Issuer</strong> (Issuer) - a legal entity that issues identity claims about the User. The Grant Server Owner may be an Issuer, and the Resource Owner may be an Issuer.</li>
        </ul>
        <t>These three entities do not interact in the protocol, but are trusted by the User and the Resource Owner:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +------------+           +--------------+----------+
  |    User    | >> (A) >> | Grant Server |          |
  |            |           | Owner (GSO)  |          | 
  +------------+         > +--------------+          |
        V              /          ^       |  Claims  |
       (B)          (C)          (E)      |  Issuer  |
        V          /              ^       | (Issuer) |
  +------------+ >         +--------------+          |
  |  Client    |           |   Resource   |          |
  | Owner (CO) | >> (D) >> |  Owner (RO)  |          |
  +------------+           +--------------+----------+
]]></artwork>
        <t>(A) User trusts the GSO to acquire authorization before making a grant to the CO</t>
        <t>(B) User trusts the CO to act in the User's best interest with the Grant the GSO grants to the CO</t>
        <t>(C) CO trusts claims issued by the GSO</t>
        <t>(D) CO trusts claims issued by the RO</t>
        <t>(E) RO trusts the GSO to manage access to the RO resources</t>
      </section>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t><strong>Roles</strong></t>
        <ul spacing="normal">
          <li>
            <t><strong>Grant Client</strong> (GC)
            </t>
            <ul spacing="normal">
              <li>may want access to resources at a Resource Server</li>
              <li>may be interacting with a User and want identity claims about the User</li>
              <li>requests the Grant Service to grant resource access and identity claims</li>
            </ul>
          </li>
          <li>
            <t><strong>Grant Server</strong> (GS)
            </t>
            <ul spacing="normal">
              <li>accepts Grant requests from the GC for resource access and identity claims</li>
              <li>negotiates the interaction mode with the GC if interaction is required with the User</li>
              <li>acquires authorization from the User before granting identity claims to the GC</li>
              <li>acquires authorization from the RO before granting resource access to the GC</li>
              <li>grants resource access and identity claims to the GC</li>
            </ul>
          </li>
          <li>
            <t><strong>Resource Server</strong> (RS)
            </t>
            <ul spacing="normal">
              <li>has resources that the GC may want to access</li>
              <li>expresses what the GC must obtain from the GS for access through documentation or an API. This is not in scope for this document</li>
              <li>verifies the GS granted access to the GC, when the GS makes resource access requests</li>
            </ul>
          </li>
        </ul>
        <t><strong>Humans</strong></t>
        <ul spacing="normal">
          <li>
            <t><strong>User</strong>
            </t>
            <ul spacing="normal">
              <li>the person interacting with the Grant Client.</li>
              <li>has delegated access to identity claims about themselves to the Grant Server.</li>
              <li>may authenticate at the GS.</li>
            </ul>
          </li>
          <li>
            <t><strong>Resource Owner</strong> (RO)
            </t>
            <ul spacing="normal">
              <li>the legal entity that owns resources at the Resource Server (RS).</li>
              <li>has delegated resource access management to the GS.</li>
              <li>may be the User, or may be a different entity that the GS interacts with independently.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Reused Terms</strong></t>
        <ul spacing="normal">
          <li>
            <strong>access token</strong> - an access token as defined in <xref target="RFC6749" format="default"/> Section 1.4. An GC uses an access token for resource access at a RS.</li>
          <li>
            <strong>Claim</strong> - a Claim as defined in <xref target="OIDC" format="default"/> Section 5. Claims are issued by a Claims Issuer.</li>
          <li>
            <strong>Client ID</strong> - a GS unique identifier for a Registered Client as defined in <xref target="RFC6749" format="default"/> Section 2.2.</li>
          <li>
            <strong>ID Token</strong> - an ID Token as defined in <xref target="OIDC" format="default"/> Section 2. ID Tokens are issued by the GS. The GC uses an ID Token to authenticate the User.</li>
          <li>
            <strong>NumericDate</strong> - a NumericDate as defined in <xref target="RFC7519" format="default"/> Section 2.</li>
          <li>
            <strong>authN</strong> - short for authentication.</li>
          <li>
            <strong>authZ</strong> - short for authorization.</li>
        </ul>
        <t><strong>New Terms</strong></t>
        <ul spacing="normal">
          <li>
            <strong>GS URI</strong> - the endpoint at the GS the GC calls to create a Grant, and is the unique identifier for the GS.</li>
          <li>
            <strong>Registered Client</strong> - a GC that has registered with the GS and has a Client ID to identify itself, and can prove it possesses a key that is linked to the Client ID. The GS may have different policies for what different Registered Clients can request. A Registered Client MAY be interacting with a User.</li>
          <li>
            <strong>Dynamic Client</strong> - a GC that has not been previously registered with the GS, and each instance will generate it's own asymetric key pair so it can prove it is the same instance of the GC on subsequent requests. The GS MAY return a Dynamic Client a Client Handle for the Dynamic Client to identify itself in subsequent requests. A single-page application with no active server component is an example of a Dynamic Client.</li>
          <li>
            <strong>Client Handle</strong> - a unique identifier at the GS for a Dynamic Client for the Dynamic Client to refer to itself in subsequent requests.</li>
          <li>
            <strong>Interaction</strong> - how the GC directs the User to interact with the GS. This document defines the interaction modes: "redirect", "indirect", and "user_code" in <xref target="InteractionModes" format="default"/>.</li>
          <li>
            <strong>Grant</strong> - the user identity claims and/or resource access the GS has granted to the Client. The GS MAY invalidate a Grant at any time.</li>
          <li>
            <strong>Grant URI</strong>  - the URI that represents the Grant. The Grant URI MUST start with the GS URI.</li>
          <li>
            <strong>Access</strong> - the access granted by the RO to the GC and contains an access token. The GS may invalidate an Access at any time.</li>
          <li>
            <strong>Access URI</strong> - the URI that represents the Access the GC was granted by the RO. The Access URI MUST start with the GS URI. The Access URI is used to refresh an access token.</li>
        </ul>
      </section>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
        <t>Certain security-related terms are to be understood in the sense
defined in <xref target="RFC4949" format="default"/>.  These terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity", "sign",
"signature", "trust", "validate", and "verify".</t>
        <t><em>[Editor: review that the terms listed and used are the same]</em></t>
        <t>Unless otherwise noted, all the protocol parameter names and values
are case sensitive.</t>
        <t>Some protocol parameters are parts of a JSON document, and are referred to in JavaScript notation. For example, <tt>foo.bar</tt> refers to the "bar" boolean attribute in the "foo" object in the following example JSON document:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "foo" : {
        "bar": true
    }
}
]]></artwork>
      </section>
    </section>
    <section anchor="exemplar-sequences" numbered="true" toc="default">
      <name>Exemplar Sequences</name>
      <t>The following sequences are demonstrative of how GNAP can be used, but are just a few of the possible sequences possible with GNAP.</t>
      <t>Before any sequence, the GC needs to be manually or programmatically configured for the GS. See GS Options 
<xref target="GSoptions" format="default"/> for details on programmatically acquiring GS metadata.</t>
      <t>In the sequence diagrams:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
+ + + indicates an interaction with a person
----- indicates an interaction between protocol roles
]]></artwork>
      <section anchor="redirect-interaction" numbered="true" toc="default">
        <name>"redirect" Interaction</name>
        <t>The GC is a web application and wants a Grant from the User containing resource access and identity claims. The User is the RO for the resource:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+                                  +--------+
| Grant  |                                  | Grant  |
| Client |--(1)--- Create Grant ----------->| Server |
|  (GC)  |                                  |  (GS)  |
|        |<--- Interaction Response ---(2)--|        |         +------+
|        |                                  |        |         | User |
|        |+ +(3)+ + Interaction Transfer + +| + + + +|+ + + + >|      |
|        |                                  |        |         |      |
|        |                                  |        |<+ (4) +>|      |
|        |                                  |        |  authN  |      |
|        |                                  |        |         |      |
|        |                                  |        |<+ (5) +>|      |
|        |                                  |        |  authZ  |      |
|        |<+ + Interaction Transfer + +(6)+ | + + + +|+ + + + +|      |
|        |                                  |        |         |      |
|        |--(7)--- Verify Grant ----------->|        |         +------+
|        |                                  |        |
|        |<--------- Grant Response ---(8)--|        |
|        |                                  |        |
+--------+                                  +--------+
]]></artwork>
        <ol spacing="normal" type="1">
          <li>
            <strong>Create Grant</strong> The GC creates a Request JSON document <xref target="RequestJSON" format="default"/> containing an interaction.redirect object, and the requested identity claims and resource access. The GC then makes a Create Grant request (<xref target="CreateGrant" format="default"/>) by sending the JSON with an HTTP POST to the GS URI.</li>
          <li>
            <strong>Interaction Response</strong>  The GS determines that interaction with the User is required and sends an Interaction Response (<xref target="InteractionResponse" format="default"/>) containing the Grant URI and an interaction.redirect object containing the redirect_uri.</li>
          <li>
            <strong>Interaction Transfer</strong> The GC redirects the User to the redirect_uri at the GS.</li>
          <li>
            <strong>User Authentication</strong> The GS authenticates the User.</li>
          <li>
            <strong>User Authorization</strong> If required, the GS interacts with the User (who may also be the RO) to determine the identity claims and resource access in the Grant Request are to be granted.</li>
          <li>
            <strong>Interaction Transfer</strong> The GS redirects the User to the completion_uri at the GC.</li>
          <li>
            <strong>Verify Grant</strong> The GC makes an HTTP PATCH request to the Grant URI passing the verification code (<xref target="VerifyGrant" format="default"/>).</li>
          <li>
            <strong>Grant Response</strong> The GS responds with a Grant Response (<xref target="GrantResponse" format="default"/>).</li>
        </ol>
        <t>The GC can now access the resources at the RS per <xref target="RSA" format="default"/>.</t>
      </section>
      <section anchor="usercode-interaction" numbered="true" toc="default">
        <name>"user_code" Interaction</name>
        <t>A GC is on a device that wants a Grant from the User. The User will interact with the GS using a separate device:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+                                  +--------+
| Grant  |                                  | Grant  |
| Client |--(1)--- Create Grant ----------->| Server |
|  (GC)  |                                  |  (GS)  |
|        |<--- Interaction Response ---(2)--|        |         +------+
|        |                                  |        |         | User |
|        |--(3)--- Read Grant ------------->|        |         |      |
|        |                                  |        |<+ (4) +>|      |
|        |                                  |        |  authN  |      |
|        |                                  |        |         |      |
|        |                                  |        |<+ (5) +>|      |
|        |                                  |        |  code   |      |
|        |                                  |        |         |      |
|        |                                  |        |<+ (6) +>|      |
|        |                                  |        |  authZ  |      |
|        |                                  |        |         |      |
|        |<--------- Grant Response ---(7)--|        |         |      |
|        |                                  |        |         |      |
+--------+                                  |        |         |      |
                                            |        |         |      |
+--------+                                  |        |         |      |
| Client |< + + Information URI Redirect + +| + + + +|+ (8) + +|      |
| Server |                                  |        |         |      |
+--------+                                  +--------+         +------+
]]></artwork>
        <ol spacing="normal" type="1">
          <li>
            <strong>Create Grant</strong> The GC creates a Request JSON document <xref target="RequestJSON" format="default"/> containing an interaction.user_code object and makes a Create Grant request (<xref target="CreateGrant" format="default"/>) by sending the JSON with an HTTP POST to the GS URI.</li>
          <li>
            <strong>Interaction Response</strong>  The GS determines that interaction with the User is required and sends an Interaction Response (<xref target="InteractionResponse" format="default"/>) containing the Grant URI and an interaction.user_code object.</li>
          <li>
            <strong>Read Grant</strong> The GC makes an HTTP GET request to the Grant URI.</li>
          <li>
            <strong>User Authentication</strong> The User loads display_uri in their browser, and the GS authenticates the User.</li>
          <li>
            <strong>User Code</strong> The User enters the code at the GS.</li>
          <li>
            <strong>User Authorization</strong> If required, the GS interacts with the User (who may also be the RO) to determine the identity claims and resource access in the Grant Request are to be granted.</li>
          <li>
            <strong>Grant Response</strong> The GS responds with a Grant Response (<xref target="GrantResponse" format="default"/>).</li>
          <li>
            <strong>Information URI Redirect</strong> The GS redirects the User to the information_uri provided by the GC.</li>
        </ol>
        <t>The GC can now access the resources at the RS per <xref target="RSA" format="default"/>.</t>
      </section>
      <section anchor="independent-ro-authorization" numbered="true" toc="default">
        <name>Independent RO Authorization</name>
        <t>The GC wants access to resources that require the GS to interact with the RO, who is not interacting with the GC. The authorization from the RO may take some time, so the GS instructs the GC to wait and check back later.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+                                  +--------+
| Grant  |                                  | Grant  |
| Client |--(1)--- Create Grant ----------->| Server |
|  (GC)  |                                  |  (GS)  |
|        |<---------- Wait Response ---(2)--|        |         +------+
|  (3)   |                                  |        |         |  RO  |
|  Wait  |                                  |        |<+ (4) +>|      |
|        |                                  |        |  authZ  |      |
|        |--(5)--- Read Grant ------------->|        |         +------+
|        |                                  |        |
|        |<--------- Grant Response --(6)---|        |
|        |                                  |        |
+--------+                                  +--------+
]]></artwork>
        <ol spacing="normal" type="1">
          <li>
            <strong>Create Grant</strong> The GC creates a Grant Request (<xref target="CreateGrant" format="default"/>) and sends it with an HTTP POST to the GS GS URI.</li>
          <li>
            <strong>Wait Response</strong>  The GS sends an Wait Response (<xref target="WaitResponse" format="default"/>) containing the Grant URI and the "wait" attribute.</li>
          <li>
            <strong>GC Waits</strong> The GC waits for the time specified in the "wait" attribute.</li>
          <li>
            <strong>RO AuthZ</strong> The GS interacts with the RO to determine which identity claims and/or resource access in the Grant Request are to be granted.</li>
          <li>
            <strong>Read Grant</strong> The GC does an HTTP GET of the Grant URI (<xref target="ReadGrant" format="default"/>).</li>
          <li>
            <strong>Grant Response</strong> The GS responds with a Grant Response (<xref target="GrantResponse" format="default"/>).</li>
        </ol>
        <t>The GC can now access the resources at the RS per <xref target="RSA" format="default"/>.</t>
      </section>
      <section anchor="RSA" numbered="true" toc="default">
        <name>Resource Server Access</name>
        <t>The GC received an Access URI from the GS. The GC acquires an access token, calls the RS, and later the access token expires. The GC then gets a fresh access token.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+                             +----------+  +--------+
| Grant  |                             | Resource |  | Grant  |
| Client |--(1)--- Access Resource --->|  Server  |  | Server | 
|  (GC)  |<------- Resource Response --|   (RS)   |  |  (GS)  | 
|        |                             |          |  |        | 
|        |--(2)--- Access Resource --->|          |  |        | 
|        |<------- Error Response -----|          |  |        |
|        |                             |          |  |        | 
|        |                             +----------+  |        |
|        |                                           |        |
|        |--(3)--- Read Access --------------------->|        |
|        |<------- Access Response ------------------|        |
|        |                                           |        |
+--------+                                           +--------+
]]></artwork>
        <ol spacing="normal" type="1">
          <li>
            <strong>Resource Request</strong> The GC accesses the RS with the access token per <xref target="RSAccess" format="default"/> and receives a response from the RS.</li>
          <li>
            <strong>Resource Request</strong> The GC attempts to access the RS, but receives an error indicating the access token needs to be refreshed.</li>
          <li>
            <strong>Read Access</strong> The GC makes a Read Access (<xref target="ReadAccess" format="default"/>) with an HTTP GET to the Access URI and receives as Response JSON "access" object (<xref target="ResponseAccessObject" format="default"/>) with a fresh access token.</li>
        </ol>
      </section>
    </section>
    <section anchor="gs-apis" numbered="true" toc="default">
      <name>GS APIs</name>
      <t><strong>GC Authentication</strong></t>
      <t>All GS APIs except for GS Options require the GC to authenticate. Authentication mechanisms include:</t>
      <ul spacing="normal">
        <li>JOSE Authentication <xref target="JOSE_Authentication" format="default"/></li>
        <li>[Others TBD]*</li>
      </ul>
      <section anchor="gs-api-table" numbered="true" toc="default">
        <name>GS API Table</name>
        <table align="center">
          <thead>
            <tr>
              <th align="left">request</th>
              <th align="left">http method</th>
              <th align="left">uri</th>
              <th align="left">response</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Create Grant</td>
              <td align="left">POST</td>
              <td align="left">GS URI</td>
              <td align="left">Interaction, wait, or Grant</td>
            </tr>
            <tr>
              <td align="left">Verify Grant</td>
              <td align="left">PATCH</td>
              <td align="left">Grant URI</td>
              <td align="left">Grant</td>
            </tr>
            <tr>
              <td align="left">Read Grant</td>
              <td align="left">GET</td>
              <td align="left">Grant URI</td>
              <td align="left">wait, or Grant</td>
            </tr>
            <tr>
              <td align="left">Read Access</td>
              <td align="left">GET</td>
              <td align="left">Access URI</td>
              <td align="left">Access</td>
            </tr>
            <tr>
              <td align="left">GS Options</td>
              <td align="left">OPTIONS</td>
              <td align="left">GS URI</td>
              <td align="left">metadata</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="CreateGrant" numbered="true" toc="default">
        <name>Create Grant</name>
        <t>The GC creates a Grant by doing an HTTP POST of a JSON <xref target="RFC8259" format="default"/> document to the GS URI. This is a Grant Request.</t>
        <t>The JSON document MUST include the following from the Request JSON <xref target="RequestJSON" format="default"/>:</t>
        <ul spacing="normal">
          <li>iat</li>
          <li>nonce</li>
          <li>uri - MUST be set to the GS URI</li>
          <li>method - MUST be "POST"</li>
          <li>client</li>
        </ul>
        <t>and MAY include the following from Request JSON <xref target="RequestJSON" format="default"/></t>
        <ul spacing="normal">
          <li>user</li>
          <li>interaction</li>
          <li>access</li>
          <li>claims</li>
        </ul>
        <t>The GS MUST respond with one of Grant Response <xref target="GrantResponse" format="default"/>, Interaction Response <xref target="InteractionResponse" format="default"/>, Wait Response <xref target="WaitResponse" format="default"/>, or one of the following errors:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
        <t>from Error Responses <xref target="ErrorResponses" format="default"/>.</t>
        <t>Following is a non-normative example of a web application GC requesting identity claims about the User and read access to the User's contacts:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Example 1

{ 
    "iat"       : 15790460234,
    "uri"       : "https://as.example/endpoint",
    "method"    : "POST,  
    "nonce"     : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
    "client": {
        "display": {
            "name"  : "SPA Display Name",
            "uri"   : "https://spa.example/about"
        }
    },
    "interaction": {
        "redirect": {
            "completion_uri"    : "https://web.example/return"
        },
        "global" : {
            "ui_locals" : "de"
        }
    },
    "access": [ "read_contacts" ],
    "claims": {
        "oidc": {
            "id_token" : {
                "email"          : { "essential" : true },
                "email_verified" : { "essential" : true }
            },
            "userinfo" : {
                "name"           : { "essential" : true },
                "picture"        : null
            }
        }
    }
}
]]></artwork>
        <t>Following is a non-normative example of a device GC requesting two different access tokens, one request with "oauth_scope", the other with "oauth_rich":</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Example 2

{ 
    "iat"       : 15790460234,
    "uri"       : "https://as.example/endpoint",
    "method"    : "POST,  
    "nonce"     : "5c9360a5-9065-4f7b-a330-5713909e06c6",
    "client": {
        "id"        : "di3872h34dkJW"
    },
    "interaction": {
        "indirect": {
            "information_uri": "https://device.example/c/indirect"
        },
        "user_code": {
            "information_uri": "https://device.example/c/user_code"
         }
    },
    "access": {
        "play_music": [ "play_music" ],
        "read_user_info: [ {
            "type"      : "customer_information",
            "locations" : [ "https://example.com/customers" ],
            "actions"   : [ "read" ],
            "datatypes" : [ "contacts", "photos" ]
        } ]
    }
}
]]></artwork>
      </section>
      <section anchor="VerifyGrant" numbered="true" toc="default">
        <name>Verify Grant</name>
        <t>The GC verifies a Grant by doing an HTTP PATCH of a JSON document to the Grant URI. The GC MUST only verify a Grant once.</t>
        <t>The JSON document MUST include the following from the Request JSON <xref target="RequestJSON" format="default"/>:</t>
        <ul spacing="normal">
          <li>iat</li>
          <li>nonce</li>
          <li>uri - MUST be set to the Grant URI</li>
          <li>method - MUST be PATCH</li>
          <li>interaction.redirection.verification - MUST be the verification code received per <xref target="RedirectVerification" format="default"/>.</li>
        </ul>
        <t>Following is a non-normative example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{ 
    "iat"     : 15790460235,
    "uri"     : "https://as.example/endpoint/grant/example1",
    "method"  : "PATCH,  
    "nonce"   : "9b6afd70-2036-47c9-b953-5dd1fd0c699a",
    "interaction": {
        "redirect": {
            "verification" : "cb4aa22d-2fe1-4321-b87e-bbaa66fbe707"
        }
    }
}
]]></artwork>
        <t>The GS MUST respond with one of Grant Response <xref target="GrantResponse" format="default"/> or one of the following errors:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
      </section>
      <section anchor="ReadGrant" numbered="true" toc="default">
        <name>Read Grant</name>
        <t>The GC reads a Grant by doing an HTTP GET of the corresponding Grant URI. The GC MAY read a Grant until it expires or has been invalidated.</t>
        <t>The GS MUST respond with one of Grant Response <xref target="GrantResponse" format="default"/>, Wait Response <xref target="WaitResponse" format="default"/>, or one of the following errors:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
      </section>
      <section anchor="RequestJSON" numbered="true" toc="default">
        <name>Request JSON</name>
        <ul spacing="normal">
          <li>
            <strong>iat</strong> - the time of the request as a NumericDate.</li>
          <li>
            <strong>nonce</strong> - a unique identifier for this request. Note the Grant Response MUST contain a matching "nonce" attribute value.</li>
          <li>
            <strong>uri</strong> - the URI being invoked</li>
          <li>
            <strong>method</strong> - the HTTP method being used</li>
        </ul>
        <section anchor="client-object" numbered="true" toc="default">
          <name>"client" Object</name>
          <t>The client object MUST only one of the following:</t>
          <ul spacing="normal">
            <li>
              <strong>id</strong> - the Client ID the GS has for a Registered Client.</li>
            <li>
              <strong>handle</strong> - the Client Handle the GS previously provided a Dynamic Client</li>
            <li>
              <t><strong>display</strong> - the display object contains the following attributes:  </t>
              <ul spacing="normal">
                <li>
                  <strong>name</strong> - a string that represents the Dynamic Client</li>
                <li>
                  <strong>uri</strong> - a URI representing the Dynamic Client</li>
              </ul>
            </li>
          </ul>
          <t>The GS will show the the User the display.name and display.uri values when prompting for authorization.</t>
          <t><em>[Editor: a max length for the name and URI so a GS can reserve appropriate space?]</em></t>
        </section>
        <section anchor="interaction-object" numbered="true" toc="default">
          <name>"interaction" Object</name>
          <t>The interaction object contains one or more interaction mode objects per <xref target="InteractionModes" format="default"/> representing the interactions the GC is willing to provide the User. In addition to the interaction mode objects, the interaction object may contain the "global" object;</t>
          <ul spacing="normal">
            <li>
              <t><strong>global</strong> - an optional object containing parameters that are applicable for all interaction modes. Only one attribute is defined in this document:  </t>
              <ul spacing="normal">
                <li>
                  <strong>ui_locales</strong> - End-User's preferred languages and scripts for the user interface, represented as a space-separated list of <xref target="RFC5646" format="default"/> language tag values, ordered by preference. This attribute is OPTIONAL.</li>
              </ul>
            </li>
          </ul>
          <t><em>[Editor: ui_locales is taken from OIDC. Why space-separated and not a JSON array?]</em></t>
        </section>
        <section anchor="RequestUserObject" numbered="true" toc="default">
          <name>"user" Object</name>
          <ul spacing="normal">
            <li>
              <t><strong>identifiers</strong> - The identifiers MAY be used by the GS to improve the User experience. This object contains one or more of the following identifiers for the User:  </t>
              <ul spacing="normal">
                <li>
                  <strong>phone_number</strong> - contains a phone number per Section 5 of <xref target="RFC3966" format="default"/>.</li>
                <li>
                  <strong>email</strong> - contains an email address per <xref target="RFC5322" format="default"/>.</li>
                <li>
                  <strong>oidc</strong> - is an object containing both the "iss" and "sub" attributes from an OpenID Connect ID Token <xref target="OIDC" format="default"/> Section 2.</li>
              </ul>
            </li>
            <li>
              <t><strong>claims</strong> - an optional object containing one or more assertions the GC has about the User.  </t>
              <ul spacing="normal">
                <li>
                  <strong>oidc_id_token</strong> - an OpenID Connect ID Token per <xref target="OIDC" format="default"/> Section 2.</li>
              </ul>
            </li>
          </ul>
        </section>
        <section anchor="AccessObject" numbered="true" toc="default">
          <name>"access" Object</name>
          <t>The GC may request a single Access, or multiple. If a single Access, the "access" object contains an array of <xref target="RAR" format="default"/> objects. If multiple, the "access" object
contains an object where each property name is a unique string created by the GC, and the property value is an array of <xref target="RAR" format="default"/> objects.</t>
        </section>
        <section anchor="ClaimsObject" numbered="true" toc="default">
          <name>"claims" Object</name>
          <t>Includes one or more of the following:</t>
          <ul spacing="normal">
            <li>
              <t><strong>oidc</strong> - an object that contains one or both of the following objects:  </t>
              <ul spacing="normal">
                <li>
                  <strong>userinfo</strong> - Claims that will be returned as a JSON object</li>
                <li>
                  <strong>id_token</strong> - Claims that will be included in the returned ID Token. If the null value, an ID Token will be returned containing no additional Claims.</li>
              </ul>
            </li>
          </ul>
          <t>The contents of the userinfo and id_token objects are Claims as defined in <xref target="OIDC" format="default"/> Section 5.</t>
          <ul spacing="normal">
            <li>
              <strong>oidc4ia</strong> - OpenID Connect for Identity Assurance claims request per <xref target="OIDC4IA" format="default"/>.</li>
            <li>
              <strong>vc</strong> - <em>[Editor: define how W3C Verifiable Credentials  can be requested.]</em><xref target="W3C_VC" format="default"/></li>
          </ul>
        </section>
      </section>
      <section anchor="ReadAccess" numbered="true" toc="default">
        <name>Read Access</name>
        <t>The GC acquires and refreshes an Access by doing an HTTP GET to the corresponding Access URI.</t>
        <t>The GS MUST respond with a Access JSON document <xref target="AccessJSON" format="default"/>, or one of the following errors:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
        <t>from Error Responses <xref target="ErrorResponses" format="default"/>.</t>
      </section>
      <section anchor="GSoptions" numbered="true" toc="default">
        <name>GS Options</name>
        <t>The GC can get the metadata for the GS by doing an HTTP OPTIONS of the corresponding GS URI. This is the only API where the GS MAY respond to an unauthenticated request.</t>
        <t>The GS MUST respond with the the following JSON document:</t>
        <ul spacing="normal">
          <li>
            <strong>uri</strong> - the GS URI.</li>
          <li>
            <strong>client_authentication</strong> - a JSON array of the GC Authentication mechanisms supported by the GS</li>
          <li>
            <strong>interactions</strong> - a JSON array of the interaction modes supported by the GS.</li>
          <li>
            <t><strong>access</strong> - an object containing the access the GC may request from the GS, if any.  </t>
            <ul spacing="normal">
              <li>Details TBD</li>
            </ul>
          </li>
          <li>
            <t><strong>claims</strong> - an object containing the identity claims the GC may request from the GS, if any, and what public keys the claims will be signed with.  </t>
            <ul spacing="normal">
              <li>Details TBD</li>
            </ul>
          </li>
          <li>
            <strong>algorithms</strong> - a JSON array of the cryptographic algorithms supported by the GS. [details TBD]*</li>
          <li>
            <strong>features</strong> - an object containing feature or extension support</li>
        </ul>
        <t>or one of the following errors:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
        <t>from Error Responses <xref target="ErrorResponses" format="default"/>.</t>
      </section>
    </section>
    <section anchor="gs-responses" numbered="true" toc="default">
      <name>GS Responses</name>
      <t>There are three successful responses to a Grant Request: Grant Response, Interaction Response, or Wait Response.</t>
      <section anchor="GrantResponse" numbered="true" toc="default">
        <name>Grant Response</name>
        <t>The Grant Response MUST include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>iat</li>
          <li>nonce</li>
          <li>uri</li>
        </ul>
        <t>and MAY include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>client.handle</li>
          <li>access</li>
          <li>claims</li>
          <li>expires_in</li>
          <li>warnings</li>
        </ul>
        <t>Example non-normative Grant Response JSON document for Example 1 in <xref target="CreateGrant" format="default"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{ 
    "iat"           : 15790460234,
    "nonce"         : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
    "uri"           : "https://as.example/endpoint/grant/example1",
    "expires_in"    : 300
    "access": {
        "mechanism"     : "bearer",
        "token"         : "eyJJ2D6.example.access.token.mZf9p"
        "expires_in"    : 3600,
        "granted"       : [ "read_contacts" ],
    },
    "claims": {
        "oidc": {
            "id_token"      : "eyJhbUzI1N.example.id.token.YRw5DFdbW",
            "userinfo" : {
                "name"      : "John Doe",
                "picture"   : "https://photos.example/p/eyJzdkiO"
            }
        }
    }
}
]]></artwork>
        <t>Note in this example since no Access URI was returned in the access object, the access token can not be refreshed, and expires in an hour.</t>
        <t>Example non-normative Grant Response JSON document for Example 2 in <xref target="CreateGrant" format="default"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"   : 15790460234,
    "nonce" : "5c9360a5-9065-4f7b-a330-5713909e06c6",
    "uri"   : "https://as.example/endpoint/grant/example2",
    "access": {
        "play_music": { "uri"       : "https://as.example/endpoint/access/example2" },
        "read_user_info: { "uri"    " "https://as.example/endpoint/access/"}
    }
}
]]></artwork>
        <t>Note in this example the GS only provided the Access URIs. The GC must acquire the Access per <xref target="ReadAccess" format="default"/></t>
        <t>[Editor: the GC needs to remember if it asked for a single access, or multiple, as there is no crisp algorithm for differentiating between the responses]</t>
      </section>
      <section anchor="InteractionResponse" numbered="true" toc="default">
        <name>Interaction Response</name>
        <t>The Interaction Response MUST include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>iat</li>
          <li>nonce</li>
          <li>uri</li>
          <li>interaction</li>
        </ul>
        <t>and MAY include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>user</li>
          <li>wait</li>
          <li>warnings</li>
        </ul>
        <t>A non-normative example of an Interaction Response follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"       : 15790460234,
    "nonce"     : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
    "uri"       : "https://as.example/endpoint/grant/example4",
    "interaction" : {
        "redirect" : {
            "redirect_uri"     : "https://as.example/i/example4"
        }
    }    
}
]]></artwork>
      </section>
      <section anchor="WaitResponse" numbered="true" toc="default">
        <name>Wait Response</name>
        <t>The Wait Response MUST include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>iat</li>
          <li>nonce</li>
          <li>uri</li>
          <li>wait</li>
        </ul>
        <t>and MAY include the following from the Response JSON <xref target="ResponseJSON" format="default"/></t>
        <ul spacing="normal">
          <li>warnings</li>
        </ul>
        <t>A non-normative example of Wait Response follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "iat"       : 15790460234,
    "nonce"     : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
    "uri"       : "https://as.example/endpoint/grant/example5",
    "wait"      : 300
}
]]></artwork>
      </section>
      <section anchor="ResponseJSON" numbered="true" toc="default">
        <name>Response JSON</name>
        <t>Details of the JSON document:</t>
        <ul spacing="normal">
          <li>
            <strong>iat</strong> - the time of the response as a NumericDate.</li>
          <li>
            <strong>nonce</strong> - the nonce that was included in the Request JSON <xref target="RequestJSON" format="default"/>.</li>
          <li>
            <strong>uri</strong> - the Grant URI.</li>
          <li>
            <strong>wait</strong> - a numeric value representing the number of seconds the GC should want before making a Read Grant request to the Grant URI.</li>
          <li>
            <strong>expires_in</strong> - a numeric value specifying how many seconds until the Grant expires. This attribute is OPTIONAL.</li>
        </ul>
        <section anchor="clientObject" numbered="true" toc="default">
          <name>"client" Object</name>
          <t>If the GC is a Dynamic Client, the GS may return</t>
          <ul spacing="normal">
            <li>
              <strong>handle</strong> the Client Handle</li>
          </ul>
        </section>
        <section anchor="interactionObject" numbered="true" toc="default">
          <name>"interaction" Object</name>
          <t>If the GS wants the GC to start the interaction, the GS MUST return an interaction object containing one or more interaction mode responses per <xref target="InteractionModes" format="default"/> to one or more of the interaction mode requests provided by the GC.</t>
        </section>
        <section anchor="access-object" numbered="true" toc="default">
          <name>"access" Object</name>
          <t>If the GC requested a single Access, the "access" object is an access response object <xref target="ResponseAccessObject" format="default"/>. If the GC requested multiple, the access object contains a property of the same name for each Access requested by the GC, and each property is an access response object <xref target="ResponseAccessObject" format="default"/>.</t>
        </section>
        <section anchor="ResponseAccessObject" numbered="true" toc="default">
          <name>Access Response Object</name>
          <t>The access response object contains properties from the Access JSON <xref target="AccessJSON" format="default"/>. The access response object MUST contain either the "uri" property from, or MUST contain:</t>
          <ul spacing="normal">
            <li>mechanism</li>
            <li>token</li>
          </ul>
          <t>and MAY contain:</t>
          <ul spacing="normal">
            <li>access</li>
            <li>expires_in</li>
            <li>uri</li>
          </ul>
          <t>If there is no "uri" property, the access token can not be refreshed. If only the "uri" property is present, the GC MUST acquire the Access per <xref target="ReadAccess" format="default"/></t>
        </section>
        <section anchor="ResponseClaimsObject" numbered="true" toc="default">
          <name>"claims" Object</name>
          <t>The claims object is a response to the Grant Request "claims" object <xref target="ClaimsObject" format="default"/>.</t>
          <ul spacing="normal">
            <li>
              <t><strong>oidc</strong>  </t>
              <ul spacing="normal">
                <li>
                  <strong>id_token</strong> - an OpenID Connect ID Token containing the Claims the User consented to be released.</li>
                <li>
                  <strong>userinfo</strong> - the Claims the User consented to be released.</li>
              </ul>
              <t>
Claims are defined in <xref target="OIDC" format="default"/> Section 5.</t>
            </li>
            <li>
              <strong>oidc4ia</strong> - OpenID Connect for Identity Assurance claims response per <xref target="OIDC4IA" format="default"/>.</li>
            <li>
              <t><strong>vc</strong>  </t>
              <t>
The verified claims the user consented to be released. <em>[Editor: details TBD]</em></t>
            </li>
          </ul>
        </section>
        <section anchor="WarningsObject" numbered="true" toc="default">
          <name>"warnings" JSON Array</name>
          <t>Includes zero or more warnings from <xref target="Warnings" format="default"/>,</t>
        </section>
      </section>
      <section anchor="AccessJSON" numbered="true" toc="default">
        <name>Access JSON</name>
        <t>The Access JSON is a Grant Response Access Object <xref target="ResponseAccessObject" format="default"/> or the response to a Read Access request by the GC <xref target="ReadAccess" format="default"/>.</t>
        <ul spacing="normal">
          <li>
            <strong>mechanism</strong> - the RS access mechanism. This document defines the "bearer" mechanism as defined in <xref target="RSAccess" format="default"/>. Required.</li>
          <li>
            <strong>token</strong> - the access token for accessing an RS. Required.</li>
          <li>
            <strong>expires_in</strong> - an optional numeric value specifying how many seconds until the access token expires.</li>
          <li>
            <strong>uri</strong> - the Access URI. Used to acquire or refresh Access. Required.</li>
          <li>
            <strong>granted</strong> - an optional array of <xref target="RAR" format="default"/> objects containing the resource access granted</li>
        </ul>
        <t><em>[Editor: would an optional expiry for the Access be useful?]</em></t>
        <t>The following is a non-normative example of Access JSON:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{
    "mechanism"     : "bearer",
    "token"         : "eyJJ2D6.example.access.token.mZf9p"
    "expires_in"    : 3600,
    "uri"           : "https://as.example/endpoint/access/example2",
    "granted"       : [ "read_calendar write_calendar" ]
}
]]></artwork>
      </section>
      <section anchor="response-verification" numbered="true" toc="default">
        <name>Response Verification</name>
        <t>On receipt of a response, the GC MUST verify the following:</t>
        <ul spacing="normal">
          <li>TBD</li>
        </ul>
      </section>
    </section>
    <section anchor="InteractionModes" numbered="true" toc="default">
      <name>Interaction Modes</name>
      <t>This document defines three interaction modes: "redirect", "indirect", and "user_code". Extensions may define additional interaction modes.</t>
      <t>The "global" attribute is reserved in the interaction object for attributes that apply to all interaction modes.</t>
      <section anchor="redirect" numbered="true" toc="default">
        <name>"redirect"</name>
        <t>A Redirect Interaction is characterized by the GC redirecting the User's browser to the GS, the GS interacting with the User, and then GS redirecting the User's browser back to the GC. The GS correlates the Grant Request with the unique redirect_uri, and the GC correlates the Grant Request with the unique completion_uri.</t>
        <t><strong>The request "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>completion_uri</strong>  a unique URI at the GC that the GS will return the User to. The URI MUST not contain the "nonce" from the Grant Request, and MUST not be guessable. This attribute is REQUIRED.</li>
        </ul>
        <t><strong>The response "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>redirect_uri</strong> a unique URI at the GS that the GC will redirect the User to. The URI MUST not contain the "nonce" from the Grant Request, and MUST not be guessable. This attribute is REQUIRED.</li>
          <li>
            <strong>verification</strong> a boolean value indicating the GS requires the GC to make a Verify Grant request.(<xref target="VerifyGrant" format="default"/>)</li>
        </ul>
        <section anchor="RedirectVerification" numbered="true" toc="default">
          <name>"redirect" verification</name>
          <t>If the GS indicates that Grant Verification is required, the GS MUST add a 'verification' query parameter with a value of a unique verification code to the completion_uri.</t>
          <t>On receiving the verification code in the redirect from the GS, the GC makes a Verify Grant request (<xref target="VerifyGrant" format="default"/>) with the verification code.</t>
        </section>
      </section>
      <section anchor="indirect" numbered="true" toc="default">
        <name>"indirect"</name>
        <t>An Indirect Interaction is characterized by the GC causing the User's browser to load the indirect_uri at GS, the GS interacting with the User, and then the GS MAY optionally redirect the User's Browser to a information_uri. There is no mechanism for the GS to redirect the User's browser back to the GC.</t>
        <t>Examples of how the GC may initiate the interaction are encoding the indirect_uri as a code scannable by the User's mobile device, or launching a system browser from a command line interface (CLI) application.</t>
        <t>The "indirect" mode is susceptible to session fixation attacks. See TBD in the Security Considerations for details.</t>
        <t><strong>The request "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>information_uri</strong> an OPTIONAL URI that the GS will redirect the User's browser to after GS interaction.</li>
        </ul>
        <t><strong>The response "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>indirect_uri</strong> the URI the GC will cause to load in the User's browser. The URI SHOULD be short enough to be easily encoded in a scannable code. The URI MUST not contain the "nonce" from the Grant Request, and MUST not be guessable. <em>[Editor: recommend a maximum length?]</em></li>
        </ul>
      </section>
      <section anchor="usercode" numbered="true" toc="default">
        <name>"user_code"</name>
        <t>An Indirect Interaction is characterized by the GC displaying a code and a URI for the User to load in a browser and then enter the code.  <em>[Editor: recommend a minimum entropy?]</em></t>
        <t><strong>The request "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>information_uri</strong> an OPTIONAL URI that the GS will redirect the User's browser to after GS interaction.</li>
        </ul>
        <t><strong>The response "interaction" object contains:</strong></t>
        <ul spacing="normal">
          <li>
            <strong>code</strong> the code the GC displays to the User to enter at the display_uri. This attribute is REQUIRED.</li>
          <li>
            <strong>display_uri</strong> the URI the GC displays to the User to load in a browser to enter the code.</li>
        </ul>
      </section>
    </section>
    <section anchor="RSAccess" numbered="true" toc="default">
      <name>RS Access</name>
      <t>The mechanism the GC MUST use to access an RS is in the Access JSON "mechanism" attribute <xref target="ResponseAccessObject" format="default"/>.</t>
      <t>The "bearer" mechanism is defined in Section 2.1 of <xref target="RFC6750" format="default"/></t>
      <t>The "jose" and "jose+body" mechanisms are defined in <xref target="JOSE_Authentication" format="default"/></t>
      <t>A non-normative "bearer" example of the HTTP request headers follows:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
GET /calendar HTTP/2
Host: calendar.example
Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA
]]></artwork>
    </section>
    <section anchor="ErrorResponses" numbered="true" toc="default">
      <name>Error Responses</name>
      <ul spacing="normal">
        <li>TBD</li>
      </ul>
    </section>
    <section anchor="Warnings" numbered="true" toc="default">
      <name>Warnings</name>
      <t>[Editor: Warnings are an optional response that can assist a GC in detecting non-fatal errors, such as ignored objects and properties.]</t>
      <ul spacing="normal">
        <li>TBD</li>
      </ul>
    </section>
    <section anchor="Extensibility" numbered="true" toc="default">
      <name>Extensibility</name>
      <t>This standard can be extended in a number of areas:</t>
      <ul spacing="normal">
        <li>
          <t><strong>GC Authentication Mechanisms</strong>  </t>
          <ul spacing="normal">
            <li>An extension could define other mechanisms for the GC to authenticate to the GS and/or RS such as Mutual TLS or HTTP Signing. Constrained environments could use CBOR <xref target="RFC7049" format="default"/> instead of JSON, and COSE <xref target="RFC8152" format="default"/> instead of JOSE, and CoAP <xref target="RFC8323" format="default"/> instead of HTTP/2.</li>
          </ul>
        </li>
        <li>
          <t><strong>Grant</strong>  </t>
          <ul spacing="normal">
            <li>An extension can define new objects in the Grant Request and Grant Response JSON that return new URIs.</li>
          </ul>
        </li>
        <li>
          <t><strong>Top Level</strong>  </t>
          <ul spacing="normal">
            <li>Top level objects SHOULD only be defined to represent functionality other the existing top level objects and attributes.</li>
          </ul>
        </li>
        <li>
          <t><strong>"client" Object</strong>  </t>
          <ul spacing="normal">
            <li>Additional information about the GC that the GS would require related to an extension.</li>
          </ul>
        </li>
        <li>
          <t><strong>"user" Object</strong>  </t>
          <ul spacing="normal">
            <li>Additional information about the User that the GS would require related to an extension.</li>
          </ul>
        </li>
        <li>
          <t><strong>"access" Object</strong>  </t>
          <ul spacing="normal">
            <li>RAR is inherently extensible.</li>
          </ul>
        </li>
        <li>
          <t><strong>"claims" Object</strong>  </t>
          <ul spacing="normal">
            <li>Additional claim schemas in addition to OpenID Connect claims and Verified Credentials.</li>
          </ul>
        </li>
        <li>
          <t><strong>interaction modes</strong>  </t>
          <ul spacing="normal">
            <li>Additional types of interactions a GC can start with the User.</li>
          </ul>
        </li>
        <li>
          <t><strong>Continuous Authentication</strong>  </t>
          <ul spacing="normal">
            <li>An extension could define a mechanism for the GC to regularly provide continuous authentication signals and receive responses.</li>
          </ul>
        </li>
      </ul>
      <t><em>[Editor: do we specify access token introspection in this document, or leave that to an extension?]</em></t>
    </section>
    <section anchor="rational" numbered="true" toc="default">
      <name>Rational</name>
      <ol spacing="normal" type="1">
        <li>
          <t><strong>Why do GCs now always use Asymetric cryptography? Why not keep the client secret?</strong>  </t>
          <t>
In the past, asymetric cryptography was relatively computational expensive. Modern browsers now have asymetric cryptographic APIs available, and modern hardware has significantly reduced the computational impact.</t>
        </li>
        <li>
          <t><strong>Why have both Client ID and Client Handle?</strong>  </t>
          <t>
While they both refer to a Grant Client in the protocol, the Client ID refers to a pre-registered client,and the Client Handle is specific to an instance of a Dynamic Client. Using separate terms clearly differentiates which identifier is being presented to the GS.</t>
        </li>
        <li>
          <t><strong>Why allow GC and GS to negotiate the user interaction mode?</strong>  </t>
          <t>
The GC knows what interaction modes it is capable of, and the GS knows which interaction modes it will permit for a given Grant Request. The GC can then present the intersection to the User to choose which one is preferred. For example, while a device based GC may be willing to do both "indirect" and "user_code", a GS may not enable "indirect" for concern of a session fixation attack. Additional interaction modes will likely become available which allows new modes to be negotiated between GC and GS as each adds additional interaction modes.</t>
        </li>
        <li>
          <t><strong>Why have both identity claims and resource access?</strong>  </t>
          <t>
There are use cases for each that are independent: authenticating a user and providing claims vs granting access to a resource. A request for an authorization returns an access token which may have full CRUD capabilities, while a request for a claim returns the claim about the User - with no create, update or delete capabilities. While the UserInfo endpoint in OIDC may be thought of as a resource, separating the concepts and how they are requested keeps each of them simpler in the Editor's opinion. :)</t>
        </li>
        <li>
          <t><strong>Why do some of the JSON objects only have one child, such as the identifiers object in the user object in the Grant Request?</strong>  </t>
          <t>
It is difficult to forecast future use cases. Having more resolution may mean the difference between a simple extension, and a convoluted extension. For example, the "global" object in the "interaction" object allows new global parameters to be added without impacting new interaction modes.</t>
        </li>
        <li>
          <t><strong>Why is the "iss" included in the "oidc" identifier object? Would the "sub" not be enough for the GS to identify the User?</strong>  </t>
          <t>
This decouples the GS from the OpenID Provider (OP). The GS identifier is the GS URI, which is the endpoint at the GS. The OP issuer identifier will likely not be the same as the GS URI. The GS may also provide claims from multiple OPs.</t>
        </li>
        <li>
          <t><strong>Why is there not a UserInfo endpoint as there is with OpenID Connect?</strong>  </t>
          <t>
Since the GC can Read Grant at any time, it get the same functionality as the UserInfo endpoint, without the GC having to manage a separate access token and refresh token. If the GC would like additional claims, it can Update Grant, and the GS will let the GC know if an interaction is required to get any of the additional claims, which the GC can then start.  </t>
          <t><em>[Editor: is there some other reason to have the UserInfo endpoint?]</em></t>
        </li>
        <li>
          <t><strong>Why use URIs for the Grant and Access?</strong>  </t>
          <ul spacing="normal">
            <li>Grant URI and Access URI are defined to start with the GS URI, allowing the GC, and GS to determine which GS a Grant or Access belongs to.</li>
            <li>URIs also enable a RESTful interface to the GS functionality.</li>
            <li>A large scale GS can easily separate out the services that provide functionality as routing of requests can be done at the HTTP layer based on URI and HTTP method. This allows a separation of concerns, independent deployment, and resiliency.</li>
          </ul>
        </li>
        <li>
          <t><strong>Why use the OPTIONS method on the GS URI? Why not use a .well-known mechanism?</strong>  </t>
          <t>
Having the GS URI endpoint respond to the metadata allows the GS to provide GC specific results using the same GC authentication used for other requests to the GS. It also reduces the risk of a mismatch between the advertised metadata, and the actual metadata. A .well-known discovery mechanism may be defined to resolve from a hostname to the GS URI.</t>
        </li>
        <li>
          <t><strong>Why is there a Verify Grant? The GC can protect itself from session fixation without it.</strong>  </t>
          <t>
GC implementations may not always follow the best practices. The Verify Grant allows the GS to ensure there is not a session fixation as the instance of the GC making creating the Grant is the one that gets the verification code in the redirect.</t>
        </li>
        <li>
          <t>**Why use the <xref target="OIDC" format="default"/> claims rather than the <xref target="IANA_JWT" format="default"/> list of claims?  </t>
          <t>
The <xref target="IANA_JWT" format="default"/> claims include claims that are not identity claims, and <xref target="IANA_JWT" format="default"/> references the <xref target="OIDC" format="default"/> claims, and <xref target="OIDC" format="default"/> 5.1 are only identity claims.</t>
        </li>
      </ol>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>This draft derives many of its concepts from Justin Richer's Transactional Authorization draft <xref target="TxAuth" format="default"/>.</t>
      <t>Additional thanks to Justin Richer and Annabelle Richard Backman for their strong critique of earlier drafts.
[Editor: add in the other contributors from mail list]</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC3966" target="https://www.rfc-editor.org/info/rfc3966" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3966.xml">
          <front>
            <title>The tel URI for Telephone Numbers</title>
            <seriesInfo name="DOI" value="10.17487/RFC3966"/>
            <seriesInfo name="RFC" value="3966"/>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <date year="2004" month="December"/>
            <abstract>
              <t>This document specifies the URI (Uniform Resource Identifier) scheme "tel".  The "tel" URI describes resources identified by telephone numbers.  This document obsoletes RFC 2806.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5322" target="https://www.rfc-editor.org/info/rfc5322" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
          <front>
            <title>Internet Message Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC5322"/>
            <seriesInfo name="RFC" value="5322"/>
            <author initials="P." surname="Resnick" fullname="P. Resnick" role="editor">
              <organization/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4949" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml">
          <front>
            <title>Internet Security Glossary, Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC4949"/>
            <seriesInfo name="RFC" value="4949"/>
            <seriesInfo name="FYI" value="36"/>
            <author initials="R." surname="Shirey" fullname="R. Shirey">
              <organization/>
            </author>
            <date year="2007" month="August"/>
            <abstract>
              <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml">
          <front>
            <title>Tags for Identifying Languages</title>
            <seriesInfo name="DOI" value="10.17487/RFC5646"/>
            <seriesInfo name="RFC" value="5646"/>
            <seriesInfo name="BCP" value="47"/>
            <author initials="A." surname="Phillips" fullname="A. Phillips" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Davis" fullname="M. Davis" role="editor">
              <organization/>
            </author>
            <date year="2009" month="September"/>
            <abstract>
              <t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document  specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <seriesInfo name="DOI" value="10.17487/RFC6749"/>
            <seriesInfo name="RFC" value="6749"/>
            <author initials="D." surname="Hardt" fullname="D. Hardt" role="editor">
              <organization/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6750" target="https://www.rfc-editor.org/info/rfc6750" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml">
          <front>
            <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
            <seriesInfo name="DOI" value="10.17487/RFC6750"/>
            <seriesInfo name="RFC" value="6750"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="D." surname="Hardt" fullname="D. Hardt">
              <organization/>
            </author>
            <date year="2012" month="October"/>
            <abstract>
              <t>This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources.  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
          <front>
            <title>JSON Web Token (JWT)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7519"/>
            <seriesInfo name="RFC" value="7519"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <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>
        </reference>
        <reference anchor="OIDC" target="https://openiD.net/specs/openiD-connect-core-1_0.html">
          <front>
            <title>OpenID Connect Core 1.0</title>
            <author initials="N." surname="Sakimora">
              <organization/>
            </author>
            <author initials="J." surname="Bradley">
              <organization/>
            </author>
            <author initials="M." surname="Jones">
              <organization/>
            </author>
            <author initials="B." surname="de Medeiros">
              <organization/>
            </author>
            <author initials="C." surname="Mortimore">
              <organization/>
            </author>
            <date year="2014" month="November"/>
          </front>
        </reference>
        <reference anchor="OIDC4IA" target="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html">
          <front>
            <title>OpenID Connect for Identity Assurance 1.0</title>
            <author initials="T." surname="Lodderstedt">
              <organization/>
            </author>
            <author initials="D." surname="Fett">
              <organization/>
            </author>
            <date year="2019" month="October"/>
          </front>
        </reference>
        <reference anchor="RAR" target="https://tools.ietf.org/html/draft-ietf-oauth-rar-00">
          <front>
            <title>OAuth 2.0 Rich Authorization Requests</title>
            <author initials="T." surname="Lodderstedt">
              <organization/>
            </author>
            <author initials="J." surname="Richer">
              <organization/>
            </author>
            <author initials="B." surname="Campbell">
              <organization/>
            </author>
            <date year="2020" month="January"/>
          </front>
        </reference>
        <reference anchor="W3C_VC" target="https://w3c.github.io/vc-data-model/">
          <front>
            <title>Verifiable Credentials Data Model 1.0</title>
            <author initials="M." surname="Sporny">
              <organization/>
            </author>
            <author initials="G." surname="Noble">
              <organization/>
            </author>
            <author initials="D." surname="Chadwick">
              <organization/>
            </author>
            <date year="2019" month="November"/>
          </front>
        </reference>
        <reference anchor="JOSE_Authentication" target="https://tools.ietf.org/html/draft-hardt-gnap-jose">
          <front>
            <title>JOSE Authentication</title>
            <author initials="D." surname="Hardt">
              <organization/>
            </author>
            <date year="2020" month="June"/>
          </front>
        </reference>
        <reference anchor="GNAP_Advanced" target="https://tools.ietf.org/html/draft-hardt-gnap-advanced">
          <front>
            <title>The Grant Negotiation and Authorization Protocol - Advanced Features</title>
            <author initials="D." surname="Hardt">
              <organization/>
            </author>
            <date year="2020" month="June"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7049" target="https://www.rfc-editor.org/info/rfc7049" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7049"/>
            <seriesInfo name="RFC" value="7049"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <date year="2013" month="October"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.  These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8152"/>
            <seriesInfo name="RFC" value="8152"/>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization/>
            </author>
            <date year="2017" month="July"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <seriesInfo name="DOI" value="10.17487/RFC8323"/>
            <seriesInfo name="RFC" value="8323"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="S." surname="Lemay" fullname="S. Lemay">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization/>
            </author>
            <author initials="B." surname="Silverajan" fullname="B. Silverajan">
              <organization/>
            </author>
            <author initials="B." surname="Raymor" fullname="B. Raymor" role="editor">
              <organization/>
            </author>
            <date year="2018" month="February"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
              <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="browser_based_apps" target="https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04">
          <front>
            <title>OAuth 2.0 for Browser-Based Apps</title>
            <author initials="A." surname="Parecki">
              <organization/>
            </author>
            <author initials="D." surname="Waite">
              <organization/>
            </author>
            <date year="2019" month="September"/>
          </front>
        </reference>
        <reference anchor="QR_Code" target="https://www.iso.org/standard/62021.html">
          <front>
            <title>ISO/IEC 18004:2015 - Information technology - Automatic identification and data capture techniques - QR Code bar code symbology specification</title>
            <author>
              <organization/>
            </author>
            <date year="2015" month="February"/>
          </front>
        </reference>
        <reference anchor="TxAuth" target="https://tools.ietf.org/html/draft-richer-transactional-authz-04">
          <front>
            <title>Transactional AuthN</title>
            <author initials="J." surname="Richer">
              <organization/>
            </author>
            <date year="2019" month="December"/>
          </front>
        </reference>
        <reference anchor="IANA_JWT" target="https://www.iana.org/assignments/jwt/jwt.xhtml">
          <front>
            <title>JSON Web Token Claims</title>
            <author>
              <organization/>
            </author>
            <date year="2015" month="January"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="document-history" numbered="true" toc="default">
      <name>Document History</name>
      <section anchor="draft-hardt-xauth-protocol-00" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-00</name>
        <ul spacing="normal">
          <li>Initial version</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-01" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-01</name>
        <ul spacing="normal">
          <li>text clean up</li>
          <li>added OIDC4IA claims</li>
          <li>added "jws" method for accessing a resource.</li>
          <li>renamed Initiation Request -&gt; Grant Request</li>
          <li>renamed Initiation Response -&gt; Interaction Response</li>
          <li>renamed Completion Request -&gt; Authorization Request</li>
          <li>renamed Completion Response -&gt; Grant Request</li>
          <li>renamed completion handle -&gt; authorization handle</li>
          <li>added Authentication Request, Authentication Response, authentication handle</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-02" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-02</name>
        <ul spacing="normal">
          <li>major rewrite</li>
          <li>handles are now URIs</li>
          <li>the collection of claims and authorizations are a Grant</li>
          <li>an Authorization is its own type</li>
          <li>lots of sequences added</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-03" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-03</name>
        <ul spacing="normal">
          <li>fixed RO definition</li>
          <li>improved language in Rationals</li>
          <li>added user code interaction method, and aligned qrcode interaction method</li>
          <li>added information_uri for code flows</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-04" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-04</name>
        <ul spacing="normal">
          <li>renamed interaction uris to have purpose specific names</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-05" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-05</name>
        <ul spacing="normal">
          <li>separated claims from identifiers in request user object</li>
          <li>simplified reciprocal grant flow</li>
          <li>reduced interactions to redirect and indirect</li>
          <li>simplified interaction parameters</li>
          <li>added in language for Client to verify interaction completion</li>
          <li>added Verify Grant API and Interaction Nonce</li>
          <li>replaced Refresh AuthZ with Read AuthZ. Read and refresh are same operation.</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-06" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-06</name>
        <ul spacing="normal">
          <li>fixup examples to match specification</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-07" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-07</name>
        <ul spacing="normal">
          <li>refactored interaction request and response syntax, and enabled interaction mode negotiation</li>
          <li>generation of client handle by GS for dynamic clients</li>
          <li>renamed title to Grant Negotiation and Authorization Protocol. Preserved draft-hardt-xauth-protocol filename to ease tracking changes.</li>
          <li>changed Authorizations to be key / value pairs (aka dictionary) instead of a JSON array</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-08" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-08</name>
        <ul spacing="normal">
          <li>split document into three documents: core, advanced, and JOSE authentication.</li>
          <li>grouped access granted into "access" object in Authorization JSON</li>
          <li>added warnings object to the Grant Response JSON</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-09" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-09</name>
        <ul spacing="normal">
          <li>added editorial note that this document should be referred to as XAuth</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-10" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-10</name>
        <ul spacing="normal">
          <li>added example of RAR authorization request</li>
          <li>fixed typos</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-11" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-11</name>
        <ul spacing="normal">
          <li>renamed authorization_uri to interaction_uri to avoid confusion with AZ URI</li>
          <li>
            <t>made URI names more consistent
            </t>
            <ul spacing="normal">
              <li>renamed completion_uri to information_uri</li>
              <li>renamed redirect_uri to completion_uri</li>
              <li>renamed interaction_uri to redirect_uri</li>
              <li>renamed short_uri to indirect_uri</li>
            </ul>
          </li>
          <li>editorial fixes</li>
          <li>renamed http verb to method</li>
          <li>added Verify Grant and verification parameters</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-12" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-12</name>
        <ul spacing="normal">
          <li>removed authorization object, and made authorizations object polymorphic</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-13" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-13</name>
        <ul spacing="normal">
          <li>added Q about referencing OIDC claims vs IANA JWT</li>
          <li>made all authorizations be a RAR type as it provides the required flexibility, removed "oauth_rar" type</li>
          <li>added RO to places where the RO and User are the same</li>
        </ul>
      </section>
      <section anchor="draft-hardt-xauth-protocol-14" numbered="true" toc="default">
        <name>draft-hardt-xauth-protocol-14</name>
        <ul spacing="normal">
          <li>rewrote introduction</li>
          <li>add in claims issuer and grant server owner</li>
          <li>abstract protocol</li>
          <li>add clarification on different parties</li>
          <li>renamed Client to Grant Client</li>
          <li>added entity relationship diagram</li>
          <li>updated diagrams</li>
          <li>added placeholder for Privacy Considerations</li>
          <li>renamed Authorization to Access</li>
        </ul>
      </section>
    </section>
    <section anchor="comparison-with-oauth-20-and-openid-connect" numbered="true" toc="default">
      <name>Comparison with OAuth 2.0 and OpenID Connect</name>
      <t><strong>Changed Features</strong></t>
      <t>The major changes between GNAP and OAuth 2.X and OpenID Connect are:</t>
      <ul spacing="normal">
        <li>The OAuth 2.X client and the OpenID Connect replying party are the Grant Client in GNAP.</li>
        <li>The GNAP Grant Server is a superset of the OAuth 2.X authorization server, and the OpenID Connect OP (OpenID Provider).</li>
        <li>The GC always uses a private asymetric key to authenticate to the GS. There is no client secret.</li>
        <li>The GC initiates the protocol by making a signed request directly to the GS instead of redirecting the User to the GS.</li>
        <li>The GC does not pass any parameters in redirecting the User to the GS.</li>
        <li>The refresh_token has been replaced with an AZ URI that both represents the authorization, and is the URI for obtaining a fresh access token.</li>
        <li>The GC can request identity claims to be returned independent of the ID Token.</li>
        <li>The GS URI is the only static endpoint. All other URIs are dynamically generated. The GC does not need to register it's redirect URIs.</li>
      </ul>
      <t>TBD - negotiation</t>
      <t><strong>Preserved Features</strong></t>
      <ul spacing="normal">
        <li>GNAP reuses the scopes, Client IDs, and access tokens of OAuth 2.0.</li>
        <li>GNAP reuses the Client IDs, Claims and ID Token of OpenID Connect.</li>
        <li>No change is required by the GC or the RS for accessing existing bearer token protected APIs.</li>
      </ul>
      <t><strong>New Features</strong></t>
      <ul spacing="normal">
        <li>All GC calls to the GS are authenticated with asymetric cryptography</li>
        <li>A Grant represents both the user identity claims and RS access granted to the GC.</li>
        <li>Support for scannable code initiated interactions.</li>
        <li>Highly extensible per <xref target="Extensibility" format="default"/>.</li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIACRlOF8AA+19aXPbRrbod/4KFF31ItsirV223lTyZMpx5EokjyhP5s7c
eb4g0SQRgQAHACUzsv/7PVtvALjIdjK5t0ZTE5Mgejt9+uzndKfTaUXZMA2n
6iSI8nBUdiZhHpWdD+G8nHRmeVZmwyzp7B60yrhM4KXriQpe52FaBhdqnJVx
WMZZGoRpFJxCiyyPf+Unb6VpKwpLaLa3s7fT2Xne2T1sDeHBOMsXJ0FRRq14
lp8EZT4vyr2dnRc7e60wV+FJ0FfDeR6Xi9YwSwuVFvOC3lKtVkjDnLQC+ItT
eHzWDX7AOdOTLB+HqcwBeonH6XnavczH9GOe4QpUFJdZTg943Wfx8MbpQk3D
OAFowNMuAeP/jfFJd5hN6fdhNk9LnP67NC5VFPRLWFDRaqVZPoVxb9VJC967
+r63t7v74oQ/7r84OpKPh/t7e/Lx4MWBfuHw6EC/cHRsnh4dH+7Ix+ND09nz
vcMXNMbl+VmPASGbczlT6flZ0MvSVA1L+DdXwW53h18J87EqT4JJWc6Kk2fP
Mng3PuumqnxWzNSwkAedITeGf3PV2X2/052U04R64J28yG7VdKDy4Pk27Cog
Bv7kbkoQdORf2aCLbtAPb+JplofNL7zpBi/zMErUovn3n7rBmywFGDf++rIb
RCr4SUUqzrMl7/S6wU9ZXuIclIbcwfnpKuCNsjw4j1QKvy6C06KYA9IP14Az
qoIzMuA86MTSWSfUnTWB93JYZgjd3UMC74v14L3uBj9mUaTyArCxbH4Hzsj3
qsQfEYVOr/yF48kN9ro7wVU8nFTO8ZX651wVZRE0rrrMsqToxqocdeHkPcO1
PGMygs86GVGRPMw7OzvOGt+E6TzMF8He7jYRhq+zRsAinL/Kl6JJL5zOBipJ
EAN+3u8Ff/FPz19UHo/icJCooJcr2q0wKYKzsAwBeyKVLN38u/1hdxyXk/mg
G2fPbocdWGfYmWKbZ01HZ+9o+eYGNdzvz7I8XSz5/XUXuoUpL/kZNr43CaM7
IGa46jeX/Ve0wbi4IVNJFwQNvz9045l/jNNw1vklK5S77fNUBUebbrkh6/D4
9cXp2+A0usVDE3kTfig7AgDpfuBEhOU8Vw9GbWeFofRVXeXxw1cZp6MqAzne
MZzg+e6h5hrP9/f26Y1Bnt0VgE2DsIDVhDOYdvOxRlL2kl/uvKSXT+HlLzjR
MnKHRu7gyJ2dAwcGfTUrBdP3NiVjp93gLfD+4U28FFI/h8Bw8UELl//nK6DV
kfLWfN6/fHb+qhfsPt/ZOTiBgQ9hw881ZAEPSjWcpFmSjReICfMyw+fDgGnz
SKM84g8e4WAYzhBFuFmMlBCaycAA9xyEAfhQLKYD7hNJv+mmmVTc3XXjIiPg
FiUMBLv/7AiQZbfKCb5Xg5zIJFFJEJzgt+sPuKn+CQDsL8IhDhgmhPUXD9zY
nKhmp3Q76uBe/erv6pka8qbu7m+6qVWaTPzn/PTiNHjz87VPefqXF8HPahBc
ZzcqDXpJGE+L5RAM05CWAbwUZLwp7F7x7Je7Ev/f/VABpGE3+xqQnU4nCAcF
rBgYfavVS2LoICiyUXkHKBjAvzCFSBUxUgf4fzbPh/AJjpFm4sGQJhiUk7AM
sE2cRgo4Pv4M7eG5glew2y7QqLgItCgdhEkChycIgzmeXUCAZ9CtHiPI7lJ4
WmYweqLGMH37U+gRNNMwUXAIccja1DIYBMa4VTkwgcoSh2GKc0yhA+LvQTiE
FVIju14Zo9rxAD7BKuJ0TMvUQ1ybz9DZP+cEO5beSzpQ/vxHeTal5ivAEI9o
etBTtE1dyIzhSKY0VQtluzJ8VgNV877dKXgfqFcOfDmq7tM0XAQDFagPJe5q
FEBH0zBdgF4A2FZAv0WXEWkaRyC6tlqPgNCUeRbN6QgBiXry5NXZ+fXlVXBx
ef3qyRN4QCOAvjVHhNXEBXEhndPBgl0EiA2BesoMZRJhlM1Q1QDI4/JgjrMM
yTjxxbssv8G9GOfZfAZElBEiVyNGpNIbMyxOngQ4tb8ipZBJ0Sbg4NRfnFba
wOc0g39SgQR0inMCFAVg5gxjxL8SHuNE4K0sL+x0G2aJc2j50IDjNszjgSp4
V1F1eRBj38JhHjMamk0s5jMQnkru8w6QIIENVLMkW8D0cNFDgFWhX+MpW755
fy/q2KdPwf/R3w53Pn3arioL9/eoUcBrQFdSxplCwGK6AxQuAOWSBP/NYEK5
fbEAOqmSEGegAVIAwIfJHBgcA7BJcLm/9yQjGB8B1CTE3d83PIX3Cct80NOL
U2B4oEgXcFRQepBDFnrNuwHuoXJ5agLjF4DXKpjAIrGLMcy3iFFzsnC9C3Fx
MYrXuB/IhPD8/ZQRHS1VzlyogE5mAGc6etkgBrk8UrfxkOYJYH7bK7okmOep
loUQU+/giIIcUULXsq8A8MVUlcDngmG+mJXZOA9nE/g2mqc8Uhe1eOLFOOgt
HPupynHquHjkMIi6CFuVUg9E+5BRwY6C3B8gCw1m4SLJQuhhC0H42PKGCuIB
3aBtK+LpLAFpQeAORCgPETvy4QTknCFsMTB0UiK2gQneIKHAjS7DMR3WMovC
xTdFI/i38QjcwrAGt2kl2P3Kk7ANHY8IjICDcFILB5dnGexNwYQ4jCLAPzw6
RBOF4RVitAGKUaCoBJTEbjqcrBlya4DcDKgG7AeOQ01wLgNV3inYa/itRIgA
XcETQht9G4dAbrS4C9yA9lcw8OcJIgZTLiZUg3B4c0dbOcymM0BV1Ohom5yz
CNQK+D8I28RIpoCO0/hX5h7TeCxUTY0AamWX0byYj8cK9U+EbQqYExvSp0dv
j+eTDugFbZzYo0dWO+EemJ7Be4AXROQUIruGniFaGhShOXYIccNnT6UfYem5
VtBDeU6cVX/pO8zZa4Z9uq8EqZBZhgH95DbrVzi7z2IBhGN6zbTV7NkdtKE/
n6OvbuwCUcwSxCCBZZYh4FrsyPnhIJvzbN4B3LZrvfETh9jQQatwguZGAnBV
EyqMjOK8YqU3kq+6wStD8mnukRrFKTL4KBYJ3l0Fc1rhAxFz5goEuoRohgte
ZQnyhUf6AX3/RJBDWYfko1wpMoXSAUXUPamtFLhp77ELNdmurdf9x3aZV3px
+terPjDglwoEXMTyCfxD0JCxGNakuvLf0478PQ1W/5kX6WXT/qNMDj503P9t
7T72vn/7MbBzDT467WW1H9eMj7/LGv32BKfAtPfm6ayLfkfoBNX28qHT2dp7
TPOEP1mU84I3v6b2f+ps7Zv2ZqbQb7B19DjobNL+4HFHv4e7/LDxN1n/Bu2X
/a1t7w+7dfjY+/7tkvafi38tQDAmZT06xHAQc6YWV33W3QDVp3iu7yZC6uEH
UWUKQ6D7xJNrFILEYiAeMyt4B8UwA5kKX/dEczj8gDd2KiQjCP5oxU6T0n6w
1csV0nf+/f6ev9K3T5/g4P4g5xW6cgQ9VThdrJ9RcAnLNtIjNlgieiI9B6TV
kyd+1CdwNnIiePlAXu4bhhFW2EUPUFeIYzFD1RMlZHygv+M6oadDOywB3dPy
7Y7BiQ1OWS8G4b/PHwlU0McR9wGvqNswmROgRIkmVuiwkApSVN4yk3/Y1rOE
8cMcBDBUPI3Q7HJJIW+iRRpuByIYiUNhMKHmoLB1SA3fQmbpEPhaL6niCY9V
WZcAtC3CtjRKPjNhWIN5whq+iD514PucZdt/eEltt64uH7dahtvcoSSBr/Ga
PD0Cp54NQdLULFTLWl+VGdEqNyJmzcyo+mFpe7v+r0DMvJ+c/y5tzv80tFvZ
sKHZ1ilzma2Xj5c02urpX5qGWz6ged7cbEk7+3QZUJvaPfVfXC2hPK1JKE8f
JqFUZ+By2H9LKCvab7L+Ddov+/ujSSj47Ec1BspOH5/S/+I0Eo7uE0iPG9D7
1M3y942yrtUOEvFbrVYfeFcRoHjE+6oNsgXo+2j2ur/3FZNPrBJq9UfzgwYS
jsSiQwQB+3zyZJAloBI9eQJzAQbQRZMmvnItzAY5QgO/e91zmFuP2FlRlcCW
mb23RNp4jFbT31ACfIhM9wARiiD00ohQ+JYGEENH82maE2vzHosnY/ET3IGV
XVxdrupgEyFuYwHtN5HCAItPE3gpJVdssmiUPYbZPInYCo5umiQQVCGTH5o+
Q8fVkk1B9lRkHAldC4lQQQ1CMSUi8F7XgSfCoXsKqzIiHR5fOyAjFAZXcQBD
q3We2sMmS34nDpiGddLaPbuB2K1xtWy3FBMnmu306aVoLjZcgnzVgcMqTIz6
hCO71bvEw4zv1qEHgqFrCRLjD3Xjgc109rq/eW9iDpNJ0bE+R1sldcSfsK+m
XdU2zQpV8A1NDRYuRhjtyEllvAYjSvOLbHwsNPwN5KPMOGXo/FUE2+1gMOed
od2wx2DFbp+0tDTsc5NlbAZ+qss8xMhYEMYv335LlBv++eiDxWF4H92mTQzV
SLy01V7TYPWMv63NuInL4t9ffH76zH78/3ZGgjJ+U098tRIrfnn12DTl3Vwx
6rPA+7OjGrz82LzWb02b9WulNdBZDKogdgXQ5t2RTcDDyxt7JhvrKiRNTT8L
nVqIN4RIhMFyivuX5NdmK3RFBR2oEXqQgGWSt0ZbpJnK9S6hx5f1HnvSoTlB
+MI3BXRWyOnCD4a7vbZWbpgKjVB4Q8D+Y5c8gNAIIh0OI7pE+8HZ2hev6D3A
oavLBhiAhISOIOu3lyaGTwr1J3ZH7iFk3yR2ISO29JQRgigpTJ7FPyJDd8SE
muIC4HFVRXfaNZsaDOGhbleTUenMuDZ8Ah7DoMbh0CC8VTtv1ZgHsw2zWGyK
LndPyCqsrQLEkAY5rXEo7tCIX0Wjm8FBpx4GOVSYuo558MUyM9dGB4xnadEn
gSCEW9AQGiLCzmadAlpVu6wCo9qlHI0NYOaKXrhRFcTCvbqye4XClcVEK1H1
LMrSeSZJmpuoDzNxVt65r6OQkg3Ic2R3miVyvaZJns3HEyNQib8P0Tg4fXuu
RbJ1pjqZxi2Flyp9iI3kWQXgtjVlkZB9o+pg1DiKR5pMgHCmAwYfIgB+4UFJ
JlB5kaX1M1n3sLlA1gFI7gSXntppoZJbx1LsCVuWMrhmZS3Gv+53K/tuJDvk
J846lkh364yH7JZqXFkVrExTKRzFqFjdwCdtnjlTS2tBFKPfHBu689NWc1/C
d0LFkkWXAoWu1BwDZpBYG+pswH6jQHXiyBL3WUBLQfcheQbdYJU+u8eD3e5B
NzhNEd3nBavxXg+NVI2Iu94Uknh4dJZ+aqNK4Ise8rCrpSSKijMMLQw8ebsb
eJrB+ZmMAdCaU6ClCckUhRQZzjgukB9Hxoe9FgB73T1ZyPkZRxZqSOrv69az
1zWvVpek8UM0VQ1h0zPSIRfhjZLAM7rAEIt4eAY/yeKdJ01rwxQQb2aCJxjy
ST0UExPo4Qfq2Bf/1vCi1TERFS/UnY+HsCXvrs6pHa4AEJciQez51RQVgwKJ
BAzZzySKPas6MdO95s2t0IHKPmvU6Fn1OrfvWFLWp4FY+zZ4ZcnWaBHEJdCp
EU8IIyAp8g9DQWYZ8gfawOBGGY0vSOL0xhoHTKdd1wRC8UL2/M+yJB4imceF
EcOxv9WWVtA0hJpjaEcdyX86/Y8VEpXA7GyRhtN4uBxgFBfDJjt1G2fzIlks
ASJDR4VDJFQYoTxEeSVJgrECsoz7GpcgHwPpdcKqEGazMM6DIkNwerCVnScT
oOlRTAUwRcDkYj4oEASO8GUgjMtnSxGsyF+m3eYfYMqJMqhUea2OAcSsmwY9
xVi1caI6M5KtZ7NEB9ARhFLSFOJbE+hqbTtxwZF/4XSW0PKqs+16BI9nLBtV
PxT2bDHtq6xo+UJN2OfqhQpNtHInzWRiHcAcYlVYkRK7rNn6mPr5UZxIs5rF
3uIkaOvgrfZ20EbzsnxGlGujC/I9BtS3meQ500PrFVqLHVHeECTyXNYkk0pA
sZHoCKh4IiqGPy9CidEuTm/DJI4cUkbMMQXyEE+VOxchkDIh+MIHL1coeNIx
dzzZ1kKEL/70rn8dwKHIPbDiTzIAe53NapuNm1eXjg+cqBvHRNVYftc33toF
ptrTXV+i/OAygWVLPHXA3KM4z9pEeQa2z1UQqL4KmEZyEiM6DDyprY+U3ouM
ZXUQF3tZeouoYTzjSKruMowObOPIiIg0g4tL+nz16s/vzq9eneHn/g+nP/5o
PvAbLfhy+e5H+R0/2Za9y59+enVxxo0BgzRiX769Pr+8OP2xrWOrW16eCJvp
MkPlAaIkdhcmMNfKAJhTSuegp3JSXXTMZSeX+GG0bxdOl/OU0uayzMSPYT6t
alWlC0xGRX9MIOZG6kZCz6w1EflIEk9jPjkAjbAsw+ENLtiXOfQTI1zggyFM
mpetEJKApKNY8uxgCfSGSbzDbzrallvrM46fMSYXu8B/KRgaH5KRBD9otNYb
QKrXoo3yzX/+/RXl/54EyAjVnRXUecVJTNZSbEao5nqw/gES0bs0QWQjO/hd
XBBEKD1BQmuNS8wEuVKWMWu+6KJQRYsTMAreiRj5CYrD/Wza1Lww9vWC2Qpl
ymiCK+G4uQT853w4YE/fhLdhH5BnVuIMxYXwfZZrFrUd/Ncoy7qDMP8vbmqU
tzY8aweDLEsUHq4SGDzsvtLY04ZmbVCcf1HWZjbKMKmFYv+FAXqTlCiLe2P6
5D5OnCf0FAeWNG/97FOL/9t6FLz6oKDrMAcBGLkZWbiuvcEL/QMBJFJTOPRl
Tn4cBB2yN4rURfFkQIwjspj9C9oDwmAEKKEDckEopNhh2695RJQKO+tiCAqZ
RpBq6je3fQ8jn8Qp5iFhxDvsAuwzUMYpZZ/RMzoL43kuMeeau/YVEcPLGXtB
W/f3r/sZfwFVAN+MFNABkLuztN4p23UQNEjx4UVMauuSF4gJAc8WuH2IDQvZ
qM28xWxW+CJ3MZBqKxG4UUwSxNQjsSq4UwNPFtNWxErMs5FVhPk1maka7E9d
z2nsuDDxo26vIbOpP957t8X2cxMKsvbPvitNdRRIhyJHANZeKJ9jQv/2o3Gw
SNNKAMjKUSWuwjSV53/CEZ3dseF1HQ4L6TTESTz1F1/7fdU0qu9+5O2pzguw
dGv/MeKqOzlKiEQpGH74KLj89KP8G+hIi2pfnzmvL+7rT08D9Ik//TrzIlvA
V5lX9dGXrvHwq67xb0vn9adV6LB1BNhSx4mnvwO84KAc08mlKgOLxpNb6+sr
nKGGo8x/Jo3AOcrPvaP8paN+LrFs7XZRUXYoHOgdwg/YtFSQOZBjYTxJA0VZ
fo6PgUM6rMBnSl3Nd0SUaUreaFAqm8K1FVtaVGqidTzqrIN2tqoR16gTgQQY
6URaWgkz1zT44fr6bfD2EhQTG33NSuFe11fdzRaiBiranQlzERdJjX2XDssz
/iZcH06IzZhN9H7L08qdqGoX0NYDgDobyacrQV9tq39+D4oNrHe/ul59oi1W
6Ba+vaLal+dxOOiKr6QSmK477Vdj4K3x9tBr6oQ3BeduwnKz8d9McOtukrFT
JCky7VhAj4cXpUR2lPVo2Jga5CiBooXD5I/WQbO/Appo7koUNvPg2UP15Rg7
domb3R45FhqpT697P9RC2Qy+6CRBfMouM5H6qNQCICCPYdIWWq3nXWOHcY6C
WQw+iQoTAehTva3GBAFNbGDKmE/qGI+a0gRAEOb8AFLMUaZ1LFmeUHsqIi3K
sJLLyudzhTTriKdkhm2ywoEqwyEPhUK9sdSJsv+WWv+AUmuHIqFhblcqjOqw
aJYE/i1pbtTX15U0ieL8Idd49DtJ0w/ry//0MNHzuPk8/mbzeghNXNfXQ/5+
z3lZCvyngNUim1qMrPZKy2EVTRn0gAatqB64+XusseFdQ6N/H0XBMHMtrqL8
9W9JfyNJvwo7Lc5b1rdMSnz96nqpjLhefKdfuBhHFBezJFyQwMpScpzrWhJO
MshG8j6W/XJHoPoNumBN5Ic0Hf1P1hKOv7pI/ZxxuZkAbaJ7OHURaC+lwImN
xOl9ueB+7hTxurr0N850LrJ6Q1yseEQ5NlnHxjT5za8uMcgvcysr1SPzepIb
tTQkE9EC68IEBXqO0GG7jfEXBqOKMp9rSKKFIoOpx0y+hhM1vKFCKQF6DRHL
P58w/29QFLRkgiUGP0tRwDysLxBMYDvtvGgS/2rhfrlQqNMXH6TA/L6mTBCQ
O38AU+ZmAopPjuvCg2XWcblSavAFBw+VHYnB8H0f12FcfLAxpydfMBKUtvUR
a/YOy8O+CrtafLEwXjWkVbpWpq1r09AbsXmhxH+zXKKBW3IEjJt3iSW5NgwL
2pAvBiILNEkvUVYRXnSEmwHaFoqcYeQYro7+aIarauS0Ln7xCN8xvQN/VvEt
SZFucI4TRG+s4jaxwA/T2dbBojQRFsOIEbkxThyjrD7MsAff0D5WZC6TECA/
/uchB9bNOPpclvbRgu3jJrxNQGYaCcHUOfEfPV2rwuU0zbOtHaKH05QU/o8u
uwseQv0+eh+dRnUmsLdqORt1YpbzKs/hWLp8t9NZ1slvsZqVnfhI8gVMpT6t
1bZBAW2n6e/bpX0YoNqdcaDq/f0Ga3kIpzR/NZbpoDcRY0tnTT640DDDADyi
YSiblOwRbYjoFhKOXMPEytN9zTdXjF2WajrjhD+HtCIBwygi2z9QLUJoiYjR
DNSbohsZJMGMzGKsgmxCP30N2UMO4SqmNpEvICAjEvnAodQ+MBwMIbtEm6dp
YrxoBH6B+7ik53asJWS49QjZ2Onbc8pSgulXNXVMtE/0O0DnMQmP099twJOn
TfWqKRXdaplTp2yprp7aaj19SEVUfP0//34JD0Gxv355hjF/yBp5msE1Xg/Q
an00tgnvJGCJaoyzmmQRfEMt1fnR4Bz+tT6e4BGtniXvWeUV/gpDe8qR7p1E
QfONJUHz1bHkbJMoRslL3AF06IUkmA7JTWc6NGKM87X10VUBnNFfXbvf/Kb1
4V10XtKHg7zO19ZHF1Xs2xxv22+GhQ6DC3hf/Zpoj1zR24pTFVF9sABxTyyF
Vg63wZkUT4u3tADhMQZH37hnUgcr4r/IcL6tkuKTBZ8r8ZaWfrlWzopxk85A
HJbw3xTLS8O/iJsd7niAgYCV+cEbgsb2pTausg2/cFXSVgvJCMfJL53Zqlnh
pNA+iHNznKRPdfLmU5O+KxIxTUTEYiY9Wcplq9fUfNtuNnEusXBuVxSjql5E
yCsj+0smol8QtIFytFoEAl+0wRI49MQ8INn7e9MHoQTsUsdcJ+QnlVRjIUke
J6g2Jfr6adVC+MNqzqmkvJO6B0qVeI1fybC7Er1rq2K1AZfa8vkk2D08frFz
cLSzt3+wbV8BBLOvtHXt/rDoymqe6TyyttOIca4tjRDftp1iXG1C3rbuc3QU
Hu08393p7Ec7x52D3XDYeb6rjjuDF4fPhztRtLerDtzOGW3btahjMRDXfuAh
wymOCMP1354GZ/xqcIFPt+tvy6KdBRez0KyYNqPttfpkA52dmTrHoT5dEy/b
OF8/QkND0lydoAZmNpxUVZmOv6b2OMkGYVKP1ObFxu+TDNS4An9vR2qTlYlo
cRL8HRcSRu81zrWDf3hbhdhbX3sWR8PmdcfRexI8mudKr9C9Xm37AF6Eh0Uh
6QYBR55XYeA3fy9J3FF7afNa64YOKUAEDdorpiuY97nTncVDSouwzdN5ktQn
t2zTdNz9A0iTBLT4FKm8y5wESFdGxGLjqQm3Y4Lepvtl3lMifZudI1xxyP0V
i623K0Rq7w9KpA6HL/aPdsLDzoudo8POweh40An393c6h8e7+y92Xqido+HR
JkQqjpydBJK1//x4b7J/EN28+bn9cBpiMu+az5LvaWk7oOEtNuAZPjM9raQj
Nh7qiwe0Xfn9rKE3FQCQR3A6L+Ih0yLnu0uI6F2iUzQszhNfb1hCuZjpswaz
H86LMptKC1lZE79A+knCKx7nv9tVy3LxysFnuq+iNjNZoXQQBIaqNr+JQi9O
Uw9mSO82rH+SlRmO4G+j890SBBCaPYXh/pEbkWeEZlPuYrnUTBpGPaep7u/V
CjBJgFmaLLj3hekbz5wuEP8vlJ31hJvEZ1qtL+t23asMvFhH26w5DNKYYMXQ
If38xXlxY7nyZAXpdAnnYRPhXE02n5HlXKPzbiMVRRqKoGkmovDri8FROIqO
dzp7O/tHnYPj4QsU8fY7h1G0O4p2hkcvXoTtryM9uYAmqWY4OAjDvb2oszdS
u52D/b3dzuD5seoMBmF4dDQaqOOd46Vyjz4xX6q+bKxvkAXf6OP3j6y7wbHd
Y0zE0iPpOC6GWS6Tpfyx+lmkxHzUJeTHOQgmCbqoxGKP08ZEayo7YFONo+7X
UOi+jooWCMzc4//IPf743pMncBxM5jO5rkzZavEUFX7xji43IyRemuJvygSZ
6g8XmVuv066OwKQvuQgDOL3DCa5FnxKbokn5pTI6HFEvXZvvZoJ9ANkr4lf4
DJq3CAOEbvHbmCGJIHpkBJOAjX+0g3I7iZgJLW1uAvyJQNKO5lTomJik/CWV
XmRJE1s0welBij9IL059CxMhUq2fwL2J3me6k++VpISigkAG2DZZEnYaZHXZ
aLxUhsy99eT46iR0a71TIe2TaaStxpUiDy1zfCgcvNBFG2y8jF1LN6W6u3ib
oTxA3sVZyFxlCmA05euMGqvB2GxpxLsPQaLSsdQoxWFM9zjxIuP6PVzRhApk
8OVqs5wq0YIqPFTfoT2VEMol0xqraGVuBFt1Lwi18mBauSmKq6rxy4XwxHr1
iDpovQrDYmLGUvKx3G6XaRxyovEbKqgum0n9khlZj3trDXm+taLNv/9fRlB+
qAsWcdZvmDQkzTi54qYgq9iIBlIWJXQyB0w9DrysQc6rk+btFR7yCpk5GK+V
f8WVKV6lUUesSDOTiJ6E6XgejiX3vaBkdBsDwGU7cEqjEBOmzeZw6YOQ8aWj
MxoiysxHukLWVbwvG3ZUDxGU4VjwGml/RLQDb5yiySiSDsni6q1T12WgGlwW
1e3aKCE4pEpZKCtiaahu8PNkUZsbLhAjuUSSDfM8XHwnrgPJB9FIbjkMAkx8
KZo6au7AUL2euByj0KWA5u7dehxhNuVqO4YGAAsGZuSse9VBqjFJd0y9Xdit
s/+gMKTqPV9bSHO1BUcC+k1faYiH0dQGM9uH96GTgKr7I+tKpaOUr2LXl41p
WZevUPdao12IGnMVnvoJGWTiJWzH6NmiohDFfODwTl2UO61e7WfKeTWVBuN9
Y3PVBgfVhXpYFFgNw6E8VLmqUk7YX+N7bebSYy2bK4OqNl9BR+3gMwjp+fW0
qIhEykg4UhdJPC9c+26elDFqqRjQWnuBgF3xJHpFafCICD6cXqGQyzSTetNd
N3bTcruRnu+oTDUVrUKGA4BdMHMitUeEL2HN7M1x4kZtFLBpS6REsGnpTI1k
RMZKC00udGdO9jkrn6vPnMhHBpHt0oiiV88t4XPt3MrE5Jhi6R5tZ6Q+e+7V
pyg7kOcZrcCa5BLxknFtJx7SNXVSvaDMdKrxkTaVBIY5tCDgbnul8mrTcQ4N
Ft2y16P1pGYDywr4GslXAgu9XqnzwPM2ggHyRV2ccG0VQ7shB3FIS68cNqSM
59rfcloU85wqm4nnRZ8cexIPzjnOCru95V12mI5cBIfSHF1N33wXPSg6dG89
JixwEROTrdzVnmrXnco6oAQHGCXQicqKTOxB4YRzNeqFJgfU1QutY3aVWhfq
96o5GPyYLS2/hV+NHffaQ3z/yBZP8WLl8DojHNL4hm0JljostHe5WU+uuHfJ
go1CFgYPMJWSfll/ZiBhWEMKZMqNbYiMYrgCsFrwt7CqFt6p6YImSJQ5F+oU
78NqDkXHk2Scan3L4y3qNyf2RapxhOylXW9yE2NfJh3aimiNzN4NtamzMidM
cRuLL4fpwkgSZ1JLh7CsgbM3DlW/WnqTMZnpUH3I2XyQcA1FSSXhfjRNxBJX
UqJx+UTDZAyKWzmZLgexf/WtbdAI6eA//x7ZMZC04CgjuXh4OUDkjSBzLjfW
AwAyfv0TzlFG5ln9pstiTqgwmicmAkfuRvcCL04qVpfmmAGiUZ7tSe5hq1qs
HvkWK//qUteus9Y07YZm2UgsG0JRs01vFJixWd9ygz3bXRoiM55qW9/7GAM3
7sIckQA2QbvlfINzZf0+M0CSa0IOmCl7cfCrzNRBzVjtevkcj5yYrB8aOuD4
Cb/I6G2hJe7D/Z2d9c4qQ2SNyX2gAL/zikepLQ5wZ5Zq8ebN3tmRnmJXapZw
iN70b6MXM9943TDBo52dalAAR8Nbx+lKX/6nr+TWd5Y0Gbz79Xz3wqwqjmRF
/3F1d3j2fTT4uTE240EudxjpTTZJg7OsKdCD3nY87A5CsCfNIMXsGUz41+gm
vmzXelnreyeDsDbCaFc7X6YOQrETE3dHJZFFdBYhXDigrm5Tiz/lHIHSCz+V
2r9iv0drcwoS6RzTw77wRO+tONG1A73mIH+GW70emLP24O61H+pHvn9AQMEz
7tEOVvOZV93OTu/tjbpub4pRIhWSmGps5n7IsE2/oGsT9P0rzkvaEWlDkVst
q92ITGRinnM1VWQewtsv0IFyI3UPjR0hrBsatlFrK4m9U+IkSDRxMbOSDJdD
1LEmMcdd69qDrJcK//+HZHs2BQU+agoKZP7d2OC34uJ+VOTX4+kScolhuB7L
Pl0R2rMkR5zHL5ae42D9WZaTshPtvnjxPHreGQ1GYefg+TH6eA/2Os8Pw+fP
B6PR7mh/sIQhP+RMHyzzE9drkdqylI2Mya0rtcoTHtuhl1F7/I8bXFFxbT7y
XJuMiP4rvx0GEpJ8PdTbCNn8tf2PQ7FDtw9OaJQ+tKz3SafaudB65EGr1dIK
nmhKvlYfrHNLS9dr/dJkksNvYs8Li5otb1VsTIOn2a3RgL8hBEQjTXkiYlut
+eLEXwBrKNSQEh+FaRQTumyRrvapXvHlhDusKBZBDgYj2TZOh5NRF9grmuCm
XMyX58GBDbZTJyNxhUepwWsO28wPrG3YGFbIUO27ek1xCDYloHhX8YPXvODL
faswtvO0NoG+lDWQ2QAQuSJ7xTZjpiSmKL6XIV3hs626PWq+UquUL/Xbwmwa
bOcNPcnFXQ2lIYJG14e7Abbs40a+jNjNaTUnTn5cljFl7ODeeL63w5PbPbea
dk7I+ulCDXJyoNxDvo9T73aouo/Dd5B83hIYkNXcQse32dCKudaSkcwSZWKx
cq5ec+3GvrlYqmM09+mFzKgYhUbeRaLqBgI4DImY7vtkhTI6N3wmfcmyQfc1
YxDx7CBkhOGdNrKqP/KG+hjhC8nlDZOPyddeWEIh8ZEbCufNviu9fRUf1rU1
Szr4b8HuEV3NMkzvBqW8XjX7YJ/XEnfTCh9nxQzbs9ZXXQRcogl0jmWiwgLD
z/RAnnPsYV1QH849V6t9SV/sShIoL/cl8YRwl3SCgmuNnq9cjO+F8my+hCNa
amvzKTwlmzKKpfy47uf8VeWZIda6NR9pDNTj759A321ZQiJSkHPAGencn71s
OQGJ/H65mmgFtpq7wVc/jVZLD4ZgVs5Lt6VD5oQuGKS56pvb4/Rvqy7F0bY7
+3b9qi+Tttyls4SFomSv7cGo0Q97b6E4q676teZVIcgJVvgccaixTkNdJnR8
hHiuIvcGVyrGwfnDp1JQuTJnMTfWJrzMLV+vJuzX+pD+vIifO5Iw3d5pNQvj
B9R+UTpLo3lCsT3XftDMyuwYB4/ruswGBt4vNO6uM+w+0MJdNV45HS23DocJ
tA/z4C6PS2W+6pyDilbkRrK3WpcpR7zPSk4X0OfYZ3ySE1CPq+DgaM+GQaKl
b+xhaRO3tfnsojPp86+06gavtD+sIIFeHP5OaEM9Po9xzEQHeqqGhFgaRa1B
BCeSYAOcODZwNkNxIlsSEVi9kwNVdVMm0gUgzACQFr8B1H91RU1Tw02fQH2j
Mtfcs4nGteJ3Xv2zd259vtStDbekX6pmZm7BMhddkX8+MTX9fBHFjCYhQq5Z
xykO2HtYL34SJt/weT2x8eK+flYRg0+eiLPV7wULOJlIJiriYG6yda8aJaex
6GVGjikzKSKtb9tCOdOLPxVTifVTu+tjQJiGWBAJHhcYnNKkA+sbtNx1y6ne
bOHuJsCyG1fdD9yrf2XVgqb/+nWTWOZQMFqFvlFJYsv80iCE3hKVY3VwLPgB
Lb10Kx0VUquELuKaPbte2hCK9g1JQq4FwN7fQ7Dl4dy33RKiviUAqBjM8xt3
xG8CmGe+cO7BklAgXj/RcdnYen5TY735rmUEt8srxJsYNMEGL/bCxGZwIZUm
wNZLzNvzXRtNvP+W7iPBRGv5wyjmMJwXy6kl1jEVEu9fZvBAEqo3DHRYLefQ
LaCVYwODv7SDh9XCm3SkjFprpVgnZIocPPVelxBqEIfES1joW7rMNuEdhTHd
pF7jcah2qRQ2wQbzu9DB7SV8KECxTimQTuAts5lmgzjRhfLJCJCE85Qza8Kg
WBSlmpopc2ww4uOUSpUh5zax68FW78fzx25VBs24LVqQgSrGWJsCy9zQHWJo
ZENxHct6xh/kaiu6Tq/gi78wQ0nQuS/X/KHKWMQRXsRKkoRzA1j389hMZXuR
VKXGjmkvevT5y/LNRZQZ4Wl3kZIg8nnMwN1VsXjynCzhx9OjzEGJ04ZpWT4g
dzZiXBVdgqxSuuKddWJQiGM4EoRWLFmFDv7wgf+tGIp3MyEimsJyyph1E0/n
U8m8kfQZ74aJz6I4kg/EyM61i2k4KuTnhPy7YA3NJhuSQgWQhVQjcJauAo4x
rgLez7MZp0b8L0TWIdeH1vCoANurt4KfGXoyX6dO9QbShfN2/VQsG6++kWYS
Zgspou6q75V+dMOHLcF3VS85gOaSPewhNnU1XSOOq+zaBa6wNl83G038NCWb
4rBrckyOjg93Psms279khZK8D/z4dJBFi7Ybvlqz4i2pDlb1XJqpOco+rplC
hTVyT0AB5mQa15uJQdXPjFqMDZ7t0Q8/ZBiPqH/R6jf95JWkPgl48GC9KeC6
Pzulra0FVT6qBFU6CrO21TnWPi+qw/xOCWeO9cTa2Sh5Ab0MwOcojwRdXSnV
aWVhBaE5Cks0uVAM6DYGbE6Qf8djgDLshoneh82zLoLuP5yJimoNDB1ZJCzJ
/a5Verx5HMAZ6ch5ik81ZN66H2ExYSH5GPWI558Mymir69PgNHWCXYdkSxLt
nouXOGhmpKRaLTunAJdUqYUzpGHx07ycA4iuf+yjoEK41Qf4AAC7JBGUeUiY
q9LbOM/SKV8tTzPBo9l7eXnFh+J4B2/5peLgaP2E5eKpZMbUQ4zn2mW7h3uV
t+A3eSs7fStv7e/t+28xDguJkgK5zUAKUw2iFC9clS1ursObRo1xZpJiS6ou
dsJhSjz2dTYLflS3KrHj46MEH5nRRBQg/8rAnn6SXsWzEoxAJGSkRszKjCNJ
fYilvk2tW2KkxuoiwKh4gh2wuPYfWx3f5oFVFXzaVF0W0Vz6nPHt8wJfPaib
d/iAISWN+DMH9V2sdtir0yvmCROKz0I5S45poiyUXH9U45TpFZDKJmoacoyi
k41b8as4VyH8RftFnHSabi1Bga1gMq43LFVOQRz3coZDnUFSub9cbo6g7mEy
gCnzbF40VMBcR0DCJg2rxzg6nidhbmP2SByRgfyEDkohwPQhp/Cn9bv7ed5R
FtwZ+79v4Y9ReMNfWLisJAezCqXCW6H6FeyQbNjgSi5ml0KvmEwLQ77uFVyw
OrlDuQVp1mmxmKoSXRJO4sLiO0q/Ren5RqkZiy0cAFGoIRCD7zRQ5YrjWUhi
d2NfEjabECOnK5ins7m5OB5TaGHmeDc3WoaByIjQxDOd4EIb+4VvVNA0vAWt
DGV7pptT7gTk8egO+SVme+K+kEGBjgMg5nwooZf+XOLpDDAOiZsBGo1PaYC2
kAKRZzccxEDj50nMgZ4LbkNp0W4WhDQTAqwvat4Wt6gewF4UjuEIqpPbQg28
C9vaZOrXZkDuKzfeC14g0yAfJ9mB/LgX9BLxdd5ymR3fzD4E5EJ0dyM8qYyB
LfROhTXiQqpX2Hxyw1oRhBaGIUpjlBCHLIbsFqkaZ9beYHPUHfLwnetuhcY3
gA4FZ/LUs5hi8pQPwxlpkNnIu3FGt6QFNDUlBWaGFe3FmB+MASHTSslQc6NA
mLJWppmXMZkUcmYr+sBwkoEsLBPACJvYSd+v3BZ/RxhkirwN0HWsbTQD5ZZM
gONMOOZYPyq+kG0uFIFN8SQrVq+d93GtQ9Sk4cAQgiyxk3R9XlaFIIEviW8U
Mfgh3pJiDqWsmlCgIPmB27AhwKBBZAKILZrAwaVAGmA8xTr/TcN53eCiHhfF
JJkJSeIwRIndRPuYWg+xvbbmxCP9pN3PtcbOfIJSoHnkW/GG0numImhoZgPg
tSlsiH5p5TYalr5q1f0Ftri/tOwRZv32rt6d8UFAqTzGQg0ap7wxhMHrrpnC
45OKfNLpMLulOHDMKtgO5jMsMBSQSSwBDcMbrmuJIHWAdxEF2qOJhA/jKjQ6
wyLn4wl7GwsHItuaKGmjI2HpTKQ+MV0uaFNsEBZyKkEZVg5BfInxVOWa3jLz
/Qbki1mcoigVnDz2GSRd8eMGg2ppk6RXgjIe4CEsMbIqFBEAp5iDjt1JLXXz
H3mExfJSImJId+PhPCHWjmGYgI4oIFO+n0HPLtB8ss5T9AfCLZnziQDIThWT
KEPDkZLI+QoFKFZk2BabFMD4FntB/cYImz51Kie1IirmVpEmy41z7LmVV0OF
SAAcbMm6RLRjDkwKK7RpOul2uyTtl0tNVONpOdnJ5Vc8JRBsSO6jd6g0hZgI
xUDpm9eluTVoOxSDLCMgRJJBXZoYe6QIyG9ZZMyDrcu3j42r1Gei0hTUqm3N
o/ihOTT2ujPq4fItvFHMsbXtyKXBsiJsQ8GLoTuImYW57czItUytaA06VhIG
88hrrDNDuApL/YC7qSNEN3xVwcCvH3M4tOGoTogxktt0ITdtAUvWaeO0GF9T
DItmQrNtMEqGmPBpIWdfipVsnEt8PZrq5OpLjX0nmJQVNASzy5AYcDRVXMk7
Jo+0Fk8O4T1SZk4ol3Casofp7gWCMF9cPYJDqFLDuIw1DixJOiFVqWvSOOlf
RwExO8kkjzRutMiw+DIJb5eQcFIwDD4gPUKDgD03vIOpjvjCDTfDP63cbeTe
lZB7loGKnqfPR6ijgHix245EWb2SCAUIXbUyt4FFSYaGtDIzKd40ezoHIh+F
wdWr/jXmMVvPk7UZeehnOjkNQEUckxMsUbo4l3g5DJppbMR4ktjcY6dPXw2v
c3iforpHNuJaTGoRl5KyBtAkXJDDD4VFufMPIeNUmtO2bibIBvkpimWkhUDE
YedqPviUZAtWOkV6ilFzGC48OkxGaaJLXLBBSttlqbN1Vp/Et8Oge6eSpIMH
wCluYIiDsDbb3NIXp5RDOXEqScjCLOnWcMXMBq0TQWOga0VgvcBEUlDk9BV5
Kv2EKK3PhcDfUXDOS8Ya1ibl8qe4uGFBegrLwfqBXl5cGN2iURX71vO29AEO
P5oe9Q8oE7pAiuJimN2io98aKkSI8gxqIAfcKu1HnWRFSZHr1RtP6/Tcd9J/
5+o6qKUSoy8LlYy475qiYBh42dW7iCZoFBsQgcSNqlURsT+wnZ6mNqAiLkQC
h/oWKi9soLbBIKDMOfxae8nLRg1GxDNHES612/vG1Cny714zBUXExkLXYOGT
tWEQ3YZzYSKVdZxxKOZNEdLu789PL06DNz9fY6U1qb7G735nNWDvLelJZ4qZ
GGRRVOiyS1/9YUTzOjE124qmaeoG8vCwu0tdkxxc6ZudWW/z+DYcVj3nrZb4
DpZ41s3vp0NE9ERFY7Kq6/jAPBwhIcrpDp2p8MGYw09ZIyB8fDNHM3FwBZSf
PI/XsI9FKATV9+ZIn/f31x/wOUb/tlquBRL25YaOutcpMyx0UcOhVPQQnRwv
QT2GaWn+F+dY/iojtIIO/8kROGhQQSGNRgZwOeUeIyOxMqlB4yKZtLNci2JY
mw3R4h8UXIn71whCvLUGQz7wrTMdVvkDtMvyBTmzafQOzrrsfECC19H2p87O
DrQPzikGJEEsLygedE2jXWxUgq5ANiOgmjP4zvK8BM/rAhb6cfuXu6KtGUQl
ktqqw/A64CXQrUimJOmwrL12vvXVp2Vv69u4vm1MqnVa9Uz0kzuGjzP1sbxW
dqxlU7MhVgGnleHLvpYv5T80rCoOMRPbUHuuY3QrPGxiMtVWbuIebuI0/IUi
xClmGL5z20KICft8Wh3RxAH9h0ZwsLYVbzHiq2RwtCii3AcoeihQrQbWhiZ/
eCXJuL5YgQslqkRwWLuAfVwAkHsA2dUlM0M6yvBU6jXaEpl41rRl3GKl5G1E
lbhjwlJRjhMuDvTPfMlrpq/q9clsYkP5DtnX2sUctByccYeBvgojmM/m+Qwt
ikawwffXd36Indtimq6+51ov4tRYihzTBTZFds7eHeB1MXQM4i6btmh5NHW2
rfsVX504NSoYJwZIv0t3tdZK4ADW7iICVSzf0LfEo7vt7Wkz7T1hAquE4Uxc
ynBBKdm4hFkS4hqudMIE3dJLuginsuD3Ln92tUXEeJIn0Xeu49PWbMmRIO98
po0sBeuoKDvq7ZXo/DVdHTPqgL5Skj/fhUfu+HhN0ECxALnsg2Qsku4T1Swu
xkLLoByrVDlaA2+B0LPBgvQjtAqKm4F/LxyMBqGBA/J4Gy5s58xePRLxVpbW
hU86CH85AACKidLCLmZcBSUshCU8mOEYjUcd+VgZSZuibtQieCZxs7MwhqOw
Fd6EIHqzHJEvHrtOeLf219rNeY64Dphe2owHADVK5ZjuoJ8VJxgAj6Q8ukVh
VagPhcj41B3XMgYNcaaiSsIN91tLo63SX5y7ORsmeUzXwvTTDJ1ogLULfWE6
VSTioDyRcsF1UljdnA/JOOdMTK5ljHbxIvgrznXdULs7digbE4Te76rxXPNi
ZhLAbrK1tHJ318Farz+i6s5t886j8DaLqaTmaF5onSg4/RvdVIE8NuLoMSLW
bLfFZEH07AGP5GzJurhgx/MYS+V9N5afXE5e+8rLDVN321fepvhNOwvnvY6z
xwhb96TTFY1AmQdEznwe6et1gOCeWuXQ/nWbtEcDTonF+5uuyzGRRxgBX5FO
BNFnWbKAjUBn8trB9s38/yw+Eq1AIY0hr4b192g1S+87ZgFVpjAgUxOgK8o/
FIhljEH6KmkxAo4S9UGCrLbNevUlTZjaJRIUz45v6CYeVjilMOExVZAnL1Vu
rcNr131AQL7LuaQRKDfA4S1nRcqitVE2SuMoLBMUfLsyyHgqx7cHGD81LI3b
W3qA5s72o4Jm7rECXECfkit2G7bvOtQtJWC9lKMNAMqTeAbdhTCfKbzDjqtI
P7HCBUFrkiWRXBixRJe10/CJaamrhKHuhYoBLKjQBOAS3w32ujsEGd8cjvGv
PWFJ35uijxIBSjK58C7rHr04fcsdSbd/begWN5gz8tAsZ14Ufq0tTpU2KPcs
pMx9uTA4Uo1bwAl0dd80G35DrtKm9MwC+FKOF/aIscWZqwc3RpDtZTO6fBts
VRwpjznyTKxTNoyFCzfAppVutAgy9KXhf36ChRfd0nXG0IkRhRexgdKOqY4i
lUO1kMUUkrP/xFzliA1N2XXOpJyR6ap7NOXMQgr2XbjOMxLSN+pJxFOp0Wxu
ijFirr7ImBkV82kJXvGu1fC2jvdM7GQ6mD0b6ITgJXcVP3XNihpctbqumVeh
2jVICzqZctemRzYSu3WACzQ5Do3duBvgHchsYmGLP/obWE6l9ByRbFXUrYEf
q6lJJBhF4QCh/qawGg3FQ5INBpimKy7D2baCqz3dhMB0cHI11zds0018xbaN
ARL7m3eRH67fUJNuYz9u+57VzU0xB+zBO2QEw4tM6Izne7JZDOLbuepXbDYm
OlPio+VScLYXI5V8e87pMhfqzqNvT2k7CBGSxDGrs9XAq87M6NkYWEb9mKwy
g6zmEgIOK2oIA7G1BLTQ7KZJPQ36XEiXVuvnpRhy4Ku41OqHeDzxoi2lkIQf
Jf2p2/pva0KCOw7gAAA=

-->

</rfc>
