Trustmark Framework in Detail

This page discusses the Trustmark Framework (TMF) in greater detail. We cover the following topics:

TMF Design Goals

The TMF was designed to meet the following goals, all of which are consistent with the philosophy and goals of the Assertion-Based Architecture (ABA).

  1. Agility – Meet the trust needs of a wide range of organizations and individuals from disparate communities, with a wide range of interrelationships, across a wide range of use cases.
  2. Scalability and Decentralization – Be able to grow to Internet scale, i.e., handle thousands (or more) of participating organizations, and millions (or more) of participating individuals. To meet this goal, the framework must be fully decentralized, i.e., it must not require substantial centralized coordination for its operation.
  3. Componentization of Trust Requirements – Enable the decomposition of trust requirements into arbitrary-sized components, so that users of the framework can factor trust requirements into components that best facilitate component reuse.
  4. Automatability and Machine-Readability – Enable machine-readability of various technical artifacts, including trustmarks and other objects, through appropriate technical specifications, to promote the development of software tools that can help manage the inherent complexity of the framework.
  5. Trust Requirement Bundling for Business Cases – Enable the aggregation of trust components into trust requirement bundles, or profiles, to meet the trust prerequisites of specific business cases as prescribed by organizations or individuals, or to comply with requirements prescribed by law.
  6. Implementability under a Practical Legal Framework – Address the practicalities of its implementation and use within a legal context. As the framework inherently supports a large number of participating organizations and individuals, it must include mechanisms to enable those participants to enter into appropriate legal agreements underpinning the trust relationships that the framework enables.

TMF Basic Concepts

The diagram below illustrates the basic concepts and terms of the TMF.

The Trustmark Framework
Trustmark Framework Basics

The framework includes the following concepts and interrelationships. Note that all these aspects of the TMF are rigorously defined in a normative Trustmark Framework Technical Specification (TMFTS), which is available here.

Trustmark (TM) A trustmark (TM) is a machine-readable, cryptographically signed digital artifact that represents a statement of conformance to a well-defined set of requirements. The issuer of a TM must cryptographically sign it to ensure its integrity. The TMFTS provides an XML-based normative specification for TM objects.

Trustmark Provider (TP) A trustmark provider (TP) is an entity that issues a TM based on a formal assessment process. The TM serves as a formal attestation by the TP that the recipient conforms to a well-defined set of requirements. The TM is issued under a legal framework, which we discuss here. Any number of TPs can exist in the framework.

Trustmark Recipient (TR) A trustmark recipient (TR) is an entity that receives a TM from a TP. Note that a TR is always an organization or other business entity; TMs are not intended for issuance to individuals.

Trustmark Definition (TD) A trustmark definition (TD) specifies the conformance criteria that a prospective TR must meet, as well as the formal assessment process that a TP must perform to assess whether a prospective TR qualifies to receive a specific type of TM. There can be many different types of TMs, and each type of TM has its own TD. The TMFTS provides an XML-based normative specification for TD objects.

Trustmark Defining Organization (TDO) A TD is developed and maintained by a trustmark defining organization (TDO), which represents the interests of a stakeholder community. A TDO is similar in function to a standards development organization. A TDO does not play an active role in the issuance of a TM, and does not enter into any legal agreement as part of the issuance or use of TMs. Its only role is to represent a stakeholder community and publish TDs that represent the requirements of that community. Any number of TDOs can exist in the framework.

Trustmark Relying Party (TRP) Possession of a TM by a TR is required by a trustmark relying party (TRP), which treats the TM as formal artifact or evidence indicating that the TR meets the trust criteria set forth in the TD for the TM. When it relies on a TM, a TRP enters into a legal agreement with the TP, in accordance with the legal framework that we describe here. A TRP may be either an organization or an individual.

Trust Interoperability Profile (TIP) A TRP can define a trust interoperability profile (TIP) that expresses a trust policy in terms of a set or bundle of TMs that a TR must possess to meet its trust requirements. The TMFTS provides an XML-based normative specification for TIP objects. Given the TIP of a TRP and a set of TMs possessed by a TR, we can compute whether a state of trust interoperability exists between the TRP and the TR. Note that for most real-world use cases, every participant imposes trust requirements on the other participant(s). Therefore, organizations would typically act as both a TRP (imposing requirements on other participants through a TIP) and a TR (obtaining TMs to comply with the TIPs of other participants) within the context of a single use case.

Trustmark Status Report (TSR) After issuing a TM, a TP must publish a trustmark status report (TSR) (not shown in diagram) that provides an online, queryable source of status information about the TM. The TP must then update the TSR as needed if the TM’s status changes, e.g., from “active” to “revoked” or “expired”. A TRP may query the TSR periodically or as needed, based on its risk tolerance, to check whether the TM is still valid and suitable for use as a basis for trust. The TMFTS provides an XML-based normative specification for TSR objects.

In addition to the basic TMF, there exists a trustmark legal framework to support issuance, use, and reliance upon TMs as the basis of trust in live, operational use cases. The following diagram illustrates the trustmark legal framework:

The Trustmark Legal Framework
The Trustmark Legal Framework

Within this framework, a TM is issued to a TR by a TP under a trustmark recipient agreement (TRA), which is a standard two-party contract that establishes an explicit legal agreement between the TP and TR. The TRA incorporates a trustmark policy by reference. The TP and TR both must sign the TRA to execute it.

When a TRP chooses to rely upon a trustmark, the TRP must enter into a trustmark relying party agreement (TRPA) with the TP. The TRPA is also a two-party contract; however, it is not a standard two-party agreement that both parties must sign. Instead, it is a “clickwrap” or “clickthrough” agreement that becomes effective by virtue of the TRP using or relying on a TM issued by the TP. The TRPA also incorporates the trustmark policy by reference.

Note, as indicated by the above diagram, that a TM object contains references to both the trustmark policy under which it was issued and the TRPA to which all TRPs are subject if they choose to use or rely upon the TM. Note also that even though the purpose of a TM is to provide a basis for trust between the TR and TRP, the trustmark legal framework does not establish an explicit legal relationship between these two entities. Instead, it establishes separate explicit legal relationships between each entity and a third party, the TP, which issued the TM.

Establishment of a suitable trustmark policy, TRA, and TRPA are mandatory for the issuance of a TM, as stipulated in the TMFTS; however, the TMFTS does not provide any further requirements or guidance as to what structure these three documents must follow or what content they must contain.

Summary of TMF Pilot Activities

To date, the TMF has been used in two operational pilots, both of which revolved around establishing scalable trust for information-sharing missions, including:

  1. It was used as part of an initial pilot within the National Identity Exchange Federation (NIEF). This initial pilot demonstrated the viability of the core TMF concept, as well as the legal framework.
  2. It was used within a pilot project of the Alabama Secure Sharing Utility for Recidivism Elimination (ASSURE). The ASSURE pilot helped to demonstrate the TMF’s value as a tool for componentizing and harmonizing trust-related requirements (e.g., requirements related to security, privacy, interoperability, etc.) from two distinct communities — in this case, the state and local law enforcement community and the mental health and substance abuse counseling community.

These two pilots combined to demonstrate the soundness of the TMF as a framework for building scalable trust in support of information sharing, and the TMF is still being used by both of these communities as a foundation for trust.

For More Information...
To learn more about the TMF, please see the GTRI NSTIC Trustmark Pilot Website.