draft-ietf-teep-opentrustprotocol-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY RFC7515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7515.xml">
<!ENTITY RFC7516 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7516.xml">
<!ENTITY RFC7517 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7517.xml">
<!ENTITY RFC7518 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7518.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- <?rfc compact="yes" ?> -->
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-teep-opentrustprotocol-03.txt" ipr="trust200902"
  submissionType="IETF">
  <front>
    <title abbrev="OTrP">The Open Trust Protocol (OTrP)</title>

    <author fullname="Mingliang Pei" initials="M." surname="Pei">
      <organization>Symantec</organization>
      <address>
        <postal>
          <street>350 Ellis St</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>USA</country>
        </postal>
        <email>mingliang_pei@symantec.com</email>
      </address>
    </author>

    <author fullname="Andrew Atyeo" initials="A." surname="Atyeo">
      <organization>Intercede</organization>
      <address>
        <postal>
          <street>St. Mary's Road, Lutterworth</street>
          <city>Leicestershire</city>
          <region>LE17</region>
          <code>4PS</code>
          <country>Great Britain</country>
        </postal>
        <email>andrew.atyeo@intercede.com</email>
      </address>
    </author>

    <author fullname="Nick Cook" initials="N." surname="Cook">
      <organization>ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Rd</street>
          <city>Cambridge</city>
          <region>CB1</region>
          <code>9NJ</code>
          <country>Great Britain</country>
        </postal>
        <email>nicholas.cook@arm.com</email>
      </address>
    </author>

    <author fullname="Minho Yoo" initials="M." surname="Yoo">
      <organization>IoTrust</organization>
      <address>
        <postal>
          <street>Suite 501, Gasanbusiness Center,165, Gasan digital1-ro</street>
          <city>Seoul</city>
          <code>08503</code>
          <country>Korea</country>
        </postal>
        <email>minho.yoo@iotrust.kr</email>
      </address>
    </author>

    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Rd</street>
          <city>Cambridge</city>
          <region>CB1</region>
          <code>9NJ</code>
          <country>Great Britain</country>
        </postal>
        <email>hannes.tschofenig@arm.com</email>
      </address>
    </author>

    <date month="May" year="2019" />
    <area>Security</area>
    <workgroup>TEEP</workgroup>
    <keyword>Trusted Execution Environment</keyword>
    <abstract>
      <t>This document specifies the Open Trust Protocol (OTrP), a
      protocol that follows the Trust Execution Environment Provisioning (TEEP)
      architecture and provides a message protocol that provisions and manages
      Trusted Applications into a device with a Trusted Execution Environment
      (TEE).
      </t>
    </abstract>
  </front>

  <middle>
   <section anchor="introduction" title="Introduction">
      <t>The Trusted Execution Environment (TEE) concept has been designed to
      separate a regular operating system, also referred as a Rich Execution
      Environment (REE), from security-sensitive applications. In an TEE
      ecosystem, different device vendors may use different TEE implementations.
      Different application providers or device administrators may choose to
      use different TAM providers. There calls for an interoperable
      protocol for managing TAs running in different TEEs of various devices
      is needed.
      </t>

      <t>The Trusted Execution Environment Provisioning (TEEP) architecture
      document <xref target="TEEPArch"/> has set to provide a design guidance
      for such an interoperable protocol. This document specifies an Open Trust
      Protocol (OTrP) that follows the architecture guidance.
      </t>

      <t>OTrP defines a mutual trust message protocol between a TAM and a TEE and
      relies on IETF-defined end-to-end security
      mechanisms, namely JSON Web Encryption (JWE), JSON Web Signature (JWS),
      and JSON Web Key (JWK). Other message encoding methods may be supported.</t>

      <t>This specification defines message payloads exchanged between devices
        and a TAM. The messages are designed in anticipation of the use of the
        most common transport methods such as HTTPS.
      </t>

      <t>Each TA binary and configuration data can be from either of two sources:
        <list hangIndent="2" style="numbers">
          <t>A TAM supplies the signed and encrypted TA binary and any
             required configuration data</t>
          <t>A Client Application supplies the TA binary</t>
        </list>
      </t>
      <t>
        This specification considers the first case where TA binary and
        configuration data are encrypted by recipient's public key that
        TAM has to be involved. The second case will also be addressed
        separately.
      </t>
    </section>

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

    <section anchor="terms" title="Terminology">
      <section anchor="Subsection-Definitions" title="Definitions">
        <t>The definitions provided below are defined as used in this
          document. All the terms defined in the TEEP Architecture document
          <xref target="TEEPArch" /> will be used, which are not repeated
          in this document.
        </t>

        <t>
          <list hangIndent="4" style="hanging">
            <t hangText="OTrP Broker:">
              It is the Broker as defined in the TEEP Architecture document
              <xref target="TEEPArch" />.
            </t>
          </list>
        </t>
      </section>

      <section title="Abbreviations">
        <t>
          <list hangIndent="8" style="hanging">
            <t hangText="CA">Certificate Authority</t>

            <t hangText="OTrP">Open Trust Protocol</t>

            <t hangText="REE">Rich Execution Environment</t>

            <t hangText="SD">Security Domain</t>

            <t hangText="SP">Service Provider</t>

            <t hangText="TA">Trusted Application</t>

            <t hangText="TEE">Trusted Execution Environment</t>

            <t hangText="TFW">Trusted Firmware</t>

            <t hangText="TAM">Trusted Application Manager</t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="model" title="OTrP Entities and Trust Model">
      <section anchor="components" title="System Components">
        <t>The same system components as defined in the TEEP Architecture document
        <xref target="TEEPArch" /> are used in OTrP, including TAM, CA, TEE, REE,
        and OTrP Broker (a.k.a Broker).</t>

        <t>Secure boot (for the purposes of OTrP) is optional in enabling
          authenticity checking of TEEs by the TAM. A TAM provider can choose
          it policy whether it trusts a TEE if the underlying firmware attestation
          information is not included.
            </t>

        <t>OTrP uses trust anchors to establish trust between TEEs and TAMs and
          verifies that they communicate in a trusted way when performing
          lifecycle management transactions.
            </t>
      </section>

      <section anchor="teeanchors" title="Trust Anchors in TEE">
        <t>This assumes the Trust Anchor specification defined in the
        TEEP Architecture document <xref target="TEEPArch" />.
        </t>

        <t>Each TEE comes with a trust store that contains a
          whitelist of root CA certificates that are used to validate a TAM's
          certificate. A TEE will accept a TAM to create new Security Domains and
          install new TAs on behalf of a SP only if the TAM's certificate is
          chained to one of the root CA certificates in the TEE's trust
          store.
        </t>
      </section>

      <section anchor="TAManchors" title="Trust Anchors in TAM">
        <t>The Trust Anchor set in a TAM consists of a list of Certificate
          Authority certificates that signs various device TEE certificates.
          A TAM decides what TEE and optionally TFW it will trust when TFW
          signature data is present in an attestation.
        </t>
      </section>

      <section anchor="keytypes" title="Keys and Certificate Types">
        <t>OTrP leverages the following list of trust anchors and
          identities in generating signed and encrypted command messages that
          are exchanged between a device's TEE and a TAM. With these
          security artifacts, OTrP Messages are able to deliver end-to-end
          security without relying on any transport security.
        </t>

        <texttable anchor="keytypelist" title="Key and Certificate Types">
          <ttcol align='left'>Key Entity Name</ttcol>
          <ttcol align='left'>Location</ttcol>
          <ttcol align='left'>Issuer</ttcol>
          <ttcol align='left'>Trust Implication</ttcol>
          <ttcol align='left'>Cardinality</ttcol>

          <c>1. TFW key pair and certificate</c>
          <c>Device secure storage</c>
          <c>FW CA</c>
          <c>A whitelist of FW root CA trusted by TAMs</c>
          <c>1 per device</c>

          <c>2. TEE key pair and certificate</c>
          <c>Device TEE</c>
          <c>TEE CA under a root CA</c>
          <c>A whitelist of TEE root CA trusted by TAMs</c>
          <c>1 per device</c>

          <c>3. TAM key pair and certificate</c>
          <c>TAM provider</c>
          <c>TAM CA under a root CA</c>
          <c>A whitelist of TAM root CA embedded in TEE</c>
          <c>1 or multiple can be used by a TAM</c>

          <c>4. SP key pair and certificate</c>
          <c>SP</c>
          <c>SP signer CA</c>
          <c>TAM manages SP. TA trust is delegated to TAM. TEE trusts TAM to
            ensure that a TA is trustworthy.
          </c>
          <c>1 or multiple can be used by a TAM</c>

        </texttable>

        <t>
          <list hangIndent="4" style="hanging">
            <t hangText="1. TFW key pair and certificate:">
                A key pair and certificate for
                evidence of trustworthy firmware in a device. This key pair is
                optional. Some TEE may present its
                trusted attributes to a TAM using signed attestation with a
                TFW key. For example, a platform that uses a hardware based TEE
                can have attestation data signed by a hardware protected TFW key.
              <list hangIndent="2" style="hanging">
                <t hangText="Location: ">Device secure storage</t>
                <t hangText="Supported Key Type: ">RSA and ECC</t>
                <t hangText="Issuer: ">OEM CA</t>
                <t hangText="Trust Implication: ">A whitelist of FW root CA trusted
                  by TAMs
                </t>
                <t hangText="Cardinality: ">One per device</t>
              </list>
            </t>

            <t hangText="2. TEE key pair and certificate:">It is used for device
              attestation to a remote TAM and SP.
            </t>

            <t>This key pair is burned into the device at device manufacturer.
              The key pair and its certificate are valid for the expected
              lifetime of the device.
              <list hangIndent="2" style="hanging">
                <t hangText="Location: ">Device TEE</t>
                <t hangText="Supported Key Type: ">RSA and ECC</t>
                <t hangText="Issuer: ">A CA that chains to a TEE root CA</t>
                <t hangText="Trust Implication: ">A whitelist of TEE root CA
                  trusted by TAMs
                </t>
                <t hangText="Cardinality: ">One per device</t>
              </list>
            </t>

            <t hangText="3. TAM key pair and certificate:">A TAM provider acquires
              a certificate from a CA that a TEE trusts.
              <list hangIndent="2" style="hanging">
                <t hangText="Location: ">TAM provider</t>
                <t hangText="Supported Key Type: ">RSA and ECC.</t>
                <t hangText="Supported Key Size: ">RSA 2048-bit, ECC P-256
                  and P-384. Other sizes should be anticipated in future.
                </t>
                <t hangText="Issuer: ">TAM CA that chains to a root CA</t>
                <t hangText="Trust Implication: ">A whitelist of TAM root CA
                  embedded in TEE
                </t>
                <t hangText="Cardinality: ">One or multiple can be used by a TAM</t>
              </list>
            </t>

            <t hangText="4. SP key pair and certificate:">an SP uses its own key pair
              and certificate to sign a TA.
              <list hangIndent="2" style="hanging">
                <t hangText="Location: ">SP</t>
                <t hangText="Supported Key Type: ">RSA and ECC</t>
                <t hangText="Supported Key Size: ">RSA 2048-bit, ECC P-256
                  and P-384. Other sizes should be anticipated in future.
                </t>
                <t hangText="Issuer: ">an SP signer CA that chains to a root CA</t>
                <t hangText="Trust Implication: ">TAM manages SP. TA trusts an SP
                  by validating trust against a TAM that the SP uses. A TEE
                  trusts TAM to ensure that a TA from the TAM is trustworthy.
                </t>
                <t hangText="Cardinality: ">One or multiple can be used by an SP</t>
              </list>
            </t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="overview" title="Protocol Scope and Entity Relations">
      <t>This document specifies messages and key properties that can
        establish mutual trust between a TEE and a TAM. The
        protocol provides specifications for the following three entities:
      </t>

      <t>
        <list style="numbers">
          <t>Key and certificate types required for device firmware, TEEs, TAs,
            SPs, and TAMs
          </t>
          <t>Data message formats that should be exchanged between a TEE in a
            device and a TAM
          </t>
          <t>An OTrP Broker in the REE that can relay
            messages between a Client Application and TEE
          </t>
        </list>
      </t>

      <t>Figure 1: Protocol Scope and Entity Relationship</t>

      <t>
       <figure>
       <preamble></preamble>
       <artwork align="left"><![CDATA[
PKI    CA    -- CA                                 CA --
        |    |                                         |
        |    |                                         |
        |    |                                         |
Device  |    |   --- OTrP Broker / Client App ---       |
SW      |    |   |                             |       |
        |    |   |                             |       |
        |    |   |                             |       |
OTrP    |    -- TEE                           TAM-------
        |
        |
       FW
          ]]></artwork>
       </figure>
      </t>

      <t>Figure 2: OTrP System Diagram</t>

      <t>
       <figure>
       <preamble></preamble>
       <artwork align="left"><![CDATA[

        -------OTrP Message Protocol---
        |                             |
        |                             |
 --------------------           ---------------   ----------
 |  REE   |  TEE    |           |    TAM      |   |  SP    |
 |  ---   |  ---    |           |    ---      |   |  --    |
 |        |         |           |             |   |        |
 | Client | SD (TAs)|           |   SD / TA   |   |  TA    |
 |  Apps  |         |           |     Mgmt    |   |        |
 |   |    |         |           |             |   |        |
 |   |    | List of |           |  List of    |   |        |
 | OTrP   | Trusted |           |  Trusted    |   |        |
 | Broker |  TAM/SP |           |   FW/TEE    |   |        |
 |        |   CAs   |           |    CAs      |   |        |
 |        |         |           |             |   |        |
 |        |TEE Key/ |           |  TAM Key/   |   | SP Key/|
 |        |  Cert   |           |    Cert     |   |  Cert |
 |        | FW Key/ |           |             |   |        |
 |        |  Cert   |           |             |   |        |
 --------------------           ---------------   ----------
              |                        |              |
              |                        |              |
        -------------              ----------      ---------
        | TEE CA    |              | TAM CA |      | SP CA |
        -------------              ----------      ---------
          ]]></artwork>
       </figure>
      </t>

      <t>In the previous diagram, different Certificate Authorities can be used
        respectively for different types of certificates. OTrP Messages are
        always signed, where the signer keys is the message creator's private
        key such as a FW's private key, a TEE's private key, or a TAM's
        private key.
      </t>

      <t>The main OTrP component consists of a set of standard JSON messages
        created by a TAM to deliver device SD and TA management commands to a
        device, and device attestation and response messages created by a TEE
        that responds to a TAM's OTrP message.
      </t>

      <t>The communication method of OTrP Messages between a TAM and TEE in a
      device may vary between TAM and TEE providers. A mandatory
      transport protocol is specified for a compliant TAM and a device TEE.
      </t>

      <t>An OTrP Broker is used to bridge communication between a TAM
      and a TEE. The OTrP Broker doesn't need to know the actual content of OTrP
      Messages except for the TEE routing information.
      </t>

      <section anchor="setupflow" title="A Sample Device Setup Flow">
          <t>Step 1: Prepare Images for Devices
            <list hangIndent="2" style="numbers">
              <t>[TEE vendor] Deliver TEE Image (CODE Binary) to device OEM</t>
              <t>[CA]         Deliver root CA Whitelist</t>
              <t>[Soc]        Deliver TFW Image</t>
            </list>
          </t>
          <t></t>

          <t>Step 2: Inject Key Pairs and Images to Devices
            <list hangIndent="2" style="numbers">
              <t>[OEM] Generate Secure Boot Key Pair
                       (May be shared among multiple devices)</t>
              <t>[OEM] Flash signed TFW Image and signed TEE Image
                       onto devices (signed by Secure Boot Key)</t>
            </list>
          </t>
          <t></t>

          <t>Step 3: Setup attestation key pairs in devices
            <list hangIndent="2" style="numbers">
              <t>[OEM]     Flash TFW Public Key and a bootloader key.</t>
              <t>[TFW/TEE] Generate a unique attestation key pair and
                           get a certificate for the device.</t>
            </list>
          </t>
          <t></t>

          <t>Step 4: Setup trust anchors in devices
            <list hangIndent="2" style="numbers">
              <t>[TFW/TEE] Store the key and certificate encrypted
                           with the eFuse key</t>
              <t>[TEE vendor or OEM] Store trusted CA certificate list
                           into devices</t>
            </list>
          </t>

      </section>

      <section anchor="derivedkeys" title="Derived Keys in The Protocol">
        <t>
          The protocol generates one key pair in run time to
          assist message communication and anonymous verification between
          a TAM and a TEE.
        </t>

        <t>
          TEE SP Anonymous Key (AIK): one derived key pair per SP in a device
        </t>
        <t>
          The purpose of the key pair is to sign data by a TEE without
          using its TEE device key for anonymous attestation to a Client
          Application. This key pair is generated in the first SD
          creation for an SP. It is deleted when all SDs are removed for a
          SP in a device.

          The public key of the key pair is given to the caller Client
          Application and TAM for future TEE returned data validation.
          The public key of this AIK is also used by a TAM to encrypt TA
          binary data and personalization data when it sends a TA to a
          device for installation.
        </t>
      </section>

      <section anchor="sdtree" title="Security Domain Hierarchy and Ownership">
        <t>
          The primary job of a TAM is to help an SP to manage its trusted
          application components. A TA is typically installed in an SD.
          An SD is commonly created for an SP.
        </t>
        <t>
          When an SP delegates its SD and TA management to a TAM, an SD is
          created on behalf of a TAM in a TEE and the owner of the SD is
          assigned to the TAM. An SD may be associated with an SP but the TAM
          has full privilege to manage the SD for the SP.
        </t>
        <t>
          Each SD for an SP is associated with only one TAM. When an SP changes
          TAM, a new SP SD must be created to associate with the new TAM. The
          TEE will maintain a registry of TAM ID and SP SD ID mapping.
        </t>
        <t>
          From an SD ownership perspective, the SD tree is flat and there is
          only one level. An SD is associated with its owner. It is up to TEE
          implementation how it maintains SD binding information for a TAM and
          different SPs under the same TAM.
        </t>
        <t>
          It is an important decision in this protocol specification that a TEE
          doesn't need to know whether a TAM is authorized to manage the SD for
          an SP. This authorization is implicitly triggered by an SP Client
          Application, which instructs what TAM it wants to use. An SD is always
          associated with a TAM in addition to its SP ID. A rogue TAM isn't
          able to do anything on an unauthorized SP's SD managed by another TAM.
        </t>
        <t>
          Since a TAM may support multiple SPs, sharing the same SD name for
          different SPs creates a dependency in deleting an SD. An SD can be
          deleted only after all TAs associated with this SD is deleted. An SP
          cannot delete a Security Domain on its own with a TAM if a TAM
          decides to introduce such sharing. There are cases where multiple
          virtual SPs belong to the same organization, and a TAM chooses to use
          the same SD name for those SPs. This is totally up to the TAM
          implementation and out of scope of this specification.
        </t>
      </section>

      <section anchor="sdownerid"
        title="SD Owner Identification and TAM Certificate Requirements">
        <t>
          There is a need of cryptographically binding proof about the owner of
          an SD in a device. When an SD is created on behalf of a TAM, a future
          request from the TAM must present itself as a way that the TEE can
          verify it is the true owner. The certificate itself cannot reliably
          used as the owner because TAM may change its certificate.
        </t>
        <t>
          To this end, each TAM will be associated with a trusted identifier
          defined as an attribute in the TAM certificate. This field is kept
          the same when the TAM renew its certificates. A TAM CA is responsible
          to vet the requested TAM attribute value.
        </t>
        <t>
          This identifier value must not collide among different TAM providers,
          and one TAM shouldn't be able to claim the identifier used by another
          TAM provider.
        </t>
        <t>
          The certificate extension name to carry the identifier can initially
          use SubjectAltName:registeredID. A dedicated new extension name may
          be registered later.
        </t>
        <t>
          One common choice of the identifier value is the TAM's service URL. A
          CA can verify the domain ownership of the URL with the TAM in the
          certificate enrollment process.
        </t>
        <t>
          A TEE can assign this certificate attribute value as the TAM owner ID
          for the SDs that are created for the TAM.
        </t>
        <t>
          An alternative way to represent an SD ownership by a TAM is to have a
          unique secret key upon SD creation such that only the creator TAM is
          able to produce a Proof-of-Possession (POP) data with the secret.
        </t>
      </section>

      <section anchor="spcontainer" title="Service Provider Container">
        <t>A sample Security Domain hierarchy for the TEE is shown below.
        </t>

        <t>
            <figure>
              <artwork><![CDATA[
    ----------
    |  TEE   |
    ----------
        |
        |          ----------
        |----------| SP1 SD1 |
        |          ----------
        |          ----------
        |----------| SP1 SD2 |
        |          ----------
        |          ----------
        |----------| SP2 SD1 |
                   ----------
             ]]></artwork>
            </figure>
        </t>
        <t>OTrP segregates SDs and TAs such that a TAM can only manage or
          retrieve data for SDs and TAs that it previously created for the
          SPs it represents.
        </t>
      </section>
    </section>

    <section anchor="otrpbroker" title="OTrP Broker">
      <t>A TEE and TAs that run inside the TEE don't generally have capability
        to communicate to the outside of the hosting device, for example,
        the TEE specified by Global Platform groups <xref target="GPTEE"/>.
        This calls for a software module in the REE world to handle the
        network communication. Each Client Application in REE may carry
        this communication functionality but it must also interact with
        the TEE for the message exchange. The TEE interaction will vary
        according to different TEEs. In order for a Client Application
        to transparently support different TEEs, it is imperative to have
        a common interface for a Client Application to invoke for exchanging
        messages with TEEs.
      </t>
      <t>A shared OTrP Broker comes to meed this need. An OTrP Broker is a
      Rich Application or SDK that facilitates communication between a TAM
      and TEE. It also provides interfaces for TAM SDK or Client Applications
      to query and trigger TA installation that the application needs to use.
      </t>
      <t>
        This interface for Client Applications may be commonly an Android
        service call for an Android powered device. A Client Application
        interacts with a TAM, and turns around to pass messages received
        from TAM to OTrP Broker.
      </t>
      <t>In all cases, a Client Application needs to be able to identify an
      OTrP Broker that it can use.
      </t>
      <section anchor="brokerrole" title="Role of OTrP Broker">
        <t> An OTrP Broker abstracts the message exchanges
          with the TEE in a device. The input data is originated from a TAM
          that a Client Application connects. A Client Application may also
          directly call OTrP Broker for some TA query functions.
        </t>
        <t>
          OTrP Broker may internally process a request from TAM. At least, it
          needs to know where to route a message, e.g. TEE instance. It doesn't
          need to process or verify message content.
        </t>
        <t>
          OTrP Broker returns TEE / TFW generated response messages to the
          caller. OTrP Broker isn't expected to handle any network connection
          with an application or TAM.
        </t>
        <t>
          OTrP Broker only needs to return an OTrP Broker error message if the
          TEE is not reachable for some reason. Other errors are represented
          as response messages returned from the TEE which will then be
          passed to the TAM.
        </t>
      </section>

      <section anchor="brokergp" title="OTrP Broker and Global Platform TEE Client API">
        <t>A Client Application may use Global Platform (GP) TEE API for TA
          communication. OTrP may use the GP TEE Client API but it is
          internal to OTrP implementation that converts given messages from
          TAM. More details can be found at <xref target="GPTEECLAPI"/>.
        </t>
      </section>

      <section anchor="brokerimpl" title="OTrP Broker Implementation Consideration">
        <t>A Provider should consider methods of distribution, scope and
          concurrency on device and runtime options when implementing an OTrP
          Broker. Several non-exhaustive options are discussed below. Providers
          are encouraged to take advantage of the latest communication and
          platform capabilities to offer the best user experience.
        </t>
        <section title="OTrP Broker Distribution">
          <t>
            OTrP Broker installation is commonly carried out at OEM time. A
            user can
            dynamically download and install an OTrP Broker on-demand.
          </t>
          <t>
            It is important to ensure a legitimate OTrP Broker is installed and
            used. If an OTrP Broker is compromised it may send rogue messages to
            TAM and TEE and introduce additional risks.
          </t>
        </section>
        <section title="Number of OTrP Broker">
          <t>
            We anticipate only one shared OTrP Broker instance in a device. The
            device's TEE vendor will most probably supply one OTrP Broker.
            Potentially we expect some open source.
          </t>
          <t>
            With one shared OTrP Broker, the OTrP Broker provider is responsible
            to allow multiple TAMs and TEE providers to achieve
            interoperability. With a standard OTrP Broker interface, TAM can
            implement its own SDK for its SP Client Applications to work with
            this OTrP Broker.
          </t>
          <t>
            Multiple independent OTrP Broker providers can be used as long as
            they have standard interface to a Client Application or TAM SDK.
            Only one OTrP Broker is expected in a device.
          </t>
          <t>
            TAM providers are generally expected to provide SDK for SP
            applications to interact with an OTrP Broker for the TAM and TEE
            interaction.
          </t>
        </section>
      </section>

      <section anchor="brokerapi" title="OTrP Broker Interfaces for Client Applications">
        <t>A Client Application shall be responsible for relaying
           messages between the OTrP Broker and the TAM.
        </t>
        <t>
          If a failure occurs during calling OTrP Broker, an error message
          described in "Common Errors" section (see <xref target="commerr"></xref>)
          will be returned.
        </t>

        <section anchor="brokerproc" title="ProcessOTrPMessage call">
          <t>
            Description
            <list hangIndent="4" style="empty">
              <t>
                A Client Application will use this method of the OTrP Broker in
                a device to pass OTrP messages from a TAM. The method is
                responsible for interacting with the TEE and for forwarding the
                input message to the TEE. It also returns TEE generated response
                message back to the Client Application.
              </t>
            </list>
          </t>
          <t>
            Inputs:
            <list hangIndent="4" style="empty">
              <t>TAMInMsg - OTrP message generated in a TAM that is passed to
              this method from a Client Application.
              </t>
            </list>
          </t>

          <t>
            Outputs:
            <list hangIndent="4" style="empty">
              <t>A TEE-generated OTrP response message (which may be a
                 successful response or be a response message containing
                 an error raised within the TEE) for the client application
                 to forward to the TAM. In the event of the OTrP Broker not
                 being able to communicate with the TEE, a
                 OTrPBrokerException shall be thrown.
              </t>
            </list>
          </t>
        </section>

        <section anchor="brokertaapi" title="GetTAInformation call">
          <t>
            Description
            <list hangIndent="4" style="empty">
              <t>
              A Client Application may quickly query local TEE about a
              previously installed TA without requiring TAM each time if it
              has had the TA's identifier and previously saved TEE SP AIK
              public key for TA information integrity verification.
              </t>
          </list>
        </t>
        <t>
          Inputs:
          <figure>
            <artwork><![CDATA[
      {
        "TAQuery": {
            "spid": "<SP identifier value of the TA>",
            "taid": "<The identifier value of the TA>"
        }
      }
      ]]></artwork>
             </figure>
         </t>
          <t>
            Outputs:
            <list hangIndent="4" style="empty">
              <t>
                The OTrP Broker is expected to return TA signer and TAM
                signer certificate along with other metadata information
                about the TA associated with the given identifier.

                It follows the underlying TEE trust model for authoring the
                local TA query from a Client Application.
              </t>
              <t>
                The output is a JSON message that is generated by the TEE. It
                contains the following information:
                <list hangIndent="2" style="symbols">
                  <t>tamid</t>
                  <t>SP ID</t>
                  <t>TA signer certificate</t>
                  <t>TAM certificate</t>
                </list>
                The message is signed with TEE SP AIK private key.
              </t>
              <t>
                The Client Application is expected to consume the response as
                follows.
              </t>
              <t>
                The Client Application gets signed TA metadata, in
                particular, the TA signer certificate. It is able to verify
                that the result is from device by checking signer against TEE
                SP AIK public key it gets in some earlier interaction with TAM.
              </t>
              <t>
                If this is a new Client Application in the device that hasn't
                had TEE SP AIK public key for the response verification, the
                application can contact the TAM first to do GetDeviceState, and
                TAM will return TEE SP AIK public key to the app for this
                operation to proceed.
              </t>
              <t>
                Output Message:
                <figure>
                  <artwork><![CDATA[
      {
        "TAInformationTBS": {
          "taid": "<TA Identifier from the input>",
          "tamid": "<TAM ID for the Security Domain where this TA
                    resides>",
          "spid": "<The service provider identifier of this TA>",
          "signercert": "<The BASE64 encoded certificate data of the
                         TA binary application's signer certificate>",
          "signercacerts": [ < The full list of CA certificate chain
                             including the root CA>
          ],
          "cacert": "<The BASE64 encoded CA certificate data of the TA
                         binary application's signer certificate>"
          ],
          "tamcert": "<The BASE64 encoded certificate data of the TAM
                       that manages this TA.>",
          "tamcacerts": [ < The full list of CA certificate chain
                            including the root CA>
          ],
          "cacert":"<The BASE64 encoded CA certificate data of the TAM
                        that manages this TA>"
          ]
        }
      }

      {
        "TAInformation": {
            "payload": "<The BASE64URL encoding of the TAInformationTBS
                        JSON above>",
            "protected": "<BASE64URL encoded signing algorithm>",
            "header": {
                "signer": {"<JWK definition of the TEE SP AIK public
                            key>"}
            },
            "signature": "<signature contents signed by TEE SP AIK
                          private key BASE64URL encoded>"
        }
      }
]]></artwork>
                </figure>

              where the definitions of BASE64 and BASE64URL refer to
              <xref target="RFC4648"/>.
              </t>
              <t>
                A sample JWK public key representation refers to an example in
                <xref target="RFC7517"/>.
              </t>
            </list>
          </t>
        </section>
      </section>

      <section anchor="brokeruse" title="Sample End-to-End Client Application Flow">
        <section title="Case 1: A New Client Application Uses a TA">
          <t>
            <list style="numbers">
              <t>
                During the Client Application installation time, the Client
                Application calls TAM to initialize the device preparation step.
                <list style="letters">
                  <t>The Client Application knows it wants to use a Trusted
                    Application TA1 but the application doesn't know whether
                    TA1 has been installed or not. It can use
                    <xref target="GPTEECLAPI">GP TEE Client API </xref> to
                    check the existence of TA1 first. If it detects
                    that TA1 doesn't exist, it will contact TAM to initiate
                    the installation of TA1. Note that TA1 could have been
                    previously installed by other Client Applications from
                    the same service provider in the device.
                  </t>
                  <t>The Client Application sends the TAM the TA list that it
                    depends on. The TAM will query a device for the Security
                    Domains and TAs that have been installed, and instructs
                    the device to install any dependent TAs that have not been
                    installed.
                  </t>
                  <t>In general, the TAM has the latest TA list and
                    their status in a device because all operations are
                    instructed by TAM. TAM has such visibility because all
                    Security Domain deletion and TA deletion are managed by
                    the TAM; the TAM could have stored the state when a TA is
                    installed, updated and deleted. There is also the
                    possibility that an update
                    command is carried out inside TEE but a response is never
                    received in TAM. There is also possibility that some manual
                    local reset is done in a device that the TAM isn't aware of
                    the changes.
                  </t>
                </list>
              </t>
              <t>The TAM generates message: GetDeviceStateRequest
              </t>
              <t>The Client Application passes the JSON message GetDeviceStateRequest
                to OTrP Broker call ProcessOTrPMessage. The communication between a
                Client Application and an OTrP Broker is up to the implementation
                of the OTrP Broker.
              </t>
              <t>The OTrP Broker routes the message to the active TEE.
                Multiple TEE case: it is up to OTrP Broker to figure this out.
                This specification limits the support to only one active TEE,
                which is the typical case today.
              </t>
              <t>The target active TEE processes the received OTrP message, and
                returns a JSON message GetDeviceStateResponse.
              </t>
              <t>The OTrP Broker passes the GetDeviceStateResponse to the Client
                Application.
              </t>
              <t>The Client Application sends GetDeviceStateResponse to the TAM.
              </t>
              <t>
                The TAM processes the GetDeviceStateResponse.
                <list style="letters">
                  <t>Extract TEEspaik for the SP, signs TEEspaik with TAM
                    signer key
                  </t>
                  <t>Examine SD list and TA list</t>
                </list>
              </t>
              <t>
                The TAM continues to carry out other actions based on the need.
                The next call could be instructing the device to install a
                dependent TA.
                <list style="letters">
                  <t>Assume a dependent TA isn't in the device yet, the TAM
                    may do the following: (1) create an SD in which to install
                    the TA by sending a CreateSDRequest message. The message
                    is sent back to the Client Application, and then
                    the OTrP Broker and TEE to process; (2) install a TA with
                    an InstallTARequest message.
                  </t>
                  <t>If a Client Application depends on multiple TAs, the Client
                    Application should expect multiple round trips of the TA
                    installation message exchanges.
                  </t>
                </list>
              </t>
              <t>At the last TAM and TEE operation, the TAM returns the signed
                TEE SP AIK public key to the application.
              </t>
              <t>The Client Application stores the TEEspaik for future
                loaded TA trust check.
              </t>
              <t>If the TAM finds that this is a fresh device that does not
                have any SD for the SP yet, then the TAM may next
                create an SD for the SP.
              </t>
              <t>During Client Application installation, the application
                checks whether required Trusted Applications are already
                installed, which may have been provided by the TEE. If needed,
                it will contact its TAM service to determine whether the
                device is ready or install TA list that this application
                needs.
              </t>
            </list>
          </t>
        </section>

        <section title="Case 2: A Previously Installed Client Application Calls a TA">
          <t>
            <list style="numbers">
              <t>The Client Application checks the device readiness:
                (a) whether it has a TEE; (b) whether it has TA that it depends.
                It may happen that TAM has removed the TA this application
                depends on.
              </t>
              <t>The Client Application calls the OTrP Broker to query the TA.
              </t>
              <t>The OTrP Broker queries the TEE to get TA information. If the
                given TA doesn't exist, an error is returned.
              </t>
              <t>The Client Application parses the TAInformation message.
              </t>
              <t>If the TA doesn't exist, the Client Application calls its TAM to
                install the TA. If the TA exists, the Client Application proceeds
                 to call the TA.
              </t>
            </list>
          </t>
        </section>
      </section>
    </section>

    <section anchor="messages" title="OTrP Messages">
      <t>The main OTrP component is the set of standard JSON messages
        created by a TAM to deliver device SD and TA management commands to a
        device, and device attestation and response messages created by TEE to
        respond to TAM OTrP Messages.
      </t>
      <t>
        An OTrP Message is designed to provide end-to-end security. It is always
        signed by its creator. In addition, an OTrP Message is typically
        encrypted such that only the targeted device TEE or TAM is able
        to decrypt and view the actual content.
      </t>
      <section anchor="format" title="Message Format">
        <t>OTrP Messages use the JSON format for JSON's simple readability and
          moderate data size in comparison with alternative TLV and XML
          formats. More compact CBOR format may be used as an alternative
          choice.
        </t>
        <t>
          JSON Message security has developed JSON Web Signing and JSON Web
          Encryption
          standard in the IETF Workgroup JOSE, see JWS <xref target="RFC7515"/>
          and JWE <xref target="RFC7516"/>.
          The OTrP Messages in this protocol will leverage the basic JWS and JWE
          to handle JSON signing and encryption.
        </t>
      </section>

      <section anchor="convention" title="Message Naming Convention">
        <t>For each TAM command "xyz"", OTrP use the following naming
          convention to represent its raw message content and complete request
          and response messages:
        </t>
        <texttable>
          <ttcol align="left">Purpose</ttcol>
          <ttcol align="left">Message Name</ttcol>
          <ttcol align="left">Example</ttcol>

          <c>Request to be signed</c>
          <c>xyzTBSRequest</c>
          <c>CreateSDTBSRequest</c>

          <c>Request message</c>
          <c>xyzRequest</c>
          <c>CreateSDRequest</c>

          <c>Response to be signed</c>
          <c>xyzTBSResponse</c>
          <c>CreateSDTBSResponse</c>

          <c>Response message</c>
          <c>xyzResponse</c>
          <c>CreateSDResponse</c>
        </texttable>

      </section>

      <section anchor="template" title="Request and Response Message Template">
        <figure>
          <preamble>An OTrP Request message uses the following format:
          </preamble>

          <artwork><![CDATA[
  {
    "<name>TBSRequest": {
      <request message content>
    }
  }
           ]]></artwork>
        </figure>

        <figure>
          <preamble>A corresponding OTrP Response message will be as follows.
          </preamble>

          <artwork><![CDATA[
  {
    "<name>TBSResponse": {
      <response message content>
    }
  }
           ]]></artwork>
        </figure>

      </section>

      <section anchor="signedmsg" title="Signed Request and Response Message Structure">
        <t>
          A signed request message will generally include only one signature,
          and uses the flattened JWS JSON Serialization Syntax, see Section
          7.2.2 in <xref target="RFC7515"/>.
        </t>
        <figure>
          <preamble>A general JWS object looks like the following.
          </preamble>

          <artwork><![CDATA[
{
  "payload": "<payload contents>",
  "protected": "<integrity-protected header contents>",
  "header": {
    <non-integrity-protected header contents>,
  },
  "signature": "<signature contents>"
}
           ]]></artwork>
        </figure>

        <t>OTrP signed messages only require the signing algorithm as the
          mandate header in the property "protected". The
          "non-integrity-protected header contents" is optional.
        </t>
        <t>
          OTrP signed message will be given an explicit Request or Response
          property
          name. In other words, a signed Request or Response uses the
          following
          template.
        </t>
        <figure>
          <preamble>A general JWS object looks like the following.
          </preamble>

          <artwork><![CDATA[
{
  "<name>[Request | Response]": {
    <JWS Message of <name>TBS[Request | Response]
  }
}
           ]]></artwork>
        </figure>

        <t>With the standard JWS message format, a signed OTrP Message looks
          like the following.
        </t>
        <figure>
          <artwork><![CDATA[
{
  "<name>[Request | Response]": {
    "payload": "<payload contents of <name>TBS[Request | Response]>",
    "protected": "<integrity-protected header contents>",
    "header":  <non-integrity-protected header contents>,
    "signature": "<signature contents>"
  }
}
           ]]></artwork>
        </figure>

        <t>
          The top element "&lt;name&gt;[Signed][Request|Response]" cannot be
          fully trusted to match the content because it doesn't participate
          in the signature generation. However, a recipient can always match
          it with the value associated with the property "payload". It
          purely serves to provide a quick reference for reading and
          method invocation.
        </t>
        <t>Furthermore, most properties in an unsigned OTrP messages are
          encrypted to provide end-to-end confidentiality. The only OTrP message
          that isn't encrypted is the initial device query message that asks
          for the device state information.
        </t>
        <t>Thus a typical OTrP Message consists of an encrypted and then signed
          JSON message. Some transaction data such as transaction ID and TEE
          information may need to be exposed to the OTrP Broker for routing
          purpose. Such information is excluded from JSON encryption.
          The device's signer certificate itself is encrypted. The overall
          final message is a standard signed JSON message.
        </t>
        <t>As required by JSW/JWE, those JWE and JWS related elements will be
          BASE64URL encoded. Other binary data elements specific to the OTrP
          specification are BASE64-encoded. This specification indicates
          elements that should be BASE64 and those elements that are to be
          BASE64URL encoded.
        </t>

        <section
          title="Identifying Signing and Encryption Keys for JWS/JWE Messaging">
          <t>
            JWS and JWE messaging allow various options for identifying the
            signing and encryption keys, for example, it allows optional
            elements including "x5c", "x5t" and "kid" in the header to cover
            various possibilities.
          </t>
          <t>
            To protect privacy, it is important that the device's
            certificate is released only to a trusted TAM, and that it is
            encrypted. The TAM will need to know the device certificate, but
            untrusted parties must not be able to get the device certificate.
            All OTrP messaging conversations between a TAM and device begin
            with GetDeviceStateRequest / GetDeviceStateResponse. These messages
            have elements built into them to exchange signing certificates,
            described in the section <xref target="detailmsg"/>. Any
            subsequent messages in the conversation that follow on from this
            implicitly use the same certificates for signing/encryption,
            and as a result the certificates or references
            may be omitted in those subsequent messages.
          </t>
          <t>
            In other words, the signing key identifier in the use of JWS and
            JWE here may be absent in the subsequent messages after the
            initial GetDeviceState query.
          </t>
          <t>
            This has an implication on the TEE and TAM implementation: they
            have to cache the signer certificates for the subsequent
            message signature validation in the session. It may be easier
            for a TAM service to cache transaction session information
            but not so for a TEE in a device. A TAM can get a
            device's capability by checking the response message from a TEE
            to decide whether it should include its TAM signer certificate
            and OCSP data in each subsequent request message. The device's
            caching capability is reported
            in GetDeviceStateResponse signerreq parameter.
          </t>
        </section>
      </section>

      <section title="JSON Signing and Encryption Algorithms">
        <t>
          The OTrP JSON signing algorithm shall use SHA256 or a stronger
          hash method with respective key type. JSON Web Algorithm RS256
          or ES256 <xref target="RFC7518"/> SHALL be used for RSA with SHA256 and
          ECDSA with SHA256. If RSA with SHA256 is used, the JSON web
          algorithm representation is as follows.
        </t>

        <t>
          <list hangIndent="4" style="empty">
            <t>{"alg":"RS256"}</t>
          </list>
        </t>

        <t>
          The (BASE64URL encoded) "protected" header property in a signed
          message looks like the following:
          <list hangIndent="4" style="empty">
            <t>"protected":"eyJhbGciOiJSUzI1NiJ9"</t>
          </list>
        </t>

        <t>
          If ECSDA with P-256 curve and SHA256 are used for signing, the JSON
          signing algorithm representation is as follows.

          <list hangIndent="4" style="empty">
            <t>{"alg":"ES256"}</t>
          </list>
        </t>

        <t>
          The value for the "protected" field will be the following.
          <list hangIndent="4" style="empty">
            <t>eyJhbGciOiJFUzI1NiJ9</t>
          </list>
        </t>

        <figure>
          <preamble>Thus, a common OTrP signed message with ES256 looks like the
            following.
          </preamble>
          <artwork><![CDATA[
  {
    "payload": "<payload contents>",
    "protected": "eyJhbGciOiJFUzI1NiJ9",
    "signature": "<signature contents>"
  }
           ]]></artwork>
        </figure>

        <t>The OTrP JSON message encryption algorithm SHOULD use one of the
          supported algorithms defined in the later chapter of this document.
          JSON encryption uses a symmetric key as its "Content Encryption Key
          (CEK)". This CEK is encrypted or wrapped by a recipient's key.
          The OTrP recipient typically has an asymmetric key pair. Therefore,
          the CEK will be encrypted by the recipient's public key.
        </t>

        <t>
          A compliant implementation shall support the following symmetric
          encryption algorithm and anticipate future new algorithms.
          <list hangIndent="4" style="empty">
            <t>{"enc":"A128CBC-HS256"}</t>
          </list>
        </t>

        <t>
          This algorithm represents encryption with AES 128 in CBC mode with
          HMAC SHA 256 for integrity. The value of the property "protected" in
          a JWE message will be
          <list hangIndent="4" style="empty">
            <t>eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0</t>
          </list>
        </t>

        <figure>
          <preamble>An encrypted JSON message looks like the following.
          </preamble>

          <artwork><![CDATA[
  {
    "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
     "recipients": [
        {
            "header": {
                "alg": "<RSA1_5 etc.>"
            },
            "encrypted_key": "<encrypted value of CEK>"
        }
    ],
    "iv": "<BASE64URL encoded IV data>",
    "ciphertext": "<Encrypted data over the JSON plaintext
                   (BASE64URL)>",
    "tag": "<JWE authentication tag (BASE64URL)>"
  }
           ]]></artwork>
        </figure>

        <t>OTrP doesn't use JWE AAD (Additional Authenticated Data) because
          each message is always signed after the message is encrypted.
        </t>

        <section anchor="signalgs" title="Supported JSON Signing Algorithms">
          <t>
            The following JSON signature algorithm is mandatory support in
            the TEE and TAM:
            <list hangIndent="4" style="symbols">
              <t>RS256</t>
            </list>
          </t>
          <t>ES256 is optional to support.
          </t>
        </section>

        <section anchor="encalgs" title="Support JSON Encryption Algorithms">
          <t>
            The following JSON authenticated encryption algorithm is mandatory
            support in TEE and TAM.
            <list hangIndent="4" style="symbols">
              <t>A128CBC-HS256</t>

            </list>
          </t>
              <t>A256CBC-HS512 is optional to support.</t>
        </section>

        <section anchor="kmalgs" title="Supported JSON Key Management Algorithms">
          <t>
            The following JSON key management algorithm is mandatory
            support in TEE and TAM.
            <list hangIndent="4" style="symbols">
              <t>RSA1_5</t>
            </list>
          </t>

          <t>ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support.</t>
        </section>

      </section>

      <section anchor="commerr" title="Common Errors">
        <t>
          An OTrP Response message typically needs to report the operation
          status and error causes if an operation fails. The following JSON
          message elements should be used across all OTrP Messages.
        </t>

        <figure>
          <artwork><![CDATA[
"status": "pass | fail"

 "reason": {
     "error-code": "<error code if there is any>",
     "error-message": "<error message>"
  }

"ver": "<version string>"
           ]]></artwork>
        </figure>

      </section>

      <section title="OTrP Message List">
        <t>
          The following table lists the OTrP commands and therefore
          corresponding Request and Response messages defined in this
          specification. Additional messages may be added in the future
          when new task messages are needed.
        </t>
        <t>
          <list hangIndent="4" style="hanging">
            <t hangText="GetDeviceState - ">
              <vspace blankLines="0" />
              A TAM queries a device's current state with a message
              GetDeviceStateRequest. A device TEE will report its
              version, its FW version, and list of all SDs and TAs in the
              device that is managed by the requesting TAM. TAM may
              determine whether the device is trustworthy and decide to
              carry out additional commands according to the response
              from this query.
            </t>
            <t hangText="CreateSD - ">
              <vspace blankLines="0" />
              A TAM instructs a device TEE to create an SD for an SP. The
              recipient TEE will check whether the requesting TAM is
              trustworthy.
            </t>
            <t hangText="UpdateSD - ">
              <vspace blankLines="0" />
              A TAM instructs a device TEE to update an existing SD. A
              typical update need comes from SP certificate change, TAM
              certificate change and so on. The recipient TEE will verify
              whether the TAM is trustworthy and owns the SD.
            </t>
            <t hangText="DeleteSD - ">
              <vspace blankLines="0" />
              A TAM instructs a device TEE to delete an existing SD. A
              TEE conditionally deletes TAs loaded in the SD according to
              a request parameter. An SD cannot be deleted until all TAs
              in this SD are deleted. If this is the last SD for an SP,
              TEE MAY also delete TEE SP AIK key for this SP.
            </t>
            <t hangText="InstallTA - ">
              <vspace blankLines="0" />
              A TAM instructs a device to install a TA into an SD for a
              SP. The TEE in a device will check whether the TAM and TA are
              trustworthy.
            </t>
            <t hangText="UpdateTA - ">
              <vspace blankLines="0" />
              A TAM instructs a device to update a TA into an SD for an SP.
              The change may commonly be bug fix for a previously
              installed TA.
            </t>
            <t hangText="DeleteTA - ">
              <vspace blankLines="0" />
              A TAM instructs a device to delete a TA. The TEE in a device
              will check whether the TAM and TA are trustworthy.
            </t>
          </list>
        </t>
      </section>

      <section title="OTrP Request Message Routing Rules">
        <t>
          For each command that a TAM wants to send to a device, the TAM
          generates a request message. This is typically triggered by a
          Client Application that uses the TAM. The Client Application
          initiates contact with the TAM and receives TAM OTrP Request
          messages according to the TAM's implementation. The Client
          Application forwards the OTrP message to an OTrP Broker in the
          device, which in turn sends the message to the active TEE in
          the device.
        </t>
        <t>The current version of this specification assumes that each device has
          only one active TEE, and the OTrP Broker is responsible to connect to
          the active TEE. This is the case today with devices in the market.
        </t>
        <t>When the TEE responds to a request, the OTrP Broker gets the OTrP
          response messages back to the Client Application that sent the
          request. In case the target TEE fails to respond to the request, the
          OTrP Broker will be responsible to generate an error message to reply
          the Client Application. The Client Application forwards any data it
          received to its TAM.
        </t>

        <section title="SP Anonymous Attestation Key (SP AIK)">
          <t>When the first new Security Domain is created in a TEE for an SP,
            a new key pair is generated and associated with this SP. This
            key pair is used for future device attestation to the service
            provider instead of using the device's TEE key pair.
          </t>
        </section>
      </section>
    </section>

    <section anchor="transport" title="Transport Protocol Support">
      <t>The OTrP message exchange between a TEE device and TAM generally
        takes place between a Client Application in REE and TAM. A device that
        is capable to run a TEE and PKI based cryptographic attestation isn't
        generally resource constraint to carry out standard HTTPS connections.
        A compliant device and TAM SHOULD support HTTPs.
      </t>
    </section>

    <section anchor="detailmsg" title="Detailed Messages Specification">
      <t>For each message in the following sections all JSON elements are
        mandatory if not explicitly indicated as optional.
      </t>
      <section anchor="getdevicestate" title="GetDeviceState">
        <t>
          This is the first command that a TAM will send to a device. This
          command is triggered when an SP's Client Application contacts
          its TAM to check whether the underlying device is ready for TA
          operations.
        </t>
        <t>
          This command queries a device's current TEE state. A device TEE
          will report its version, its FW version, and list of all SDs and
          TAs in the device that is managed by the requesting TAM. TAM may
          determine whether the device is trustworthy and decide to carry
          out additional commands according to the response from this
          query.
        </t>
        <t>
          The request message of this command is signed by the TAM. The
          response message from the TEE is encrypted. A random message
          encryption key (MK) is generated by TEE, and this encrypted key
          is encrypted by the TAM's public key such that only the TAM that
          sent the request is able to decrypt and view the response
          message.
        </t>

        <section anchor="getdsreq" title="GetDeviceStateRequest message">

          <figure>
            <artwork><![CDATA[
{
   "GetDeviceStateTBSRequest": {
      "ver": "1.0",
      "rid": "<Unique request ID>",
      "tid": "<transaction ID>",
      "ocspdat": [<a list of OCSP stapling data>"],
      "supportedsigalgs": [<array of supported signing algorithms>]
    }
}
           ]]></artwork>
          </figure>

          <t>
            The request message consists of the following data elements:
            <list hangIndent="4" style="hanging">
              <t hangText="ver - ">version of the message format</t>
              <t hangText="rid - ">a unique request ID generated by the TAM</t>
              <t hangText="tid - ">a unique transaction ID to trace request and
                response. This can be from a prior transaction's tid field, and
                can be used in  subsequent message exchanges in this TAM
                session. The combination of rid and tid MUST be made unique.
              </t>
              <t hangText="ocspdat - ">A list of OCSP stapling data respectively
                for the TAM certificate and each of the CA certificates up to
                the root certificate. The TAM provides OCSP data such that a
                recipient TEE can validate the TAM certificate chain revocation
                status without making its own external OCSP service call. A TEE
                MAY cache the CA OCSP data such that the array may contain only
                the OCSP stapling data for the TAM certificate in subsequent
                exchanges. This is a mandatory field.
              </t>
              <t hangText="supportedsigalgs - ">an optional property to list
                the signing algorithms that the TAM is able to support. A
                recipient TEE MUST choose an algorithm in this list to sign
                its response message if this property is present in a request.
                If it is absent, the TEE may use any compliant signing algorithm
                that is listed as mandatory support in this specification.
              </t>
            </list>
          </t>

          <figure>
            <preamble>The final request message is JSON signed message
            of the above raw JSON data with TAM's certificate.
            </preamble>

            <artwork><![CDATA[
{
  "GetDeviceStateRequest": {
    "payload": "<BASE64URL encoding of the GetDeviceStateTBSRequest
               JSON above>",
    "protected": "<BASE64URL encoded signing algorithm>",
    "header": {
        "x5c": "<BASE64 encoded TAM certificate chain up to the
                root CA certificate>"
    },
    "signature":"<signature contents signed by TAM private key>"
  }
}
          ]]></artwork>
          </figure>

          <t>The signing algorithm SHOULD use SHA256 with respective key
            type. The mandatory algorithm support is the RSA signing
            algorithm. The signer header "x5c" is used to include the TAM
            signer certificate up to the root CA certificate.
          </t>

        </section>

        <section title="Request processing requirements at a TEE">
          <t> Upon receiving a request message GetDeviceStateRequest at a
          TEE, the TEE MUST validate a request:

            <list hangIndent="2" style="numbers">
              <t>Validate JSON message signing. If it doesn't pass, an error
              message is returned.</t>
              <t>Validate that the request TAM certificate is chained to a
              trusted CA that the TEE embeds as its trust anchor.
                <list hangIndent="2" style="symbols">
                  <t>Cache the CA OCSP stapling data and certificate
                  revocation check status for other subsequent requests.
                  </t>
                  <t>A TEE can use its own clock time for the OCSP stapling
                  data validation. </t>
                </list></t>
              <t>Optionally collect Firmware signed data
                <list hangIndent="2" style="symbols">
                  <t>This is a capability in ARM architecture that allows a
                  TEE to query Firmware to get FW signed data. It isn't required
                  for all TEE implementations. When TFW signed data is absent,
                  it is up to a TAM's policy how it will trust a TEE.</t>
                </list></t>
              <t>Collect SD information for the SD owned by this TAM</t>
            </list>
          </t>
        </section>

        <section title="Firmware Signed Data">
          <t> Firmware isn't expected to process or produce JSON data. It
          is expected to just sign some raw bytes of data.</t>

          <t>The data to be signed by TFW key needs be some unique random
          data each time. The (UTF-8 encoded) "tid" value from the
          GetDeviceStateTBSRequest shall be signed by the firmware. TAM
          isn't expected to parse TFW data except the signature
          validation and signer trust path validation.
          </t>

          <t>It is possible that a TEE can get some valid TFW signed data
          from another device. The TEE is responsible to validate TFW integrity
          to ensure that the underlying device firmware is trustworthy. In
          some cases, a TEE isn't able to get a TFW signed data, in which
          case the TEE trust validation is up to a TAM to decide. A TAM
          may opt to trust a TEE basing on the TEE signer and additional
          information about a TEE out-of-band.
          </t>

          <t>When TFW signed data is available, a TAM validates the TEE and
            trusts that a trusted TEE has carried out appropriate trust check
            about a TFW.
          </t>

          <figure>
            <artwork><![CDATA[
  TfwData: {
       "tbs": "<TFW to be signed data, BASE64 encoded>",
       "cert": "<BASE64 encoded TFW certificate>",
       "sigalg": "Signing method",
       "sig": "<TFW signed data,  BASE64 encoded>"
  }
           ]]></artwork>
          </figure>

          <t>It is expected that a FW uses standard signature methods for
          maximal interoperability with TAM providers. The mandatory
          support list of signing algorithm is RSA with SHA256.
          </t>

          <t>The JSON object above is constructed by a TEE with data
          returned from the FW. It isn't a standard JSON signed object. The
          signer information and data to be signed must be specially
          processed by a TAM according to the definition given here. The data
          to be signed is the raw data.
          </t>

          <section title="Supported Firmware Signature Methods">
            <t>TAM providers shall support the following signature
            methods. A firmware provider can choose one of the methods in
            signature generation.
              <list hangIndent="2" style="symbols">
                <t>RSA with SHA256</t>
                <t>ECDSA with SHA 256</t>
              </list></t>

            <t>The value of "sigalg" in the TfwData JSON message SHOULD use
               one of the following:
              <list hangIndent="2" style="symbols">
                <t>RS256</t>
                <t>ES256</t>
              </list>
            </t>
          </section>
        </section>

        <section title="Post Conditions">
          <t>Upon successful request validation, the TEE information is
          collected. There is no change in the TEE in the device.
          </t>

          <t>The response message shall be encrypted where the encryption
          key shall be a symmetric key that is wrapped by TAM's public
          key. The JSON Content Encryption Key (CEK) is used for this
          purpose.
          </t>
        </section>

        <section anchor="getdsresp" title="GetDeviceStateResponse Message">
          <t>The message has the following structure.</t>
          <figure>
            <artwork><![CDATA[
  {
    "GetDeviceTEEStateTBSResponse": {
        "ver": "1.0",
        "status": "pass | fail",
        "rid": "<the request ID from the request message>",
        "tid": "<the transaction ID from the request message>",
        "signerreq": true | false // about whether TAM needs to send
                      signer data again in subsequent messages,
        "edsi": "<Encrypted JSON DSI information>"
    }
 }
           ]]></artwork>
          </figure>

          <t>
            where
            <list hangIndent="4" style="hanging">
              <t hangText="signerreq - ">true if the TAM should send its
              signer certificate and OCSP data again in the subsequent
              messages. The value may be "false" if the TEE caches the
              TAM's signer certificate and OCSP status.</t>
              <t hangText="rid - ">the request ID from the request message</t>
              <t hangText="tid - ">the tid from the request message</t>
              <t hangText="edsi - ">the main data element whose value is
              JSON encrypted message over the following Device State
              Information (DSI).</t>
            </list>
          </t>


          <t>The Device State Information (DSI) message consists of the
          following.</t>
<t>
          <figure>
            <artwork><![CDATA[
{
    "dsi": {
        "tfwdata": {
            "tbs": "<TFW to be signed data is the tid>"
            "cert": "<BASE64 encoded TFW certificate>",
            "sigalg": "Signing method",
            "sig": "<TFW signed data, BASE64 encoded>"
        },
        "tee": {
            "name": "<TEE name>",
            "ver": "<TEE version>",
            "cert": "<BASE64 encoded TEE cert>",
            "cacert": "<JSON array value of CA certificates up to
                        the root CA>",
            "sdlist": {
                "cnt": "<Number of SD owned by this TAM>",
                "sd": [
                    {
                        "name": "<SD name>",
                        "spid": "<SP owner ID of this SD>",
                        "talist": [
                          {
                             "taid": "<TA application identifier>",
                             "taname": "<TA application friendly
                                       name>" // optional
                          }
                        ]
                    }
                ]
            },
            "teeaiklist": [
                {
                    "spaik": "<SP AIK public key, BASE64 encoded>",
                    "spaiktype": "<RSA | ECC>",
                    "spid": "<sp id>"
                }
            ]
        }
    }
}
           ]]></artwork>
          </figure>
</t>

          <t>The encrypted JSON message looks like the following.</t>

          <figure>
            <artwork><![CDATA[
{
    "protected": "<BASE64URL encoding of encryption algorithm header
                   JSON data>",
    "recipients": [
        {
            "header": {
                "alg": "RSA1_5"
            },
            "encrypted_key": "<encrypted value of CEK>"
        }
    ],
    "iv": "<BASE64URL encoded IV data>",
    "ciphertext": "<Encrypted data over the JSON object of dsi
                    (BASE64URL)>",
    "tag": "<JWE authentication tag (BASE64URL)>"
}
           ]]></artwork>
          </figure>

          <t>Assume we encrypt plaintext with AES 128 in CBC mode with
          HMAC SHA 256 for integrity, the encryption algorithm header is:
            <list hangIndent="4" style="empty">
              <t>{"enc":"A128CBC-HS256"}</t>
            </list>
          </t>

          <t>The value of the property "protected" in the above JWE
          message will be
            <list hangIndent="4" style="empty">
              <t>eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0</t>
            </list>
          </t>

          <t>In other words, the above message looks like the following:</t>
          <figure>
            <artwork><![CDATA[
{
    "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
     "recipients": [
        {
            "header": {
                "alg": "RSA1_5"
            },
            "encrypted_key": "<encrypted value of CEK>"
        }
    ],
    "iv": "<BASE64URL encoded IV data>",
    "ciphertext": "<Encrypted data over the JSON object of dsi
                    (BASE64URL)>",
    "tag": "<JWE authentication tag (BASE64URL)>"
}
           ]]></artwork>
          </figure>

          <t>The full response message looks like the following:</t>
          <figure>
            <artwork><![CDATA[
{
  "GetDeviceTEEStateTBSResponse": {
    "ver": "1.0",
    "status": "pass | fail",
    "rid": "<the request ID from the request message>",
    "tid": "<the transaction ID from the request message>",
    "signerreq": "true | false",
    "edsi": {
      "protected": "<BASE64URL encoding of encryption algorithm
                     header JSON data>",
      "recipients": [
        {
          "header": {
            "alg": "RSA1_5"
          },
          "encrypted_key": "<encrypted value of CEK>"
        }
      ],
      "iv": "<BASE64URL encoded IV data>",
      "ciphertext": "<Encrypted data over the JSON object of dsi
                      (BASE64URL)>",
      "tag": "<JWE authentication tag (BASE64URL)>"
    }
  }
}
           ]]></artwork>
          </figure>

          <t>The CEK will be encrypted by the TAM public key in the
          device. The TEE signed message has the following structure.</t>
          <figure>
            <artwork><![CDATA[
{
  "GetDeviceTEEStateResponse": {
    "payload": "<BASE64URL encoding of the JSON message
                 GetDeviceTEEStateTBSResponse>",
    "protected": "<BASE64URL encoding of signing algorithm>",
    "signature": "<BASE64URL encoding of the signature value>"
  }
}
           ]]></artwork>
          </figure>

          <t>The signing algorithm shall use SHA256 with respective key
          type, see <xref target="signalgs"></xref>.
          </t>
          <t>The final GetDeviceStateResponse response message consists
          of an array of TEE responses.
          </t>

          <figure>
            <artwork><![CDATA[
{
    "GetDeviceStateResponse": [ // JSON array
       {"GetDeviceTEEStateResponse": ...},
       ...
       {"GetDeviceTEEStateResponse": ...}
    ]
}
           ]]></artwork>
          </figure>
        </section>

        <section title="Error Conditions">
          <t>An error may occur if a request isn't valid or the TEE runs
            into some error. The list of possible error conditions is the
            following.
            <list hangIndent="2" style="hanging">
            <t hangText="ERR_REQUEST_INVALID">The TEE meets the following
            conditions with a request message: (1) The request from a TAM
            has an invalid message structure; mandatory information is
            absent in the message; or an undefined member or structure is
            included.  (2) TEE fails to verify the signature of the message
            or fails to decrypt its contents.</t>
            <t hangText="ERR_UNSUPPORTED_MSG_VERSION">The TEE receives a
            version of message that the TEE can't deal with.</t>
            <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG">The TEE receives a
            request message encoded with a cryptographic algorithm that
            the TEE doesn't support.</t>
            <t hangText="ERR_TFW_NOT_TRUSTED">The TEE considers the
            underlying device firmware be not trustworthy.</t>
            <t hangText="ERR_TAM_NOT_TRUSTED">The TEE needs to make sure
            whether the TAM is trustworthy by checking the validity of
            the TAM certificate and OCSP stapling data and so on. If the TEE
            finds the TAM is not reliable, it returns this error code.</t>
            <t hangText="ERR_TEE_FAIL">If the TEE fails to
            process a request because of its internal error but is able
            to sign an error response message, it will return this error
            code.</t>
          </list></t>

          <t>The response message will look like the following if the TEE
          signing can work to sign the error response message.
          </t>
          <figure>
            <artwork><![CDATA[
  {
      "GetDeviceTEEStateTBSResponse": {
          "ver": "1.0",
          "status": "fail",
          "rid": "<the request ID from the request message>",
          "tid": "<the transaction ID from the request message>",
          "reason": {"error-code":"<error code>"}
          "supportedsigalgs": [<an array of signature algorithms that
                               the TEE supports>]
      }
  }
           ]]></artwork>
          </figure>

          <t>where
            <list hangIndent="4" style="hanging">
              <t hangText="supportedsigalgs -">an optional property to
              list the JWS signing algorithms that the active TEE
              supports. When a TAM sends a signed message that the TEE isn't
              able to validate, it can include signature algorithms that
              it is able to consume in this status report. A TAM can
              generate a new request message to retry the management task
              with a TEE-supported signing algorithm.</t>
            </list></t>

          <t>If the TEE isn't able to sign an error message due to an internal
            device error, a general error message should be returned by
            the OTrP Broker.
          </t>
        </section>

        <section title="TAM Processing Requirements">
          <t>Upon receiving a GetDeviceStateResponse message
          at a TAM, the TAM MUST validate the following.
            <list hangIndent="2" style="symbols">
              <t>Parse to get list of GetDeviceTEEStateResponse JSON
              objects</t>
              <t>Parse the JSON "payload" property and decrypt the JSON
              element "edsi". The decrypted message contains the TEE signer
              certificate.</t>
              <t>Validate the GetDeviceTEEStateResponse JSON signature. The
              signer certificate is extracted from the decrypted message
              in the last step.</t>
              <t>Extract TEE information and check it against its TEE
              acceptance policy.</t>
              <t>Extract the TFW signed element, and check the signer and
              data integration against its TFW policy.</t>
              <t>Check the SD list and TA list and prepare for a
              subsequent command such as "CreateSD" if it needs to have a
              new SD for an SP.</t>
            </list>
          </t>
        </section>

      </section> <!-- Get Device State -->

      <section anchor="sdmgmt" title="Security Domain Management">
        <section anchor="createsd" title="CreateSD">
          <t>This command is typically preceded with a GetDeviceState
          command that has acquired the device information of the target
          device by the TAM. The TAM sends such a command to instruct a
          TEE to create a new Security Domain for an SP.
          </t>

          <t>A TAM sends an OTrP CreateSDRequest Request message to a
          device TEE to create a Security Domain for an SP. Such a request
          is signed by the TAM where the TAM signer may or may not be the
          same as the SP's TA signer certificate. The resulting SD is
          associated with two identifiers for future management:
            <list hangIndent="2" style="symbols">
              <t>TAM as the owner. The owner identifier is a registered
              unique TAM ID that is stored in the TAM certificate.</t>
              <t>SP identified by its TA signer certificate as the
              authorization. A TAM can add more than one SP certificate
              to an SD.</t>
            </list></t>
          <t>A Trusted Application that is signed by a matching SP signer
          certificate for an SD is eligible to be installed into that SD.
           The TA installation into an SD by a subsequent InstallTARequest
           message may be instructed from a TAM.
          </t>

          <section anchor="createsdreq" title="CreateSDRequest Message">
            <figure>
              <preamble>The request message for CreateSD has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
   "CreateSDTBSRequest": {
     "ver": "1.0",
     "rid": "<unique request ID>",
     "tid": "<transaction ID>", // this may be from prior message
     "tee": "<TEE routing name from the DSI for the SD's target>",
     "nextdsi": true | false,
     "dsihash": "<hash of DSI returned in the prior query>",
     "content": ENCRYPTED { // this piece of JSON data will be
                             // encrypted
           "spid": "<SP ID value>",
        "sdname": "<SD name for the domain to be created>",
        "spcert": "<BASE64 encoded SP certificate>",
        "tamid": "<An identifiable attribute of the TAM
                   certificate>",
        "did": "<SHA256 hash of the TEE cert>"
     }
   }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value for the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> TEE ID returned from the previous
              GetDeviceStateResponse.</t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is expected in the
              response from the TEE to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD creation. The
              encryption key is TAMmk that is encrypted by the target
              TEE's public key. The entire message is signed by the TAM
              private key TAMpriv. A separate TAMmk isn't used in the
              latest specification because JSON encryption will use a
              content encryption key for exactly the same purpose.</t>
              <t hangText="spid -"> A unique id assigned by the TAM for
              its SP. It should be unique within a TAM namespace.</t>
              <t hangText="sdname -"> a name unique to the SP. TAM should
              ensure it is unique for each SP.</t>
              <t hangText="spcert -"> The SP's TA signer certificate is
              included in the request. This certificate will be stored by
              the device TEE which uses it to check against TA
              installation. Only if a TA is signed by a matching spcert
              associated with an SD will the TA be installed into the
              SD.</t>
              <t hangText="tamid -"> SD owner claim by TAM - an SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate. TEE
              will be responsible to assign this ID to the SD. The TAM
              certificate attribute for this attribute tamid MUST be
              vetted by the TAM signer issuing CA. With this trusted
              identifier, the SD query at TEE can be fast upon TAM signer
              verification.</t>
              <t hangText="did -">
              The SHA256 hash of the binary-encoded device TEE certificate.
              The encryption key CEK will be encrypted the
              recipient TEE's public key. This hash value in the "did"
              property allows the recipient TEE to check whether it is
              the expected target to receive such a request. If this
              isn't given, an OTrP message for device 2 could be sent
              to device 1. It is optional for the TEE to check because the
              successful decryption of the request message with this
              device's TEE private key already proves it is the target.
              This explicit hash value makes the protocol not dependent
              on message encryption method in future.</t>
            </list></t>

            <figure>
              <preamble>A CreateSDTBSRequest message is signed to
              generate a final CreateSDRequest message as follows.
              </preamble>

              <artwork><![CDATA[
{
    "CreateSDRequest": {
        "payload": "<CreateSDTBSRequest JSON above>",
        "protected": "<integrity-protected header contents>",
        "header": "<non-integrity-protected header contents>",
        "signature": "<signature contents signed by TAM private key>"
    }
}
             ]]></artwork>
            </figure>

            <t>The TAM signer certificate is included in the "header" property.</t>

          </section>

          <section anchor="createsdreqproc" title="Request Processing Requirements at a TEE">
            <t>Upon receiving a CreateSDRequest request message at a TEE,
            the TEE MUST do the following:
             <list hangIndent="2" style="numbers">
              <t>Validate the JSON request message as follows
                <list hangIndent="2" style="symbols">
                  <t>Validate JSON message signing.</t>
                  <t>Validate that the request TAM certificate is chained
                  to a trusted CA that the TEE embeds as its trust
                  anchor.</t>
                  <t>Compare dsihash with its current state to make sure
                  nothing has changed since this request was sent.</t>
                  <t>Decrypt to get the plaintext of the content: (a)
                  spid, (b) sd name, (c) did.</t>
                  <t>Check that an SPID is supplied.</t>
                  <t>spcert check: check it is a valid certificate
                  (signature and format verification only).</t>
                  <t>Check "did" is the SHA256 hash of its TEEcert BER
                  raw binary data.</t>
                  <t>Check whether the requested SD already exists for
                  the SP.</t>
                  <t>Check that the tamid in the request matches the TAM
                    certificate's TAM ID attribute.</t>
                </list>
              </t>
              <t>If the request was valid, create action
                <list hangIndent="2" style="symbols">
                  <t>Create an SD for the SP with the given name.</t>
                  <t>Assign the tamid from the TAMCert to this SD.</t>
                  <t>Assign the SPID and SPCert to this SD.</t>
                  <t>Check whether a TEE SP AIK key pair already exists
                  for the given SP ID.</t>
                  <t>Create TEE SP AIK key pair if it doesn't exist for
                  the given SP ID.</t>
                  <t>Generate new DSI data if the request asks for
                  updated DSI.</t>
                </list>
              </t>
              <t>Construct a CreateSDResponse message
                <list hangIndent="2" style="symbols">
                  <t>Create raw content
                    <list hangIndent="2" style="symbols">
                        <t>Operation status</t>
                        <t>"did" or full signer certificate information,
                        </t>
                        <t>TEE SP AIK public key if DSI isn't going to be
                        included</t>
                        <t>Updated DSI data if requested</t>
                    </list>
                  </t>
                  <t>The response message is encrypted with the
                     same JWE CEK of the request without recreating a
                     new content encryption key.</t>
                  <t>The encrypted message is signed with TEEpriv.
                     The signer information ("did" or TEEcert) is
                     encrypted. </t>
                </list>
              </t>
              <t>Deliver the response message. (a) The OTrP Broker returns this
                to the Client Application; (b) The Client App passes this back
                to the TAM.</t>
              <t>TAM processing. (a) The TAM processes the response message; (b)
              the TAM can look up signer certificate from the device ID "did".</t>
             </list>
            </t>

            <t>If a request is illegitimate or signature doesn't pass, a
            "status" property in the response will indicate the error
            code and cause.
            </t>

          </section>

          <section anchor="createsdresp" title="CreateSDResponse Message">
            <t>The response message for a CreateSDRequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "CreateSDTBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason": "<failure reason detail>", // optional
      "did": "<the device id received from the request>",
      "sdname": "<SD name for the domain created>",
      "teespaik": "<TEE SP AIK public key, BASE64 encoded>",
      "dsi": "<Updated TEE state, including all SDs owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - ">The SHA256 hash of the device TEE
              certificate. This shows the device ID explicitly to the
              receiving TAM.</t>
              <t hangText="teespaik - ">The newly generated SP AIK public
              key for the given SP. This is an optional value if the
              device has had another domain for the SP that has triggered
              TEE SP AIK key pair for this specific SP.</t>
             </list>
            </t>

            <t>There is a possible extreme error case where the TEE isn't
            reachable or the TEE final response generation itself fails.
            In this case, the TAM might still receive a response from the
            OTrP Broker if the OTrP Broker is able to detect such error from TEE.
            In this case, a general error response message should be
            returned by the OTrP Broker, assuming OTrP Broker even doesn't
            know any content and information about the request message.</t>

            <t>In other words, the TAM should expect to receive a TEE
            successfully signed JSON message, a general "status"
            message, or none when a client experiences a network error.</t>

            <figure>
              <artwork><![CDATA[
{
  "CreateSDResponse": {
    "payload": "<CreateSDTBSResponse JSON above>",
    "protected": {
       "<BASE64URL of signing algorithm>"
    },
    "signature": "<signature contents signed by the TEE device private
                  key (BASE64URL)>"
  }
}

             ]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="createsderrors" title="Error Conditions">
            <t> An error might occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors are as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_ALREADY_EXIST"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_SPCERT_INVALID"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>

<!-- TBD keep here in case we want to restore the full detail again -->
<!--
                <t hangText="ERR_REQUEST_INVALID -">  This error will
                occur if the TEE meets the following conditions with a
                request message: (1) The request from a TAM has an
                invalid message structure; mandatory information is
                absent in the message. undefined member or structure is
                included.  (2) TEE fails to verify signature of the
                message or fails to decrypt its contents. (3) etc.</t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION -">  This error
                will occur if TEE receives the version of message that
                TEE can't deal with.</t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG -">  This error
                will occur if TEE receives a request message encoded with
                cryptographic algorithms that TEE doesn't support.</t>
                <t hangText="ERR_AGENT_TEE_UNKNOWN -">  This error will occur
                if the receiver TEE is not supposed to receive the
                request. That will be determined by checking TEE name or
                device id in the request message.</t>
                <t hangText="ERR_SD_ALREADY_EXIST -">  This error will
                occur if SD to be created already exist in the TEE.</t>
                <t hangText="ERR_SPCERT_INVALID -">  If new SP
                certificate for the SD to be updated is not valid, then
                TEE will return this error code.</t>
                <t hangText="ERR_TAM_NOT_TRUSTED -">  Before processing a
                request, TEE needs to make sure whether the sender TAM is
                trustworthy by checking the validity of TAM  certificate
                etc. If TEE finds TAM is not reliable, then it will
                return this error code.</t>
                <t hangText="ERR_DEV_STATE_MISMATCH -">  TEE will return
                this error code if DSI hash value from TAM doesn't match
                with that of device's current DSI.</t>
                <t hangText="ERR_TEE_FAIL -">  TEE fails to respond to a
                TAM request. The OTrP Broker will construct an error
                message in responding the TAM's request. And also if TEE
                fails to process a request because of its internal error,
                it will return this error code.</t>
-->
              </list>
            </t>
          </section>

        </section> <!-- Create SD -->

        <section anchor="updatesd" title="UpdateSD">
          <t>This TAM initiated command can update an SP's SD that it manages
          for any of the following needs: (a) Update an SP signer certificate;
          (b) Add an SP signer certificate when an SP uses multiple to sign
          TA binaries; (c) Update an SP ID.</t>

          <t>The TAM presents the proof of the SD ownership to the TEE, and
          includes related information in its signed message. The entire
          request is also encrypted for end-to-end confidentiality.
          </t>

          <section anchor="updatesdreq" title="UpdateSDRequest Message">
            <figure>
              <preamble>The UpdateSD request message has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
   "UpdateSDTBSRequest": {
     "ver": "1.0",
     "rid": "<unique request ID>",
     "tid": "<transaction ID>", // this may be from prior message
     "tee": "<TEE routing name from the DSI for the SD's target>",
     "nextdsi": true | false,
     "dsihash": "<hash of DSI returned in the prior query>",
     "content": ENCRYPTED { // this piece of JSON will be encrypted
       "tamid": "<tamid associated with this SD>",
       "spid": "<SP ID>",
       "sdname": "<SD name for the domain to be updated>",
       "changes": {
         "newsdname": "<Change the SD name to this new name>",
                       // Optional
         "newspid": "<Change SP ID of the domain to this new value>",
                       // Optional
         "spcert": ["<BASE64 encoded new SP signer cert to be added>"],
                       // Optional
         "deloldspcert": ["<The SHA256 hex value of an old SP cert
                    assigned into this SD that should be deleted >"],
                       // Optional
         "renewteespaik": true | false
         }
     }
  }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value as the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> TEE ID returned from the previous
              GetDeviceStateResponse </t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is expected to be returned
              in the response from the TEE to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD update. The
              standard JSON content encryption key (CEK) is used, and the
              CEK is encrypted by the target TEE's public key.</t>
              <t hangText="tamid -"> SD owner claim by TAM - an SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate.</t>
              <t hangText="spid -"> the identifier of the SP whose SD
              will be updated. This value is still needed because the SD name
               is considered unique only within an SP.</t>
              <t hangText="sdname -"> the name of the target SD to be
              updated.</t>
              <t hangText="changes -"> its content consists of changes
              are to be updated in the given SD.</t>
              <t hangText="newsdname -"> the new name of the target SD
              to be assigned if this value is present.</t>
              <t hangText="newspid -"> the new SP ID of the target SD to
              be assigned if this value is present.</t>
              <t hangText="spcert -"> a new TA signer certificate of this
              SP to be added to the SD if this is present.</t>
              <t hangText="deloldspcert  -"> an SP certificate assigned
              into the SD is to be deleted if this is present. The value
              is the SHA256 fingerprint of the old SP certificate.</t>
              <t hangText="renewteespaik -"> the value should be true
              or false. If it is present and the value is true, the TEE
              MUST regenerate TEE SP AIK for this SD's owner SP. The newly
              generated TEE SP AIK for the SP must be returned in the
              response message of this request. If there is more than
              one SD for the SP, a new SPID for one of the domains will
              always trigger a new teespaik generation as if a new SP were
              introduced to the TEE.</t>
            </list></t>

            <figure>
              <preamble>The UpdateSDTBSRequest message is signed to
                generate the final UpdateSDRequest message.
              </preamble>

              <artwork><![CDATA[
{
  "UpdateSDRequest": {
    "payload": "<UpdateSDTBSRequest JSON above>",
    "protected": "<integrity-protected header contents>",
    "header": "<non-integrity-protected header contents>",
    "signature":"<signature contents signed by TAM private key>"
  }
}
             ]]></artwork>
            </figure>

            <t>TAM signer certificate is included in the "header" property.</t>

          </section>

          <section anchor="updatesdreqproc"
            title="Request Processing Requirements at a TEE">
            <t>Upon receiving a request message UpdateSDRequest at a TEE,
            the TEE must validate a request:
             <list hangIndent="2" style="numbers">
              <t>Validate the JSON request message
                <list hangIndent="2" style="symbols">
                  <t>Validate JSON message signing</t>
                  <t>Validate that the request TAM certificate is chained
                  to a trusted CA that the TEE embeds as its trust
                  anchor.The  TAM certificate status check is generally not
                  needed anymore in this request. The prior request
                  should have validated the TAM certificate's revocation
                  status.</t>
                  <t>Compare dsihash with the TEE cached last response
                  DSI data to this TAM.</t>
                  <t>Decrypt to get the plaintext of the content.</t>
                  <t>Check that the target SD name is supplied.</t>
                  <t>Check whether the requested SD exists.</t>
                  <t>Check that the TAM owns this TAM by verifying
                  tamid in the SD matches TAM certificate's TAM ID
                  attribute.</t>
                  <t>Now the TEE is ready to carry out update listed in
                  the "content" message.</t>
                </list>
              </t>
              <t>If the request is valid, update action
                <list hangIndent="2" style="symbols">
                  <t>If "newsdname" is given, replace the SD name for the
                  SD to the new value</t>
                  <t>If "newspid" is given, replace the SP ID assigned to
                  this SD with the given new value</t>
                  <t>If "spcert" is given, add this new SP certificate to
                  the SD.</t>
                  <t>If "deloldspcert" is present in the content, check
                  previously assigned SP certificates to this SD, and
                  delete the one that matches the given certificate hash
                  value.</t>
                    <t>If "renewteespaik" is given and has a value of 'true',
                  generate a new TEE SP AIK key pair,
                  and replace the old one with this.</t>
                  <t>Generate new DSI data if the request asks for
                  updated DSI</t>
                  <t>Now the TEE is ready to construct the response
                  message</t>
                </list>
              </t>
              <t>Construct UpdateSDResponse message
                <list hangIndent="2" style="symbols">
                  <t>Create raw content
                    <list hangIndent="2" style="symbols">
                        <t>Operation status</t>
                        <t>"did" or full signer certificate information,
                        </t>
                        <t>TEE SP AIK public key if DSI isn't going to be
                        included</t>
                        <t>Updated DSI data if requested</t>
                    </list>
                  </t>
                  <t>The response message is encrypted with the
                     same JWE CEK of the request without recreating a
                     new content encryption key.</t>
                  <t>The encrypted message is signed with TEEpriv.
                     The signer information ("did" or TEEcert) is
                     encrypted. </t>
                </list>
              </t>
              <t>Deliver response message. (a) The OTrP Broker returns this to
              the app; (b) The app passes this back to the TAM.</t>
              <t>TAM processing. (a) The TAM processes the response message; (b)
              The TAM can look up the signer certificate from the device ID "did".</t>
             </list>
            </t>

            <t>If a request is illegitimate or the signature doesn't pass, a
            "status" property in the response will indicate the error
            code and cause.
            </t>

          </section>

          <section anchor="updatesdresp" title="UpdateSDResponse Message">
            <t>The response message for a UpdateSDRequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "UpdateSDTBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason": "<failure reason detail>", // optional
      "did": "<the device id hash>",
      "cert": "<TEE certificate>", // optional
      "teespaik": "<TEE SP AIK public key, BASE64 encoded>",
      "teespaiktype": "<TEE SP AIK key type: RSA or ECC>",
      "dsi": "<Updated TEE state, including all SD owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - ">The request should have known the
              signer certificate of this device from a prior request.
              This hash value of the device TEE certificate serves as a
              quick identifier only. A full device certificate isn't
              necessary.</t>
              <t hangText="teespaik - ">the newly generated SP AIK public
              key for the given SP if the TEE SP AIK for the SP is asked to be
              renewed in the request. This is an optional value if "dsi"
              is included in the response, which will contain all up-to-date
              TEE SP AIK key pairs.</t>
             </list>
            </t>

            <t>Similar to the template for the creation of the
            encrypted and signed CreateSDResponse, the final
            UpdateSDResponse looks like the following.</t>

            <figure>
              <artwork><![CDATA[
{
  "UpdateSDResponse": {
    "payload": "<UpdateSDTBSResponse JSON above>",
    "protected": {
        "<BASE64URL of signing algorithm>"
    },
    "signature": "<signature contents signed by TEE device private
                  key (BASE64URL)>"
  }
}

             ]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="updatesderrors" title="Error Conditions">
            <t> An error may occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors are as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_SDNAME_ALREADY_USED"></t>
                <t hangText="ERR_SPCERT_INVALID"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>
              </list>
            </t>
          </section>

        </section> <!-- updatesd -->

        <section anchor="deletesd" title="DeleteSD">
          <t>A TAM sends a DeleteSDRequest message to a TEE to delete a
          specified SD that it owns. An SD can be deleted only if there is
          no TA associated with this SD in the device. The request
          message can contain a flag to instruct the TEE to delete all
          related TAs in an SD and then delete the SD.</t>

          <t>The target TEE will operate with the following logic.
            <list hangIndent="2" style="numbers">
              <t>Look up the given SD specified in the request message</t>
              <t>Check that the TAM owns the SD</t>
              <t>Check that the device state hasn't changed since the
              last operation</t>
              <t>Check whether there are TAs in this SD</t>
              <t>If TA exists in an SD, check whether the request
              instructs whether the TA should be deleted. If the request
              instructs the TEE to delete TAs, delete all TAs in this SD. If
              the request doesn't instruct the TEE to delete TAs, return
              an error "ERR_SD_NOT_EMPTY".</t>
              <t>Delete the SD</t>
              <t>If this is the last SD of this SP, delete the TEE SP AIK
              key.</t>
            </list>
          </t>

          <section anchor="deletesdreq" title="DeleteSDRequest Message">
            <figure>
              <preamble>The request message for DeleteSD has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
   "DeleteSDTBSRequest": {
     "ver": "1.0",
     "rid": "<unique request ID>",
     "tid": "<transaction ID>", // this may be from prior message
     "tee": "<TEE routing name from the DSI for the SD's target>",
     "nextdsi": true | false,
     "dsihash": "<hash of DSI returned in the prior query>",
     "content": ENCRYPTED { // this piece of JSON will be encrypted
       "tamid": "<tamid associated with this SD>",
       "sdname": "<SD name for the domain to be updated>",
       "deleteta": true | false
     }
  }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value for the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> TEE ID returned from the previous
              response GetDeviceStateResponse </t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is to be returned in the
              response to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD update. The
              standard JSON content encryption key (CEK) is used, and the
              CEK is encrypted by the target TEE's public key.</t>
              <t hangText="tamid -"> SD owner claim by TAM - an SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate.</t>
              <t hangText="sdname -"> the name of the target SD to be
              updated.</t>
              <t hangText="deleteta -"> the value should be boolean 'true'
                or 'false'. If it is present and the value is 'true',
                the TEE should delete all TAs associated with the SD in
                the device.</t>
            </list></t>

            <figure>
              <preamble>According to the OTrP message template, the full
              request DeleteSDRequest is a signed message over the
              DeleteSDTBSRequest as follows.
              </preamble>

              <artwork><![CDATA[
{
    "DeleteSDRequest": {
        "payload": "<DeleteSDTBSRequest JSON above>",
        "protected": "<integrity-protected header contents>",
        "header": "<non-integrity-protected header contents>",
        "signature": "<signature contents signed by TAM private key>"
    }
}
             ]]></artwork>
            </figure>

            <t>TAM signer certificate is included in the "header" property.</t>

          </section>

          <section anchor="deletesdreqproc"
            title="Request Processing Requirements at a TEE">
            <t>Upon receiving a request message DeleteSDRequest at a TEE,
            the TEE must validate a request:
             <list hangIndent="2" style="numbers">
              <t>Validate the JSON request message
                <list hangIndent="2" style="symbols">
                  <t>Validate JSON message signing</t>
                  <t>Validate that the request TAM certificate is chained
                  to a trusted CA that the TEE embeds as its trust
                  anchor. The TAM certificate status check is generally not
                  needed anymore in this request. The prior request
                  should have validated the TAM certificate's revocation
                  status.</t>
                  <t>Compare dsihash with the TEE cached last response
                  DSI data to this TAM</t>
                  <t>Decrypt to get the plaintext of the content</t>
                  <t>Check that the target SD name is supplied</t>
                  <t>Check whether the requested SD exists</t>
                  <t>Check that the TAM owns this TAM by verifying
                  that the tamid in the SD matches the TAM certificate's TAM ID
                  attribute</t>
                  <t>Now the TEE is ready to carry out the update listed in
                  the "content" message</t>
                </list>
              </t>
              <t>If the request is valid, deletion action
                <list hangIndent="2" style="symbols">
                  <t>Check TA existence in this SD</t>
                  <t>If "deleteta" is "true", delete all TAs in this SD.
                  If the value of "deleteta" is false and some TA exists,
                  return an error "ERR_SD_NOT_EMPTY"</t>
                  <t>Delete the SD</t>
                  <t>Delete the TEE SP AIK key pair if this SD is the last
                  one for the SP</t>
                  <t>Now the TEE is ready to construct the response
                  message</t>
                </list>
              </t>
              <t>Construct a DeleteSDResponse message
                <list hangIndent="2" style="symbols">
                  <t>Create response content
                    <list hangIndent="2" style="symbols">
                        <t>Operation status</t>
                        <t>"did" or full signer certificate information,
                        </t>
                        <t>Updated DSI data if requested</t>
                    </list>
                  </t>
                  <t>The response message is encrypted with the
                     same JWE CEK of the request without recreating a
                     new content encryption key.</t>
                  <t>The encrypted message is signed with TEEpriv.
                     The signer information ("did" or TEEcert) is
                     encrypted. </t>
                </list>
              </t>
              <t>Deliver response message. (a) The OTrP Broker returns this to
              the app; (b) The app passes this back to the TAM</t>
              <t>TAM processing. (a) The TAM processes the response message; (b)
              The TAM can look up signer certificate from the device ID "did".</t>
             </list>
            </t>

            <t>If a request is illegitimate or the signature doesn't pass, a
            "status" property in the response will indicate the error
            code and cause.
            </t>

          </section>

          <section anchor="deletesdresp" title="DeleteSDResponse Message">
            <t>The response message for a DeleteSDRequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteSDTBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason": "<failure reason detail>", // optional
      "did": "<the device id hash>",
      "dsi": "<Updated TEE state, including all SD owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - ">The request should have known the
              signer certificate of this device from a prior request.
              This hash value of the device TEE certificate serves as a
              quick identifier only. A full device certificate isn't
              necessary.</t>
             </list>
            </t>

            <t>The final DeleteSDResponse looks like the following.</t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteSDResponse": {
    "payload": "<DeleteSDTBSResponse JSON above>",
    "protected": {
        "<BASE64URL of signing algorithm>"
    },
    "signature": "<signature contents signed by TEE device
      private key (BASE64URL)>"
  }
}]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="deletesderrors" title="Error Conditions">
            <t> An error may occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors is as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_NOT_EMPTY"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>
              </list>
            </t>
          </section>
        </section> <!-- delete sd -->
      </section>

      <section anchor="tamgmt" title="Trusted Application Management">
        <t>This protocol doesn't introduce a TA container concept. All
        TA authorization and management will be up to the TEE
        implementation.
        </t>

        <t>The following three TA management commands are supported.
            <list hangIndent="2" style="symbols">
              <t>InstallTA - provision a TA by TAM</t>
              <t>UpdateTA - update a TA by TAM</t>
              <t>DeleteTA - remove TA registration information with an SD,
              remove the TA binary and all TA-related data in
              a TEE</t>
            </list>
        </t>

        <section anchor="installta" title="InstallTA">
          <t>TA binary data and related personalization data if there is any
            can be from two sources:
            <list hangIndent="2" style="numbers">
              <t>A TAM supplies the signed and encrypted TA binary</t>
              <t>A Client Application supplies the TA binary</t>
            </list>
          </t>

          <t>This specification primarily considers the first case where a TAM
          supplies a TA binary. This is to ensure that a TEE can properly
          validate whether a TA is trustworthy. Further, TA personalization data
          will be encrypted by the TEE device's SP public key for end-to-end
          protection. A Client Application bundled TA case will be addressed
          separately later.</t>

          <t>A TAM sends the following information in a
          InstallTARequest message to a target TEE:
            <list hangIndent="2" style="symbols">
              <t>The target SD information: SP ID and SD name</t>
              <t>Encrypted TA binary data. TA data is encrypted with the TEE
              SP AIK.</t>
              <t>TA metadata. It is optional to include the SP signer certificate
              for the SD to add if the SP has changed signer since the SD
              was created.</t>
            </list>
          </t>

          <t>The TEE processes the command given by the TAM to install a TA
            into an SP's SD. It does the following:
            <list hangIndent="2" style="symbols">
              <t>Validation
                <list hangIndent="2" style="symbols">
                  <t>The TEE validates the TAM message authenticity</t>
                  <t>Decrypt to get request content</t>
                  <t>Look up the SD with the SD name</t>
                  <t>Checks that the TAM owns the SD</t>
                  <t>Checks that the DSI hash matches which shows that the
                    device state hasn't changed</t>
                </list>
              </t>
              <t>If the request is valid, continue to do the TA validation
                <list hangIndent="2" style="symbols">
                  <t>Decrypt to get the TA binary data and any personalization
                  data with the "TEE SP AIK private key"</t>
                  <t>Check that SP ID is the one that is registered with
                  the SP SD</t>
                  <t>Check that the TA signer is either a newly given SP
                    certificate or the one that is already trusted by the
                    SD from the previous TA installation. The TA signing
                    method is specific to a TEE. This specification doesn't
                    define how a TA should be signed; a TAM should support
                    TEE specific TA signing when it supports that TEE.</t>
                  <t>If a TA signer is given in the request, add this
                  signer into the SD.</t>
                </list>
              </t>
              <t>If the above validation passed, continue to do TA installation
                <list hangIndent="2" style="symbols">
                  <t>The TEE re-encrypts the TA binary and its personalization
                  data with its own method.</t>
                  <t>The TEE enrolls and stores the TA in a secure
                  storage.</t>
                </list>
              </t>
              <t>Construct a response message. This involves signing
              encrypted status information for the requesting TAM.</t>
            </list>
          </t>

          <section anchor="installtareq" title="InstallTARequest Message">
            <figure>
              <preamble>The request message for InstallTA has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
  "InstallTATBSRequest": {
    "ver": "1.0",
    "rid": "<unique request ID>",
    "tid": "<transaction ID>",
    "tee": "<TEE routing name from the DSI for the SD's target>",
    "nextdsi": true | false,
    "dsihash": "<hash of DSI returned in the prior query>",
    "content": ENCRYPTED {
      "tamid": "<TAM ID previously assigned to the SD>",
      "spid": "<SPID value>",
      "sdname": "<SD name for the domain to install the TA>",
      "spcert": "<BASE64 encoded SP certificate >", // optional
      "taid": "<TA identifier>"
    },
    "encrypted_ta": {
      "key": "<JWE enveloped data of a 256-bit symmetric key by
               the recipient's TEEspaik public key>",
      "iv": "<hex of 16 random bytes>",
      "alg": "<encryption algoritm. AESCBC by default.",
      "ciphertadata": "<BASE64 encoded encrypted TA binary data>",
      "cipherpdata": "<BASE64 encoded encrypted TA personalization
                      data>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value for the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> TEE ID returned from the previous
              GetDeviceStateResponse </t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is to be returned in the
              response to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD update. The
              standard JSON content encryption key (CEK) is used, and the
              CEK is encrypted by the target TEE's public key.</t>
              <t hangText="tamid -"> SD owner claim by TAM - An SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate.</t>
              <t hangText="spid -"> SP identifier of the TA owner SP</t>
              <t hangText="sdname -"> the name of the target SD where the
              TA is to be installed</t>
              <t hangText="spcert -"> an optional field to specify the SP
              certificate that signed the TA. This is sent if the SP has
              a new certificate that hasn't been previously registered
              with the target SD where the TA should be installed.</t>
              <t hangText="taid -"> the identifier of the TA application
              to be installed</t>
              <t hangText="encrypted_ta -"> the message portion contains
              encrypted TA binary data and personalization data. The TA
              data encryption key is placed in "key", which is encrypted
              by the recipient's public key, using JWE enveloped structure.
              The TA data encryption uses symmetric key based encryption
              such as AESCBC.</t>
            </list></t>

            <figure>
              <preamble>According to the OTrP message template, the full
              request InstallTARequest is a signed message over the
              InstallTATBSRequest as follows.
              </preamble>

              <artwork><![CDATA[
{
    "InstallTARequest": {
        "payload": "<InstallTATBSRequest JSON above>",
        "protected": "<integrity-protected header contents>",
        "header": "<non-integrity-protected header contents>",
        "signature": "<signature contents signed by TAM private key>"
    }
}
             ]]></artwork>
            </figure>
          </section>

          <section anchor="installtaresp" title="InstallTAResponse Message">
            <t>The response message for a InstallTARequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "InstallTATBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason":"<failure reason detail>", // optional
      "did": "<the device id hash>",
      "dsi": "<Updated TEE state, including all SD owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - "> the SHA256 hash of the device TEE
              certificate. This shows the device ID explicitly to the
              receiving TAM.</t>
             </list>
            </t>

            <t>The final message InstallTAResponse looks like the
            following.</t>

            <figure>
              <artwork><![CDATA[
{
    "InstallTAResponse": {
        "payload":"<InstallTATBSResponse JSON above>",
        "protected": {
            "<BASE64URL of signing algorithm>"
        },
        "signature": "<signature contents signed by TEE device
          private key (BASE64URL)>"
    }
}

             ]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="installtaerrors" title="Error Conditions">
            <t>An error may occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors are as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_TA_INVALID"></t>
                <t hangText="ERR_TA_ALREADY_INSTALLED"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TEE_RESOURCE_FULL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>
              </list>
            </t>
          </section>
        </section> <!-- install TA -->

        <section anchor="updateta" title="UpdateTA">
          <t>This TAM-initiated command can update a TA and its data in an
          SP's SD that it manages for the following purposes.
            <list hangIndent="2" style="numbers">
              <t>Update TA binary</t>
              <t>Update TA's personalization data</t>
            </list>
          </t>

          <t>The TAM presents the proof of the SD ownership to a TEE, and
          includes related information in its signed message. The entire
          request is also encrypted for end-to-end confidentiality.</t>

          <t>The TEE processes the command from the TAM to update the TA of
            an SP SD. It does the following:
            <list hangIndent="2" style="symbols">
              <t>Validation
                <list hangIndent="2" style="symbols">
                  <t>The TEE validates the TAM message authenticity</t>
                  <t>Decrypt to get request content</t>
                  <t>Look up the SD with the SD name</t>
                  <t>Checks that the TAM owns the SD</t>
                  <t>Checks DSI hash matches that the device state hasn't
                  changed</t>
                </list>
              </t>
              <t>TA validation
                <list hangIndent="2" style="symbols">
                  <t>Both TA binary and personalization data are
                  optional, but at least one of them shall be present in
                  the message</t>
                  <t>Decrypt to get the TA binary and any personalization
                  data with the "TEE SP AIK private key"</t>
                  <t>Check that SP ID is the one that is registered with
                  the SP SD</t>
                  <t>Check that the TA signer is either a newly given SP certificate
                  or the one in SD.</t>
                  <t>If a TA signer is given in the request, add this
                  signer into the SD.</t>
                </list>
              </t>
              <t>If the above validation passes, continue to do TA update
                <list hangIndent="2" style="symbols">
                  <t>The TEE re-encrypts the TA binary and its personalization
                  data with its own method</t>
                  <t>The TEE replaces the existing TA binary and its
                  personalization data with the new binary and data.</t>
                </list>
              </t>
              <t>Construct a response message. This involves signing a
              encrypted status information for the requesting TAM.</t>
            </list>
          </t>

          <section anchor="updatetareq" title="UpdateTARequest Message">
            <figure>
              <preamble>The request message for UpdateTA has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
  "UpdateTATBSRequest": {
    "ver": "1.0",
    "rid": "<unique request ID>",
    "tid": "<transaction ID>",
    "tee": "<TEE routing name from the DSI for the SD's target>",
    "nextdsi": true | false,
    "dsihash": "<hash of DSI returned in the prior query>",
    "content": ENCRYPTED {
      "tamid": "<TAM ID previously assigned to the SD>",
      "spid": "<SPID value>",
      "sdname": "<SD name for the domain to be created>",
      "spcert": "<BASE64 encoded SP certificate >", // optional
      "taid": "<TA identifier>"
    },
    "encrypted_ta": {
      "key": "<JWE enveloped data of a 256-bit symmetric key by
               the recipient's TEEspaik public key>",
      "iv": "<hex of 16 random bytes>",
      "alg": "<encryption algoritm. AESCBC by default.",
      "ciphernewtadata": "<Change existing TA binary to this new TA
          binary data(BASE64 encoded and encrypted)>",
      "ciphernewpdata": "<Change the existing data to this new TA
          personalization data(BASE64 encoded and encrypted)>"
          // optional
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value for the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> TEE ID returned from the previous
              GetDeviceStateResponse </t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is to be returned in the
              response to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD update. The
              standard JSON content encryption key (CEK) is used, and the
              CEK is encrypted by the target TEE's public key.</t>
              <t hangText="tamid -"> SD owner claim by TAM - an SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate.</t>
              <t hangText="spid -"> SP identifier of the TA owner SP</t>
              <t hangText="spcert -"> an optional field to specify the SP
              certificate that signed the TA. This is sent if the SP has
              a new certificate that hasn't been previously registered
              with the target SD where the TA is to be installed.</t>
              <t hangText="sdname -"> the name of the target SD where the
              TA should be updated</t>
              <t hangText="taid -"> an identifier for the TA application
              to be updated</t>
              <t hangText="encrypted_ta -"> the message portion contains
              newly encrypted TA binary data and personalization data.</t>
            </list></t>

            <figure>
              <preamble>According to the OTrP message template, the full
              request UpdateTARequest is a signed message over the
              UpdateTATBSRequest as follows.
              </preamble>

              <artwork><![CDATA[


{
    "UpdateTARequest": {
        "payload": "<UpdateTATBSRequest JSON above>",
        "protected": "<integrity-protected header contents>",
        "header": "<non-integrity-protected header contents>",
        "signature": "<signature contents signed by TAM private key>"
    }
}
             ]]></artwork>
            </figure>
          </section>

          <section anchor="updatetaresp" title="UpdateTAResponse Message">
            <t>The response message for a UpdateTARequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "UpdateTATBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason": "<failure reason detail>", // optional
      "did": "<the device id hash>",
      "dsi": "<Updated TEE state, including all SD owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - "> the SHA256 hash of the device TEE
              certificate. This shows the device ID explicitly to the
              receiving TAM.</t>
             </list>
            </t>

            <t>The final message UpdateTAResponse looks like the
            following.</t>

            <figure>
              <artwork><![CDATA[
{
    "UpdateTAResponse": {
        "payload":"<UpdateTATBSResponse JSON above>",
        "protected": {
            "<BASE64URL of signing algorithm>"
        },
        "signature": "<signature contents signed by TEE device
          private key (BASE64URL)>"
    }
}

             ]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="updatetaerrors" title="Error Conditions">
            <t>An error may occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors are as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_TA_INVALID"></t>
                <t hangText="ERR_TA_NOT_FOUND"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>
              </list>
            </t>
          </section>
        </section> <!-- update TA -->

        <section anchor="deleteta" title="DeleteTA">
          <t>This operation defines OTrP messages that allow a TAM
          to instruct a TEE to delete a TA for an SP in a given SD. A TEE
          will delete a TA from an SD and also TA data in the TEE.
          A Client Application cannot directly access TEE or OTrP
          Broker to delete a TA.
          </t>

          <section anchor="deletetareq" title="DeleteTARequest Message">
            <figure>
              <preamble>The request message for DeleteTA has the
              following JSON format.</preamble>
              <artwork><![CDATA[
{
  "DeleteTATBSRequest": {
    "ver": "1.0",
    "rid": "<unique request ID>",
    "tid": "<transaction ID>",
    "tee": "<TEE routing name from the DSI for the SD's target>",
    "nextdsi": true | false,
    "dsihash": "<hash of DSI returned in the prior query>",
    "content": ENCRYPTED {
      "tamid": "<TAM ID previously assigned to the SD>",
      "sdname": "<SD name of the TA>",
      "taid": "<the identifier of the TA to be deleted from the
               specified SD>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the message, <list hangIndent="2" style="hanging">
              <t hangText="rid -"> A unique value to identify this
              request</t>
              <t hangText="tid -"> A unique value to identify this
              transaction. It can have the same value for the tid in the
              preceding GetDeviceStateRequest.</t>
              <t hangText="tee -"> The TEE ID returned from the previous
              GetDeviceStateResponse </t>
              <t hangText="nextdsi -"> Indicates whether the up-to-date
              Device State Information (DSI) is to be returned in the
              response to this request.</t>
              <t hangText="dsihash -"> The BASE64-encoded SHA256 hash
              value of the DSI data returned in the prior TAM operation
              with this target TEE. This value is always included such
              that a receiving TEE can check whether the device state has
              changed since its last query. It helps enforce SD update
              order in the right sequence without accidentally overwriting an
              update that was done simultaneously.</t>
              <t hangText="content -"> The "content" is a JSON encrypted
              message that includes actual input for the SD update. The
              standard JSON content encryption key (CEK) is used, and the
              CEK is encrypted by the target TEE's public key.</t>
              <t hangText="tamid -"> SD owner claim by TAM - an SD owned
              by a TAM will be associated with a trusted identifier
              defined as an attribute in the signer TAM certificate.</t>
              <t hangText="sdname -"> the name of the target SD where the
              TA is installed</t>
              <t hangText="taid -"> an identifier for the TA application
              to be deleted</t>
            </list></t>

            <figure>
              <preamble>According to the OTrP message template, the full
              request DeleteTARequest is a signed message over the
              DeleteTATBSRequest as follows.
              </preamble>

              <artwork><![CDATA[


{
    "DeleteTARequest": {
        "payload": "<DeleteTATBSRequest JSON above>",
        "protected": "<integrity-protected header contents>",
        "header": "<non-integrity-protected header contents>",
        "signature": "<signature contents signed by TAM
            private key>"
    }
}
             ]]></artwork>
            </figure>
          </section>

          <section anchor="deletetareqproc"
            title="Request Processing Requirements at a TEE">

            <t>A TEE processes a command from a TAM to delete a TA of an SP
            SD. It does the following:
             <list hangIndent="2" style="numbers">
              <t>Validate the JSON request message
                <list hangIndent="2" style="symbols">
                  <t>The TEE validates TAM message authenticity</t>
                  <t>Decrypt to get request content</t>
                  <t>Look up the SD and the TA with the given SD name and
                  TA ID</t>
                  <t>Checks that the TAM owns the SD, and TA is installed
                  in the SD</t>
                  <t>Checks that the DSI hash matches and the the device state
                    hasn't changed</t>
                </list>
              </t>
              <t>Deletion action
                <list hangIndent="2" style="symbols">
                  <t>If all the above validation points pass, the TEE
                  deletes the TA from the SD</t>
                  <t>The TEE SHOULD also delete all personalization data for
                  the TA</t>
                </list>
              </t>
              <t>Construct DeleteTAResponse message.</t>
             </list>
            </t>

            <t>If a request is illegitimate or the signature doesn't pass, a
            "status" property in the response will indicate the error
            code and cause.
            </t>

          </section>

          <section anchor="deletetaresp" title="DeleteTAResponse Message">
            <t>The response message for a DeleteTARequest contains the
            following content.</t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteTATBSResponse": {
    "ver": "1.0",
    "status": "<operation result>",
    "rid": "<the request ID received>",
    "tid": "<the transaction ID received>",
    "content": ENCRYPTED {
      "reason": "<failure reason detail>", // optional
      "did": "<the device id hash>",
      "dsi": "<Updated TEE state, including all SD owned by
        this TAM>"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>In the response message, the following fields MUST be supplied.
             <list hangIndent="2" style="hanging">
              <t hangText="did - "> the SHA256 hash of the device TEE
              certificate. This shows the device ID explicitly to the
              receiving TAM.</t>
             </list>
            </t>

            <t>The final message DeleteTAResponse looks like the
            following.</t>

            <figure>
              <artwork><![CDATA[
{
    "DeleteTAResponse": {
        "payload": "<DeleteTATBSResponse JSON above>",
        "protected": {
            "<BASE64URL of signing algorithm>"
        },
        "signature": "<signature contents signed by TEE device
            private key (BASE64URL)>"
    }
}

             ]]></artwork>
            </figure>

            <t>When the TEE fails to respond, the OTrP Broker will not provide
              a subsequent response to the TAM. The TAM should treat this as
              if the device has gone offline where a response is never
              delivered back.</t>
          </section>

          <section anchor="deletetaerrors" title="Error Conditions">
            <t>An error may occur if a request isn't valid or the TEE
            runs into some error. The list of possible errors are as follows.
            Refer to the <xref target="errorcodelist">
            Error Code List</xref> for detailed causes and actions.

              <list hangIndent="2" style="hanging">
                <t hangText="ERR_REQUEST_INVALID"></t>
                <t hangText="ERR_UNSUPPORTED_MSG_VERSION"></t>
                <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG"></t>
                <t hangText="ERR_DEV_STATE_MISMATCH"></t>
                <t hangText="ERR_SD_NOT_FOUND"></t>
                <t hangText="ERR_TA_NOT_FOUND"></t>
                <t hangText="ERR_TEE_FAIL"></t>
                <t hangText="ERR_TAM_NOT_AUTHORIZED"></t>
                <t hangText="ERR_TAM_NOT_TRUSTED"></t>
              </list>
            </t>
          </section>
        </section> <!-- delete TA -->

      </section>

    </section>

    <section anchor="TAMuse" title="Response Messages a TAM May Expect">
      <t>A TAM expects some feedback from a remote device when a request
        message is delivered to a device. The following three types of
        responses SHOULD be supplied.
      </t>

      <t><list hangIndent="4" style="hanging">
              <t hangText="Type 1: ">Expect a valid TEE-generated
              response message</t>
      <t>A valid TEE signed response may contain errors detected by a TEE, e.g.
        a TAM is trusted but some TAM-supplied data is missing, for example, SP ID
        doesn't exist. TEE MUST be able to sign and encrypt.
      </t>
      <t>If a TEE isn't able to sign a response, the TEE returns an error to
        the OTrP Broker without giving any other internal information. The OTrP
        Broker will be generating the response.
      </t>
      </list></t>

      <t><list hangIndent="4" style="hanging">
              <t hangText="Type 2: ">
              The OTrP Broker generated error message when TEE fails. OTrP
              Broker errors will be defined in this document.</t>
              <t>A Type 2 message has the following format.</t>
      </list></t>

      <figure>
        <artwork><![CDATA[
      {
        "OTrPBrokerError": {
            "ver": "1.0",
            "rid": "",
            "tid": "",
            "errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY"
        }
      }
           ]]></artwork>
      </figure>

      <t><list hangIndent="4" style="hanging">
              <t hangText="Type 3: ">
        OTrP Broker itself isn't reachable or fails. A Client Application is
        responsible to handle error and respond the TAM in its own way. This is
        out of scope for this specification.</t>
      </list></t>

    </section>

    <section anchor="basicprofile" title="Basic Protocol Profile">
      <t>This section describes a baseline for interoperability among
      the protocol entities, mainly, the TAM and TEE.</t>

      <t>A TEE MUST support RSA algorithms. It is optional to support
      ECC algorithms. A TAM SHOULD use a RSA certificate for TAM message
      signing. It may use an ECC certificate if it detects that the TEE
      supports ECC according to the field "supportedsigalgs" in a TEE
      response.</t>

      <t>A TAM MUST support both RSA 2048-bit algorithm and ECC P-256
      algorithms. With this, a TEE and TFW certificate can be either RSA
      or ECC type. </t>

      <t>JSON signing algorithms
        <list hangIndent="2" style="symbols">
          <t>RSA PKCS#1 with SHA256 signing : "RS256"</t>
          <t>ECDSA with SHA256 signing : "ES256"</t>
        </list>
      </t>

      <t>JSON asymmetric encryption algorithms (describes key-exchange
      or key-agreement algorithm for sharing symmetric key with TEE):
        <list hangIndent="2" style="symbols">
          <t>RSA PKCS#1  : "RSA1_5"</t>
          <t>ECDH using TEE ECC P-256 key and ephemeral ECC key
             generated by TAM : "ECDH-ES+A128W"</t>
        </list>
      </t>

      <t>JSON symmetric encryption algorithms (describes symmetric
      algorithm for encrypting body of data, using symmetric key
      transferred to TEE using asymmetric encryption):
        <list hangIndent="2" style="symbols">
          <t>Authenticated encryption AES 128 CBC with SHA256 :
             {"enc":"A128CBC-HS256"}</t>
        </list>
      </t>
    </section>

    <section anchor="impl" title="Attestation Implementation Consideration">
      <!-- NOTE: this section could be moved to Appendix in RFC -->
      <t>
        It is important to know that the state of a device is appropriate
        before trusting that a device is what it says it is. The attestation
        scheme for OTrP must also be able to cope with different TEEs,
        including those that are OTrP
        compliant and those that use another mechanism. In the initial
        version, only one active TEE is assumed.
      </t>
      <t>
        It is out of scope how the TAM and the device implement the trust
        hierarchy verification. However, it is helpful to understand what each
        system provider should do in order to properly implement an OTrP trust
        hierarchy.
      </t>
      <t>
        In this section, we provide some implementation reference
        consideration.
      </t>

      <section anchor="otrptfw" title="OTrP Trusted Firmware">
        <section anchor="attestsigner" title="Attestation signer">
          <t>
            It is proposed that attestation for OTrP is based on the TFW
            layer, and that further attestation is not
            performed within the TEE itself during Security Domain
            operations. The rationale is that the device boot process
            will be defined to start with a secure bootloader protected
            with a harden key in eFUSE. The process releases attestation
            signing capabilities into the TFW once a trust boot has been
            established. In this way the release of the attestation signer
            can be considered
            the first "platform configuration metric", using Trust Computing
            Group (TCG) terminology.
          </t>
        </section>

        <section anchor="tfwreq" title="TFW Initial Requirements">
          <t>
            <list counter="reqs" hangIndent="4" style="format R%d">
              <t>The TFW must be possible for verification during boot
              </t>
              <t>The TFW must allow a public / private key pair to be generated
                during device manufacture
              </t>
              <t>The public key and certificate must be possible to store
                securely
              </t>
              <t>The private key must be possible to store encrypted at rest
              </t>
              <t>The private key must only be visible to the TFW when it is
                decrypted
              </t>
              <t>The TFW must be able to read a list of root and
              intermediate certificates that it can use to check
              certificate chains with. The list must be stored such that
              it cannot be tampered with
              </t>
              <t>Need to allow a TEE to access its unique TEE
              specific private key
              </t>
            </list>
          </t>
        </section>
      </section>

      <section anchor="teeload" title="TEE Loading">
        <t>During boot, the TFW is required to start all of the root TEEs. Before
        loading them, the TFW must first determine whether the code sign
        signature of the TEE is valid. If TEE integrity is confirmed, the TEE
        may be started. The TFW must then be able to receive the identity certificate
        from the TEE (if that TEE is OTrP compliant). The identity certificate
        and keys will need to be baked into the TEE image, and therefore also
        covered by the code signer hash during the manufacturing process. The
        private key for the identity certificate must be securely protected.
        The private key for a TEE identity must never be released no matter how
        the public key and certificate are released to the TFW.
        </t>
        <t>Once the TFW has successfully booted a TEE and retrieved the
        identity certificate, the TFW will commit this to the platform configuration
        register (PCR) set, for later use during attestation. At minimum, the
        following data must be committed to the PCR for each TEE:
        </t>
        <t>
          <list style="numbers">
            <t>Public key and certificate for the TEE</t>
            <t>TEE identifier that can be used later by a TAM to identify this
              TEE
            </t>
          </list>
        </t>
      </section>

      <section anchor="attest" title="Attestation Hierarchy">
        <t>The attestation hierarchy and seed required for TAM protocol
        operation must be built into the device at manufacture. Additional TEEs
        can be added post-manufacture using the scheme proposed, but it is
        outside of the current scope of this document to detail that.
        </t>
        <t>It should be noted that the attestation scheme described is based on
        signatures. The only decryption that may take place is through the
        use of a bootloader key.
        </t>

        <section title="Attestation Hierarchy Establishment: Manufacture">
          <t>
            During manufacture the following steps are required:
          </t>
          <t>
            <list style="numbers">
              <t>A device-specific TFW key pair and certificate are burnt into
                the device. This key pair will be used for
                signing operations performed by the TFW.
              </t>
              <t>TEE images are loaded and include a TEE instance-specific
                key pair and certificate. The key pair and certificate are included
                in the image and covered by the code signing hash.
              </t>
              <t>The process for TEE images is repeated for any subordinate
                TEEs, which are additional TEEs after the root TEE that some
                devices have.
              </t>
            </list>
          </t>
        </section>

        <section title="Attestation Hierarchy Establishment: Device Boot">
          <t>During device boot the following steps are required:</t>
          <t>
            <list style="numbers">
              <t>The boot module releases the TFW private key by decrypting it with
                the bootloader key.
              </t>
              <t>The TFW verifies the code-signing signature of the active TEE
                 and places its TEE public key into a signing buffer, along with
                 its identifier for later access. For a non-OTrP TEE, the TFW
                 leaves the TEE public key field blank.
              </t>
              <t>The TFW signs the signing buffer with the TFW private key.</t>
              <t>Each active TEE performs the same operation as the TFW, building
                up their own signed buffer containing subordinate TEE
                information.
              </t>
            </list>
          </t>
        </section>

        <section title="Attestation Hierarchy Establishment: TAM">
          <t>Before a TAM can begin operation in the marketplace to support
            devices of a given TEE, it must obtain a TAM certificate from a
            CA that is registered in the trust store of devices with that TEE.
            In this way, the TEE can check the intermediate and root CA and
            verify that it trusts this TAM to perform operations on the TEE.
          </t>
        </section>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>There are two IANA requests: a media type and list of error codes.</t>

      <t>This section first requests that IANA assign a media type:
          application/otrp+json.</t>
        <t>
        <list hangIndent="2" style="hanging">
         <t hangText="Type name:"> application</t>
         <t hangText="Subtype name:"> otrp+json</t>
         <t hangText="Required parameters:"> none</t>
         <t hangText="Optional parameters:"> none</t>
         <t hangText="Encoding considerations:"> Same as encoding considerations of
         application/json as specified in Section 11 of <xref target="RFC7159"/></t>
         <t hangText="Security considerations:"> See Section 12 of <xref target="RFC7159"/>
         and Section 14 of this document</t>
         <t hangText="Interoperability considerations:"> Same as interoperability
         considerations of application/json as specified in
         <xref target="RFC7159"/></t>
         <t hangText="Published specification:"> <xref target="TEEPArch"/></t>
         <t hangText="Applications that use this media type:"> OTrP implementations</t>
         <t hangText="Fragment identifier considerations:"> N/A</t>
         <t hangText="Additional information:">
           <list hangIndent="2" style="hanging">
             <t hangText="Deprecated alias names for this type:"> N/A</t>
             <t hangText="Magic number(s):"> N/A</t>
             <t hangText="File extension(s):"> N/A</t>
             <t hangText="Macintosh file type code(s):"> N/A</t>
           </list>
         </t>
         <t hangText="Person to contact for further information:">
            teep@ietf.org</t>
         <t hangText="Intended usage:"> COMMON</t>
         <t hangText="Restrictions on usage:"> none</t>
         <t hangText="Author:"> See the "Authors' Addresses" section of this document</t>
         <t hangText="Change controller:"> IETF</t>
        </list>
        </t>

      <t>The error code listed in the next section will be registered.</t>

      <section anchor="errorcodelist" title="Error Code List">
        <t>This section lists error codes that could be reported by
        a TA or TEE in a device in responding to a TAM request, and a
        separate list that OTrP Broker may return when the TEE fails to
        respond.</t>

        <section anchor="teeerrorcodelist" title="TEE Signed Error Code List">
        <t>
          <list hangIndent="2" style="hanging">
            <t hangText="ERR_DEV_STATE_MISMATCH -"> A TEE will return
            this error code if the DSI hash value from TAM doesn't match
            the has value of the device's current DSI.</t>

            <t hangText="ERR_SD_ALREADY_EXISTS -">  This error will
            occur if an SD to be created already exists in the TEE.</t>

            <t hangText="ERR_SD_NOT_EMPTY -"> This is reported if a
            target SD isn't empty.</t>

            <t hangText="ERR_SDNAME_ALREADY_USED">A TEE will return this
            error code if the new SD name already exists in the TEE.</t>

            <t hangText="ERR_REQUEST_INVALID -"> This error will
            occur if the TEE meets any of the following conditions with a
            request message: (1) The request from a TAM has an
            invalid message structure; mandatory information is
            absent in the message. undefined member or structure is
            included.  (2) TEE fails to verify signature of the
            message or fails to decrypt its contents.</t>

            <t hangText="ERR_SPCERT_INVALID -">  If a new SP
            certificate for the SD to be updated is not valid, then
            the TEE will return this error code.</t>

            <t hangText="ERR_TA_ALREADY_INSTALLED -"> While installing a TA,
            a TEE will return this error if the TA has already been installed
            in the SD.</t>

            <t hangText="ERR_TA_INVALID -"> This error will occur when a TEE
            meets any of following conditions while checking validity of
            TA: (1) The TA binary has a format that the TEE can't recognize. (2)
            The TEE fails to decrypt the encoding of the TA binary and
            personalization data. (3) If an SP isn't registered with the SP SD
            where the TA will be installed.</t>

            <t hangText="ERR_TA_NOT_FOUND -"> This error will occur when
            the target TA doesn't exist in the SD.</t>

            <t hangText="ERR_TEE_FAIL -"> If the TEE fails to process a
              request because of an internal error, it will return this
              error code.</t>

            <t hangText="ERR_TEE_RESOURCE_FULL -"> This error is reported
            when a device resource isn't available anymore such as
            storage space is full.</t>

            <t hangText="ERR_TFW_NOT_TRUSTED -"> A TEE is responsible for
              determining that the underlying device firmware is trustworthy.
              If the TEE determines the TFW is not trustworthy, then
              this error will occur.</t>

            <t hangText="ERR_TAM_NOT_TRUSTED -">  Before processing a
            request, a TEE needs to make sure whether the sender TAM is
            trustworthy by checking the validity of the TAM certificate,
            etc. If the TEE finds that the TAM is not trustworthy, then
            it will return this error code.</t>

            <t hangText="ERR_UNSUPPORTED_CRYPTO_ALG -">  This error
            will occur if a TEE receives a request message encoded with
            cryptographic algorithms that the TEE doesn't support.</t>

            <t hangText="ERR_UNSUPPORTED_MSG_VERSION -">  This error
            will occur if a TEE receives a message version that
            the TEE can't deal with.</t>
          </list>
        </t>
        </section>
      </section>
    </section>

    <section anchor="security" title="Security Consideration">
      <section title="Cryptographic Strength">
        <t>The strength of the cryptographic algorithms, using the measure of
           'bits of security' defined in NIST SP800-57 allowed for OTrP
            is:</t>
        <t><list style="symbols">
         <t>At a minimum, 112 bits of security. The limiting factor for this is
            the RSA-2048 algorithm, which is indicated as providing 112 bits
            of symmetric key strength in
            SP800-57. It is important that RSA is supported in order to enhance
            the interoperability of the protocol.</t>
        <t>The option exists to choose algorithms providing 128 bits of
           security. This requires using TEE devices that support ECC P256.
        </t>
        </list>The available algorithms and key sizes specified in this document
          are based on industry standards.
          Over time the recommended or allowed cryptographic algorithms may
          change. It is important that the OTrP allows for crypto-agility.
          In this specification, TAM and TEE can negotiate an agreed upon
          algorithm where both include their supported algorithm in OTrP
          message.
        </t>
      </section>

      <section title="Message Security">
        <t>OTrP messages between the TAM and TEE are protected by message
        security using JWS and JWE. The 'Basic protocol profile' section of
        this document describes the algorithms used for this. All OTrP TEE
        devices and OTrP TAMs must meet the requirements of the basic profile.
        In the future additional 'profiles' can be added.</t>

        <t>PKI is used to ensure that the TEE will only communicate with a
        trusted TAM, and to ensure that the TAM will only communicate with a
        trusted TEE.</t>
      </section>

      <section title="TEE Attestation">
        <t>It is important that the TAM can trust that it is talking to a
        trusted TEE. This is achieved through attestation. The TEE has a private
        key and certificate built into it at manufacture, which is used to sign
        data supplied by the TAM. This allows the TAM to verify that the TEE is
        trusted. </t>

        <t>It is also important that the TFW (trusted firmware) can be checked.
        The TFW has a private key and certificate built into it at manufacture,
        which allows the TEE to check that that the TFW is trusted. </t>

        <t>The GetDeviceState message therefore allows the TAM to check that it
        trusts the TEE, and the TEE at this point will check whether it trusts
        the TFW. </t>
      </section>

      <section title="TA Protection">
        <t>
          A TA will be delivered in an encrypted form. This encryption is an
          additional layer within the message encryption described in the
          <xref target="basicprofile"/> of this document. The TA binary
          is encrypted for each target device with the device's TEE SP AIK
          public key. A TAM can either do this encryption itself or
          provide the TEE SP AIK public key to an SP such that the SP
          encrypts the encrypted TA for distribution to the TEE.
        </t>

        <figure>
          <preamble>The encryption algorithm can use a random AES 256 key
          "taek" with a 16 byte random IV, and the "taek" is encrypted by the
          "TEE SP AIK public key". The following encrypted TA data structure
          is expected by a TEE: </preamble>

          <artwork><![CDATA[
"encrypted_ta_bin": {
  "key": "<JWE enveloped data of a 256-bit symmetric key by
         the recipient's TEEspaik public key>",
  "iv": <hex of 16 random bytes>",
  "alg": "AESCBC",
  "cipherdata": "<BASE64 encoded encrypted TA binary data>"
}
         ]]></artwork>
        </figure>

      </section>

      <section title="TA Personalization Data">
      <t>
        An SP or TAM can supply personalization data for a TA to initialize for
        a device. Such data is passed through an InstallTA command from a TAM.
        The personalization data itself is (or can be) opaque to the TAM.
        The data can be from the SP without being revealed to the TAM.
        The data is sent in an encrypted manner in a
        request to a device such that only the device can decrypt. A device's
        TEE SP AIK public key for an SP is used to encrypt the data. Here JWE
        enveloping is used to carry all encryption key parameters along with
        encrypted data.
      </t>

        <figure>
          <artwork><![CDATA[
"encrypted_ta_data": { // "TA personalization data"
    "key": "<JWE enveloped data of a 256-bit symmetric key by
             the recipient's TEEspaik public key>",
    "iv": "<hex of 16 random bytes>",
    "alg": "AESCBC",
    "cipherdata": "<BASE64 encoded encrypted TA personalization
                   data>"
  }
         ]]></artwork>
        </figure>

      </section>

      <section title="TA Trust Check at TEE">
        <t>
        A TA binary is signed by a TA signer certificate. This TA signing
        certificate/private key belongs to the SP, and may be self-signed (i.e.,
        it need not participate in a trust hierarchy). It is the responsibility
        of the TAM to only allow verified TAs from trusted SPs into the system.
        Delivery of that TA to the TEE is then the responsibility of the TEE,
        using the security mechanisms provided by the OTrP.
        </t>

        <t>
        We allow a way for an (untrusted) application to check the
        trustworthiness of a TA. OTrP Broker has a function to allow
        a Client Application to query the information about a TA.
        </t>

        <t>
          An application in the Rich O/S may perform verification of the TA by
          verifying the signature of the TA. The GetTAInformation
          function is available to return the TEE supplied TA signer and TAM signer
          information to the application. An application can do additional
          trust checks on the certificate returned for this TA. It might trust
          the TAM, or require additional SP signer trust chaining.
        </t>
      </section>

      <section title="One TA Multiple SP Case">
        <t> A TA for multiple SPs must have a different identifier per SP.
          A TA will be installed in a different SD for each respective SP. </t>
      </section>

      <section title="OTrP Broker Trust Model">
        <t> An OTrP Broker could be malware in the vulnerable REE. A
        Client Application will connect its TAM provider for required TA
        installation. It gets command messages from the TAM, and passes
        the message to the OTrP Broker. </t>

        <t> The OTrP is a conduit for enabling the TAM to communicate
        with the device's TEE to manage SDs and TAs. All TAM messages are
        signed and sensitive data is encrypted such that the OTrP Broker cannot
        modify or capture sensitive data. </t>
      </section>

      <section title="OCSP Stapling Data for TAM Signed Messages">
        <t> The GetDeviceStateRequest message from a TAM to a TEE shall include
        OCSP stapling data for the TAM's signer certificate and for
        intermediate CA certificates up to the root certificate so that the TEE
        can verify the signer certificate's revocation status. </t>

        <t> A certificate revocation status check on a TA signer certificate is
        OPTIONAL by a TEE. A TAM is responsible for vetting a TA and the SP
        before it distributes them to devices. A TEE will
        trust a TA signer certificate's validation status done by a TAM when it
        trusts the TAM. </t>
      </section>

      <section title="Data Protection at TAM and TEE">
        <t> The TEE implementation provides protection of data on the device.
        It is the responsibility of the TAM to protect data on its servers. </t>
      </section>

      <section title="Privacy Consideration">
        <t> Devices are issued with a unique TEE certificate to attest the
          device's validity. This uniqueness also creates a privacy and
          tracking risk that must be mitigated. </t>

        <t> The TEE will only release the TEE certificate to a trusted TAM (it
        must verify the TAM certificate before proceeding). OTrP
        is designed such that only a TAM can obtain the TEE device
        certificate and firmware certificate - the GetDeviceState message
        requires signature checks to validate the TAM is trusted, and OTrP
        delivers the device's certificate(s) encrypted such that only that TAM
        can decrypt the response. A Client Application will never see the
        device certificate. </t>

        <t> An SP-specific TEE SP AIK  (TEE SP Anonymous Key) is generated by
        the protocol for Client Applications. This provides a way for the
        Client Application to validate some data that the TEE may send
        without requiring
        the TEE device certificate to be released to the client device rich O/S
        , and to optionally allow an SP to encrypt a TA for a target device
        without the SP needing to be supplied with the TEE device certificate. </t>
      </section>

      <section title="Threat Mitigation">
        <t> A rogue application may perform excessive TA loading. An OTrP Broker
        implementation should protect against excessive calls. </t>

        <t> Rogue applications might request excessive SD creation. The
        TAM is responsible to ensure this is properly guarded against. </t>

        <t> Rogue OTrP Broker could replay or send TAM messages out of
        sequence: e.g., a TAM sends update1 and update2. The OTrP Broker
        replays update2 and update1 again, creating an unexpected result that
        a client wants. "dsihash" is used to mitigate this. The TEE MUST
        store DSI state and check that the DSI state matches before it
        does another update.
        </t>

        <t> Concurrent calls from a TAM to a TEE MUST be handled properly by a
        TEE. If multiple concurrent TAM operations take place, these could
        fail due to the "dsihash" being modified by another concurrent operation.
        The TEE is responsible for resolve any locking such that one
        application cannot lock other applications from using the TEE, except
        for a short term duration of the TAM operation taking place. For
        example, an OTrP operation that starts but never completes (e.g. loss
        of connectivity) must not prevent subsequent OTrP messages from being
        executed. </t>
      </section>

      <section title="Compromised CA">
        <t> A root CA for TAM certificates might get compromised. Some TEE
        trust anchor update mechanism is expected from device OEMs. A compromised
        intermediate CA is covered by OCSP stapling and OCSP validation check
        in the protocol. A TEE should validate certificate revocation about a
        TAM certificate chain. </t>

        <t> If the root CA of some TEE device certificates is compromised,
        these devices might be rejected by a TAM, which is a decision of the
        TAM implementation and policy choice. Any intermediate CA for TEE device
        certificates SHOULD be validated by TAM with a Certificate
        Revocation List (CRL) or Online Certificate Status Protocol (OCSP)
        method.
        </t>
      </section>

      <section title="Compromised TAM">
        <t> The TEE SHOULD use validation of the supplied TAM certificates and
        OCSP stapled data to validate that the TAM is trustworthy. </t>

        <t> Since PKI is used, the integrity of the clock within the TEE
        determines the ability of the TEE to reject an expired TAM certificate,
        or revoked TAM certificate. Since OCSP stapling includes signature
        generation time, certificate validity dates are compared to the current
        time.</t>
      </section>

      <section title="Certificate Renewal">
        <t> TFW and TEE device certificates are expected to be long lived,
          longer than the
        lifetime of a device. A TAM certificate usually has a moderate
        lifetime of 2 to 5 years. A TAM should get renewed or rekeyed
        certificates. The root CA certificates for a TAM, which are embedded
        into the trust anchor store in
        a device, should have long lifetimes that don't require device trust
        anchor update. On the other hand, it is imperative that OEMs or device
        providers plan for support of trust anchor update in their shipped
        devices. </t>
      </section>

    </section> <!-- Security Consideration -->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We thank Alin Mutu for his contribution to many discussion that helped
      to design the trust flow mechanisms, and the creation of the flow diagrams.
      We also thank the following people (in alphabetical order) for their input
      and review: Sangsu Baek, Rob Coombs, Dapeng Liu, Dave Thaler, and
      Pengfei Zhao.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
     &RFC2119;
     &RFC4648;
     &RFC7159;
     &RFC7515;
     &RFC7516;
     &RFC7517;
     &RFC7518;
     <reference anchor="TEEPArch"
       target="https://tools.ietf.org/html/draft-ietf-teep-architecture-02">
       <front>
         <title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
         <author initials="M." surname="Pei" fullname="Mingliang Pei">
           <organization></organization>
         </author>
         <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
           <organization></organization>
         </author>
         <author initials="A." surname="Atyeo" fullname="Andrew Atyeo">
           <organization></organization>
         </author>
         <author initials="D." surname="Liu" fullname="Dapeng Liu">
           <organization></organization>
         </author>
         <date year="2018" />
       </front>
     </reference>
    </references>

    <references title="Informative References">
      <reference anchor="GPTEE">
        <front>
          <title>Global Platform, GlobalPlatform Device Technology:
            TEE System Architecture, v1.0</title>
          <author>
            <organization>Global Platform</organization>
          </author>
          <date year="2013" />
        </front>
      </reference>
      <reference anchor="GPTEECLAPI">
        <front>
          <title>Global Platform, GlobalPlatform Device Technology:
            TEE Client API Specification, v1.0</title>
          <author>
            <organization>Global Platform</organization>
          </author>
          <date year="2013" />
        </front>
      </reference>
    </references>

    <section anchor="samplemsgs" title="Sample Messages">
      <section title="Sample Security Domain Management Messages">
        <section title="Sample GetDeviceState">
          <section title="Sample GetDeviceStateRequest">
            <t>The TAM builds a "GetDeviceStateTBSRequest" message.</t>

            <figure>
              <artwork><![CDATA[
{
    "GetDeviceStateTBSRequest": {
      "ver": "1.0",
      "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B",
      "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
      "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==",
      "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==",
      "supportedsigalgs": "RS256"
    }
}
             ]]></artwork>
            </figure>

            <t>The TAM signs "GetDeviceStateTBSRequest", creating
            "GetDeviceStateRequest"</t>

            <figure>
              <artwork><![CDATA[
{
  "GetDeviceStateRequest": {
    "payload":"
    ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ
    InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0
    aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv
    Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N
    UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw
    SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2
    IgoJfQp9",
    "protected": "eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==",
              "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"]
    },
    "signature":"c2FtcGxlIHNpZ25hdHVyZQ"
  }
}
             ]]></artwork>
            </figure>

          </section>
          <section title="Sample GetDeviceStateResponse">
            <t>The TAM sends "GetDeviceStateRequest" to the OTrP Broker</t>
            <t>The OTrP Broker obtains "dsi" from each TEE. (In this example
            there is a single TEE.)</t>
            <t>The TEE obtains signed "fwdata" from firmware.</t>
            <t>The TEE builds "dsi" - summarizing device state of the TEE.</t>

            <figure>
              <artwork><![CDATA[
{
  "dsi": {
    "tfwdata": {
      "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=",
      "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==",
      "sigalg": "RS256",
      "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ=="
    },
    "tee": {
      "name": "Primary TEE",
      "ver": "1.0",
      "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==",
      "cacert": [
        "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=",
        "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI="
      ],
    "sdlist": {
      "cnt": "1",
      "sd": [
      {
        "name": "default.acmebank.com",
        "spid": "acmebank.com",
        "talist": [
          {
            "taid": "acmebank.secure.banking",
            "taname": "Acme secure banking app"
          },
          {
            "taid": "acmebank.loyalty.rewards",
            "taname": "Acme loyalty rewards app"
          }
        ]
      }
      ]
    },
    "teeaiklist": [
      {
        "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=",
        "spaiktype": "RSA",
        "spid": "acmebank.com"
      }
    ]
    }
  }
}
             ]]></artwork>
            </figure>

            <t>The TEE encrypts "dsi", and embeds it into a
              "GetDeviceTEEStateTBSResponse" message.</t>

            <figure>
              <artwork><![CDATA[
{
  "GetDeviceTEEStateTBSResponse": {
    "ver": "1.0",
    "status": "pass",
    "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}",
    "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
    "signerreq":"false",
    "edsi": {
      "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K",
      "recipients": [
        {
          "header": {
          "alg": "RSA1_5"
        },
        "encrypted_key":
        "
        QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg
        a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
        }
      ],
      "iv": "ySGmfZ69YlcEilNr5_SGbA",
      "ciphertext":
      "
      c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW
      NpcGllbnRzLmVuY3J5cHRlZF9rZXk",
      "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to
            the OTrP Broker. The OTrP Broker encodes "GetDeviceTEEStateResponse"
            into an array to form "GetDeviceStateResponse".</t>

            <figure>
              <artwork><![CDATA[
{
  "GetDeviceStateResponse": [
    {
      "GetDeviceTEEStateResponse": {
        "payload":
        "
        ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6
        ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5
        REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7
        NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy
        cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi
        ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp
        ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg
        ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk
        X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3
        Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg
        ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K
        ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog
        ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC
        a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC
        eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg
        InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg
        fQogIH0KfQ",
        "protected": "eyJhbGciOiJSUzI1NiJ9",
        "signature": "c2FtcGxlIHNpZ25hdHVyZQ"
      }
    }
  ]
}
             ]]></artwork>
            </figure>

            <t>The TEE returns "GetDeviceStateResponse" back to the OTrP Broker,
            which returns message back to the TAM.</t>

          </section>
        </section>

        <section title="Sample CreateSD">
          <section title="Sample CreateSDRequest">

            <figure>
              <artwork><![CDATA[
{
  "CreateSDTBSRequest": {
    "ver":"1.0",
    "rid":"req-01",
    "tid":"tran-01",
    "tee":"SecuriTEE",
    "nextdsi":"false",
    "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js",
    "content":{
      "spid":"bank.com",
      "sdname":"sd.bank.com",
      "spcert":"MIIDFjCCAn-
      gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD
      AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l
      hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN
      zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw
      FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA
      1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE
      BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU-
      lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE--
      3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca
      d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA
      wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp
      YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3
      S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB
      BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ-
      LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa-
      GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV
      THILI6afLCRWXXclc1L5KGY290OwIdQ",
      "tamid":"TAM_x.acme.com",
      "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>Below is a sample message after the content is encrypted
            and encoded</t>

            <figure>
              <artwork><![CDATA[
{
  "CreateSDRequest": {
  "payload":"
  eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG
  lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz
  aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz
  gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW
  dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey
  JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ
  c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG
  FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk
  dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2
  gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1
  bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj
  ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj
  UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW
  9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr
  TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW
  JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5
  Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0
  JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi
  ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE
  xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj
  XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm
  xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ
  UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj
  Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE
  emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj
  NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO
  dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV
  kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK
  TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD
  VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK
  N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV
  EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS
  bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU
  9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn
  RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF
  lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht
  UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD
  lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz
  dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2
  I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw
  T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2
  VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0
  WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk
  5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx
  VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG
  hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz
  QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren
  ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ",
  "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0",    //RSAwithSHA256
  "header": {
    "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
      "signer":"
      MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
      cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
      YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
      BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
      meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
      AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
      c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
      ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
      MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
      hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
      SZ1MdyIZV8fwdEmD90IvtMHgtzK-
      9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
      UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
        },
     "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y-
     N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz
     9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw"
  }
}
             ]]></artwork>
            </figure>

          </section>

          <section title="Sample CreateSDResponse">

            <figure>
              <artwork><![CDATA[
{
  "CreateSDTBSResponse": {
    "ver":"1.0",
    "status":"pass",
    "rid":"req-01",
    "tid":"tran-01",
    "content":{
      "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM",
      "sdname":"sd.bank.com",
      "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h-
      X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9
      GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE",
    }
  }
}
             ]]></artwork>
            </figure>

            <t>Below is the response message after the content is
            encrypted and encoded.</t>

            <figure>
              <artwork><![CDATA[
{
  "CreateSDResponse": {
    "payload":"
    eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi
    LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0
    ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy
    ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r
    ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s
    VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v
    Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j
    aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz
    Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT
    QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp
    ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW
    M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS
    RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4
    cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl
    Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn
    TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo
    ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ",
    "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0",
    "header": {
        "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
        "signer":"
            MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ
            BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
            Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN
            MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET
            MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G
            A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB
            AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
            meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
            AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA
            6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
            ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ
            BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
            Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX
            9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E
            DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv
            em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK-
            9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV
            rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
    },
    "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U-
    qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn-
    R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs-
    hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900"
  }
}
             ]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Sample UpdateSD">
          <section title="Sample UpdateSDRequest">
            <figure>
              <artwork><![CDATA[

{
  "UpdateSDTBSRequest": {
    "ver": "1.0",
    "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A",
    "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
    "tee": "Primary TEE ABC",
    "nextdsi": "false",
    "dsihash":
    "
    IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf
    w5o7",
    "content": { // NEEDS to BE ENCRYPTED
      "tamid": "id1.TAMxyz.com",
      "spid": "com.acmebank.spid1",
      "sdname": "com.acmebank.sdname1",
      "changes": {
        "newsdname": "com.acmebank.sdname2",
        "newspid": "com.acquirer.spid1",
        "spcert":
        "MIIDFjCCAn-
        gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4
        wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x
        hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc
        NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw
        GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN
        pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0
        GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0
        hCWJRaFzt5mU-
        lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE--
        3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d
        cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj
        EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2
        9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg
        kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA
        wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ-
        LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa
        -
        GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1
        QVTHILI6afLCRWXXclc1L5KGY290OwIdQ",
        "renewteespaik": "0"
      }
    }
  }
}
             ]]></artwork>
            </figure>

          </section>

          <section title="Sample UpdateSDResponse">
            <t></t>

            <figure>
              <artwork><![CDATA[
{
  "UpdateSDTBSResponse": {
    "ver": "1.0",
    "status": "pass",
    "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A",
    "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
    "content": {
      "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
      "teespaik":
      "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h-
      X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9
      GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE",
      "teespaiktype": "RSA"
    }
  }
}
             ]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Sample DeleteSD">
          <section title="Sample DeleteSDRequest">
<t>The TAM builds message - including data to be encrypted.</t>
            <figure>
              <artwork><![CDATA[
{
     "DeleteSDTBSRequest": {
       "ver": "1.0",
       "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
       "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
       "tee": "Primary TEE",
       "nextdsi": "false",
       "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=",
       "content": ENCRYPTED {
         "tamid": "TAM1.com",
         "sdname": "default.acmebank.com",
         "deleteta": "1"
       }
     }
   }
             ]]></artwork>
            </figure>

            <t>The TAM encrypts the "content".</t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteSDTBSRequest": {
    "ver": "1.0",
    "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
    "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
    "tee": "Primary TEE",
    "nextdsi": "false",
    "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=",
    "content": {
    "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
    "recipients": [
      {
        "header": {
          "alg": "RSA1_5"
        },
      "encrypted_key":
      "
      QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2
      V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
      }
    ],
    "iv": "rWO5DVmQX9ogelMLBIogIA",
    "ciphertext":
    "
    c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp
    cGllbnRzLmVuY3J5cHRlZF9rZXk",
    "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
    }
  }
}
             ]]></artwork>
            </figure>

            <t>The TAM signs the "DeleteSDTBSRequest" to form a "DeleteSDRequest"</t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteSDRequest": {
    "payload":"
    ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp
    ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ
    InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs
    CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ
    CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr
    S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps
    Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb
    ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ
    CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq
    Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1
    WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt
    UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6
    YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2
    YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog
    ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9",
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==",
              "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"]
    },
    "signature":"c2FtcGxlIHNpZ25hdHVyZQ"
  }
}
             ]]></artwork>
            </figure>

          </section>

          <section title="Sample DeleteSDResponse">
            <t>The TEE creates a "DeleteSDTBSResponse" to respond to
              the "DeleteSDRequest" message from the TAM, including
              data to be encrypted.</t>

            <figure>
              <artwork><![CDATA[
  {
     "DeleteSDTBSResponse": {
       "ver": "1.0",
       "status": "pass",
       "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
       "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
       "content": ENCRYPTED {
         "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
       }
     }
   }
             ]]></artwork>
            </figure>


<t>The TEE encrypts the "content" for the TAM.</t>

            <figure>
              <artwork><![CDATA[
   {
    "DeleteSDTBSResponse": {
     "ver": "1.0",
     "status": "pass",
     "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
     "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
      "content": {
      "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K",
      "recipients": [
        {
          "header": {
          "alg": "RSA1_5"
        },
        "encrypted_key":
        "
        QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg
        a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
        }
      ],
      "iv": "ySGmfZ69YlcEilNr5_SGbA",
      "ciphertext":
      "
      c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW
      NpcGllbnRzLmVuY3J5cHRlZF9rZXk",
      "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
      }
     }
   }
             ]]></artwork>
            </figure>

            <t>The TEE signs "DeleteSDTBSResponse" to form
            a "DeleteSDResponse"</t>

            <!-- TBD The content doesn't look to be encrypted.
                 Need encrypt the content first to get TBS request. -->

            <figure>
              <artwork><![CDATA[
{
  "DeleteSDResponse": {
    "payload":"
    ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz
    dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB
    NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3
    LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0
    ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj
    aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81
    IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ
    R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh
    MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2
    IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj
    MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP
    Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs
    CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK
    CQl9Cgl9Cn0",
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "signature":"c2FtcGxlIHNpZ25hdHVyZQ"
  }
}
             ]]></artwork>
            </figure>

            <t>The TEE returns "DeleteSDResponse" back to the OTrP Broker, which
            returns the message back to the TAM.</t>
          </section>
        </section>

      </section> <!-- SD Mgmt -->

      <!-- TBD encrypted data format with JWE enveloping / ECDH case -->
      <section title="Sample TA Management Messages">
        <section title="Sample InstallTA">
          <section title="Sample InstallTARequest">
            <figure>
              <artwork><![CDATA[
{
  "InstallTATBSRequest": {
    "ver": "1.0",
    "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207",
    "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
    "tee": "Primary TEE ABC",
    "nextdsi": "true",
    "dsihash":
    "
    IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf
    w5o7",
    "content": {
      "tamid": "id1.TAMxyz.com",
      "spid": "com.acmebank.spid1",
      "sdname": "com.acmebank.sdname1",
      "taid": "com.acmebank.taid.banking"
    },
    "encrypted_ta": {
      "key":
      "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE
      ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ
      MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT
      /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ
      6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj
      //Lq0gGtq8vPC8r0oOfmbQ==",
      "iv": "4F5472504973426F726E496E32303135",
      "alg": "AESCBC",
      "ciphertadata":
      "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=",
      "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk="
    }
  }
}
             ]]></artwork>
            </figure>
          </section>

          <section title="Sample InstallTAResponse">
            <t>A sample to-be-signed response of InstallTA looks as
            follows.</t>

            <figure>
              <artwork><![CDATA[
{
  "InstallTATBSResponse": {
    "ver": "1.0",
    "status": "pass",
    "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207",
    "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
    "content": {
      "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
      "dsi": {
        "tfwdata": {
          "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0="
          "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==",
          "sigalg": "UlMyNTY=",
          "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ=="
        },
        "tee": {
          "name": "Primary TEE",
          "ver": "1.0",
          "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==",
          "cacert": [
            "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=",
            "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI="
          ],
          "sdlist": {
            "cnt": "1",
            "sd": [
              {
                "name": "com.acmebank.sdname1",
                "spid": "com.acmebank.spid1",
                "talist": [
                    {
                    "taid": "com.acmebank.taid.banking",
                    "taname": "Acme secure banking app"
                    },
                    {
                    "taid": "acom.acmebank.taid.loyalty.rewards",
                    "taname": "Acme loyalty rewards app"
                    }
                ]
              }
            ]
          },
          "teeaiklist": [
            {
              "spaik":
                "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=",
              "spaiktype": "RSA"
              "spid": "acmebank.com"
            }
          ]
        }
      }
    }
  }
}
             ]]></artwork>
            </figure>

          </section>
        </section>

        <section title="Sample UpdateTA">
          <section title="Sample UpdateTARequest">

            <t></t>

            <!-- comments from doc:
            1. Document says to use hex encoding.
            2. Secondly, the raw data should be 16 bytes.
            3. dsidash contains non legitimate character '_' for BASE64
            -->

            <figure>
              <artwork><![CDATA[
{
  "UpdateTATBSRequest": {
    "ver": "1.0",
    "rid": "req-2",
    "tid": "tran-01",
    "tee": "SecuriTEE",
                "nextdsi": " false",
    "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
    "content": {
      "tamid": "TAM1.acme.com",
      "spid": "bank.com",
      "sdname": "sd.bank.com",
      "taid": "sd.bank.com.ta"
    },
    "encrypted_ta": {
      "key":
      "
      XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt
      GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL
      A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc",
      "iv": "AxY8DCtDaGlsbGljb3RoZQ",
      "alg": "AESCBC",
      "ciphernewtadata":
      "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U-
      67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl
      XZYTNkENcABPpuw_G3I3HADo"
    }
  }
}
             ]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[
{
  "UpdateTARequest": {
    "payload" :
    "
    eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0
    aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi
    ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu
    NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo
    VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s
    ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L
    bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft
    YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky
    SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD
    dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w
    SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04
    QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3
    azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5
    MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO
    V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp
    bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR
    ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v
    YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp
    cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF
    LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo
    MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ",
    "protected": " eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
      "signer":"
      MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
      cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
      YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
      BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
      meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
      AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
      c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
      ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
      MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
      hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
      SZ1MdyIZV8fwdEmD90IvtMHgtzK-
      9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
      UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
    },
    "signature":"inB1K6G3EAhF-
    FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr-
    myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX
    6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU"
  }
}
             ]]></artwork>
            </figure>

          </section>

          <section title="Sample UpdateTAResponse">
            <figure>
              <artwork><![CDATA[
{
  "UpdateTATBSResponse": {
    "ver": "1.0",
    "status": "pass",
        "rid": "req-2",
        "tid": "tran-01",
        "content": {
      "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
    }
  }
}
             ]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[
{
  "UpdateTAResponse":{
    "payload":"
    eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi
    LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl
    ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb
    eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB
    UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK
    YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3
    VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu
    bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl
    cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw
    eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6
    Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19",
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
      "signer":"
      MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
      cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
      YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
      BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
      meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
      AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
      c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
      ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
      MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
      hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
      SZ1MdyIZV8fwdEmD90IvtMHgtzK-
      9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
      UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
    },
    "signature":"
    Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo
    PLaws8zzh-SNIQ42-
    9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm-
    nMk14grVZygwAPej3ZZk"
  }
}
             ]]></artwork>
            </figure>
          </section>
        </section>

        <section title="Sample DeleteTA">
          <section title="Sample DeleteTARequest">

            <t></t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteTATBSRequest": {
    "ver": "1.0",
    "rid": "req-2",
    "tid": "tran-01",
    "tee": "SecuriTEE",
    "nextdsi": "false",
    "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
    "content": {
      "tamid": "TAM1.acme.com",
      "sdname": "sd.bank.com",
      "taid": "sd.bank.com.ta"
    }
  }
}
             ]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[
{
  "DeleteTARequest": {
    "payload":
    "
    eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0
    aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi
    ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu
    NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s
    InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk
    X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS
    TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS
    WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n
    d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq
    YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ
    dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR
    bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG
    Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0",
    "protected" : "eyJhbGciOiJSUzI1NiJ9",
    "header":   {
      "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
      "signer":"
      MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
      cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
      YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
      BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
      meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
      AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
      c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
      ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
      YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
      HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
      MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
      hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
      SZ1MdyIZV8fwdEmD90IvtMHgtzK-
      9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
      UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
    },
    "signature" :
    "
    BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe
    _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd-
    PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE"
  }
}
             ]]></artwork>
            </figure>
          </section>

          <section title="Sample DeleteTAResponse">
            <figure>
              <artwork><![CDATA[
{
  "DeleteTATBSResponse": {
    "ver": "1.0",
    "status": "pass",
        "rid": "req-2",
        "tid": "tran-01",
        "content": {
      "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
    }
  }
}             ]]></artwork>
            </figure>

            <t></t>

            <figure>
              <artwork><![CDATA[
{
  "DeleteTAResponse":{
    "payload":"
    ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz
    dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t
    MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC
    Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi
    OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2
    eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD
    X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY
    el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU
    bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq
    YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01
    WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0
    Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt
    b0xkTlJkTHRTAMIzUTdrYXciDQoJCX0NCgl9DQp9",
    "protected": "eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
      "signer":"
      MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ
      BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
      Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN
      MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET
      MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G
      A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB
      AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
      meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
      AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA
      6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
      ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ
      BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
      Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX
      9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E
      DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv
      em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK-
      9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV
      rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
    },
    "signature":"
    DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ
    CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V
    Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg"
  }
}
             ]]></artwork>
            </figure>
          </section>
        </section>

      </section> <!-- TA Mgmt -->

      <section title="Example OTrP Broker Option">
        <t>
          The most popular TEE devices today are Android powered devices.
          In an Android device, an OTrP Broker can be a bound service
          with a service registration ID that a Client Application can use.
          This option allows a Client Application not to depend on any OTrP
          Broker SDK or provider.
        </t>
        <t>
          An OTrP Broker is responsible to detect and work with more than one
          TEE if a device has more than one. In this version, there is only
          one active TEE such that an OTrP Broker only needs to handle the active
          TEE.
        </t>
      </section>
    </section>

    <section anchor="Contributors" title="Contributors">
        <figure>
          <artwork><![CDATA[
- Brian Witten
  Symantec
  brian_witten@symantec.com

- Tyler Kim
  Solacia
  tylerkim@iotrust.kr
         ]]></artwork>
        </figure>
    </section>
  </back>
</rfc>