Home › The Technical Framework

The Technical Framework

You are viewing an archival website from the original trustmark pilot in 2013-2016. If you are looking for more recent content about the trustmark framework, please visit the Trustmark Initiative website.

This page provides an introduction to the trustmark framework concept, and includes the following topics.

For a higher-level technical discussion of the trustmark concept, including the motivation and rationale for the concept, please see the Trustmark Concept page.

An Overview of the Trustmark Framework

Let’s start with some basic facts about trustmarks and the trustmark framework.

  • A trustmark is a statement of conformance to a well-scoped set of identity trust and/or interoperability requirements.
  • A Trustmark Provider (TP) issues a trustmark to a Trustmark Recipient (TR) based on a formal assessment process.
  • The Trustmark is issued under a Trustmark Policy and is subject to a Trustmark Agreement.
  • The formal assessment process for a trustmark is specified by a Trustmark Definition (TD).
  • A Trustmark Definition is developed and maintained by a Trustmark Defining Organization (TDO), which represents the interests of one or more Stakeholder Communities.
  • Possession of a Trustmark by the Trustmark Recipient is required by a Trustmark Relying Party (TRP), which treats the trustmark as 3rd-party-verified evidence that the Trustmark Recipient meets the trust and/or interoperability requirements set forth in the Trustmark Definition for the trustmark.
  • A Stakeholder Community defines a Trust Interoperability Profile (TIP) that expresses trust criteria as a set of trustmarks that a Trustmark Recipient must possess, in order to meet the trust and interoperability requirements of Trustmark Relying Parties in that community.

The figure below illustrates the full “concept map” and shows the interrelationships between all of the entities discussed above.

The Trustmark Concept MapThe Trustmark Concept Map

Here are a few points of clarification.

  • A trustmark must be digitally signed by the TP that issued it. In addition, it may be required to be digitally countersigned by the TR that received it.
  • A TDO is similar to an SDO in its function.
  • A TD is similar to a normative technical specification (e.g., an industry standard), with one crucial difference: A TD includes not only a list of conformance criteria that the TR must meet, but also a list of assessment steps that an independent 3rd-party TP must follow to determine whether the TR conforms as required.
  • Because a TD includes assessment criteria in addition to conformance criteria, it is not unreasonable to assume that in many cases, an instance of Trustmark X that was issued from TP A is equivalent in meaning to another instance of Trustmark X that was issued from TP B. The implications of this equivalence are significant, as it allows for the commoditization of trustmarks. If Trustmark X is viewed as a commodity, then a competitive trustmark marketplace can form around it, allowing many TPs to offer Trustmark X and compete with each other on price and quality of service, but not the on any meaningful form of differentiation as to the meaning of the trustmark itself.
  • A TR must be a business or other organizational entity (e.g., a government agency, non-profit agency, etc.), while a TRP may be either an organization or an individual user. The Privacy Page of this website presents a simple example of a privacy-related trustmark that is required by end-users.
  • A TIP is essentially a formal statement that lists the trustmarks that one entity must have in order to be trusted by, and interoperable with, another entity.

Parallels Between Trustmarks and PKI

In principle, many aspects of the trustmark concept have parallels in the well-understood concept of a Public Key Infrastructure (PKI). The table below illustrates how various concepts from a trustmark framework map to similar concepts from PKI.

Parallels Between the Trustmark Framework Concept and the PKI Concept

Here are some of the obvious conceptual similarities between the trustmark model and the PKI model.

  • A Trustmark (Certificate) represents a specific set of facts asserted to a Trustmark Relying Party (Certificate Relying Party, or Audience) about a Trustmark Recipient (Subscriber).
  • The roles, responsibilities, and terms of use for a Trustmark (Certificate) are described in a Trustmark Policy (Certificate Policy).
  • The scope and terms of the legal agreement between the Trustmark Provider (Certificate Authority) and the Trustmark Recipient (Subscriber) are delineated in a Trustmark Recipient Agreement (Subscriber Agreement).

As indicated in the last few rows of the table above, there are also other similarities between the trustmark framework and PKI, but some of these additional aspects of the analogy are not as strong as those which are explicitly called out above.

The Trustmark Framework versus The Trustmark Marketplace

The above sections of this page explore the concept of a trustmark framework. In this section we turn from the framework to the operational trustmark marketplace that the framework enables. Just as the PKI framework enables an ecosystem of PKI-related actors (e.g., CAs, subscribers, etc.), and the DNS framework enables a similar ecosystem of DNS-related actors (e.g., domain names, domain name registrars, domain name registrants, etc.), a trustmark framework enables an ecosystem of trustmark-related actors.

The diagram below depicts how the trustmark marketplace will likely look as it begins to take shape. It will likely include the following actors and entities.

  • TPs will issue various trustmarks to TRs. There will likely be many TPs, and any given TP will likely offer one or more trustmarks, in accordance with its areas of expertise and its business interests. Any trustmark issued by a TP must conform to the TD for that trustmark.
  • There will exist many COIs, and each COI can define a TIP that specifies: (1) what trustmarks are required for various roles (e.g., IDPs, APs, SPs) within the COI, and (2) what TPs are considered to be trustworthy within that COI for each trustmark. In some cases, the TIP defined by a COI may not be authoritative, but may instead merely represent general guidance or “best practices” that members of the COI are encouraged to obey.
  • TRs will acquire trustmarks from TPs in accordance with their business needs. TRs decide which trustmarks to acquire, based on the guidance provided via the TIP(s) of the COI(s) in which they want to participate.
  • TRPs can use trustmarks as their primary basis for trusting other entities for the purpose of identity reuse. TRPs may participate within a COI or COIs in one or more roles, e.g., IDP, AP, SP, etc. If participating in the role of IDP, a TRP can use trustmarks as its primary basis for trusting SPs. Conversely, if participating in the role of SP, a TRP can use trustmarks as its primary basis for trusting IDPs and APs. Note that a TRP can define and publish its own TIP, based on guidance offered via the TIP(s) of the COI(s) in which it participates.
  • There can be one or more Trustmark Registries, which address practical concerns of discoverability within the trustmark marketplace. Specifically, a Trustmark Registry would help TRs and TRPs discover each other’s trustmarks and TIPs.

The Trustmark MarketplaceThe Trustmark Marketplace

Note that TDOs are not depicted in the diagram; however, they also play a role in the trustmark marketplace by defining and publishing specific TDs that are used by the other actors in the marketplace.

Diving Deeper into the Framework: Advanced Topics

This page provides a very basic overview of the trustmark framework at a technical level. For more information about specific aspects of the trustmark framework, please visit the pages listed below.

  • The Specifications and Instances page discusses how we can use normative technical specifications for TDs, trustmarks, and TIPs to enable participants in the Trustmark Marketplace to clearly define, understand, and compare each other’s trust and interoperability requirements.
  • The Trustmark Revocation page discusses what we can do when something goes wrong and a TP must revoke a trustmark from a TR.
  • The Legal Framework page discusses the legal aspects of trustmark issuance and reliance.
  • The Trustmark Binding and Usage page discusses how we can bind trustmarks to operational system endpoints for run-time usage.