Home › The Trustmark Concept

The Trustmark Concept

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 a high-level overview of the trustmark concept, and includes the following topics.

For a deeper technical discussion of the trustmark framework, please see the Technical Framework page.

A Brief History and the Current State of Federated Identity

Before the advent of federated identity technologies, every application was an identity silo. Identities and their associated attributes were effectively locked inside applications and unavailable for reuse.

In the early 2000s, SAML and other federated identity protocols enabled us to begin decoupling identities and attributes from applications. Adoption of these protocols enabled limited reuse of identities, mostly within large organizations, and occasionally across organizational boundaries within a limited scope. But up to now, wide-scale reuse of identities has proven to be impractical, due to concerns about trust, liability, and security that are outside the scope of federated identity protocols.

Application-Specific Identity Silos vs. Federated Identity Silos

Application-Specific Identity Silos vs. Federated Identity Silos

As a result, the net effect of federated identity is that we’ve moved from application-specific identity silos to federated identity silos. Whereas we used to have little or no identity reuse, we now have limited identity reuse. And while limited reuse is better than none, it is far from ideal.

Basic Terms, Assumptions, and Assertions about the Identity Ecosystem

Before going any further, here are a few items of clarification.

1. For our purposes, the following terms are equivalent.

Equivalent TermsEquivalent Terms

2. We define a trust framework as follows:

A trust framework is any structure that builds trust among autonomous actors for the purpose of sharing and reusing identities.

3. We assume that every Federation, Community of Interest, and Information Sharing Environment is built atop a trust framework, whether implied or explicit. There are thus many trust frameworks in the Identity Ecosystem today.

4. We assert that most, if not all, existing trust frameworks are both monolithic and opaque. To clarify:

  • By monolithic, we mean that a trust framework is designed so as to require its participants to be 100% in the framework, e.g., as a “member”, or 100% outside the framework, e.g., as a “non-member”. A monolithic framework typically does not accommodate the concept of “partial” membership.
  • By opaque, we mean that deriving and understanding a trust framework’s full set of membership requirements requires a careful review of all its membership documents, policies, procedures, agreements, and technical specifications.

The diagram below depicts three trust frameworks within the Identity Ecosystem. Each trust framework has one or more IDPs, one or more APs, and one or more RPs.

Monolithic and Opaque Trust Frameworks

5. We assert that the monolithic and opaque nature of today’s trust frameworks is a major impediment to achieving the wide scale of cross-framework trust that would be required to support wide-scale identity reuse within the Identity Ecosystem.

In the diagram above, suppose that a user from an IDP in ISE A needs to access a resource managed by an RP in COI C. In today’s Identity Ecosystem, there are five ways to establish the trust necessary to enable the user to access the required resource, and each way faces significant challenges.

  • Option #1: User Creates a New Identity: The user can create a new identity at an IDP in COI C. But then the user must manage multiple identities, and we have effectively discarded the goal of identity reuse.
  • Option #2: IDP Joins a New Trust Framework: The user’s IDP, which is already part of ISE A, can join COI C by becoming a member of its trust framework. But joining a new trust framework is costly and expensive, especially when the framework is monolithic and opaque.
  • Option #3: RP Joins a New Trust Framework: The RP, which is already part of COI C can join ISE A by becoming a member of its trust framework. This option carries the same drawbacks as Option #2.
  • Option #4: Establish a Cross-Framework Trust Relationship: ISE A and COI C can try to establish a cross-framework trust relationship, to enable all the IDPs from ISE A to be trusted by all the RPs from COI C. But this strategy, which we call interfederation, is fraught with challenges at many levels, including technical, policy, and especially legal agreements.
  • Option #5: Establish a Bilateral Trust Relationship: The user’s IDP and the the RP can establish a bilateral trust relationship, outside the scope of the respective trust frameworks in which they operate. While this strategy may be relatively simple as a “one-off” solution, it is highly unscalable when viewed from the perspective of the entire Identity Ecosystem.

None of these options is a particularly elegant strategy for scaling interoperability and trust throughout the Identity Ecosystem. But whether this is truly a “problem” depends on one’s perspective.

How Perspective Influences Perception of whether the Identity Ecosystem “Works” Today

We assert that today’s Identity Ecosystem, with its diverse collection of monolithic, opaque, non-interoperable trust frameworks, is ill-suited to accommodate the proliferation of wide-scale trust and interoperability that is required for wide-scale identity reuse. But does that matter? It depends on your perspective.

A Variety of Perspectives
Is the Identity Ecosystem about only identification and authentication? Or are attributes and authorization also fundamental to it?
Will the Identity Ecosystem have many trust frameworks with few IDPs in each? Or few trust frameworks with many IDPs in each? Or something else?
Will trust frameworks remain static over time? Or must they constantly evolve to meet new requirements?
Will the Identity Ecosystem have only a few IDPs with consistent user bases and requirements? Or a large number of IDPs with heterogeneous user bases and requirements?
Is it OK if the trust frameworks in the identity ecosystem are mostly non-interoperable and non-trusting identity silos? Or does success demand that we at least provide a viable strategy and framework for trust and interoperability between various COIs, ISEs, and Federations?

Why We Believe the Identity Ecosystem is Inadequate for Many COIs Today

Since 2005, GTRI has been working on behalf of multiple Federal sponsors to serve the federated identity needs of the U.S. state and local Law Enforcement (LE) COI by providing engineering and technical support for the Global Federated Identity and Privilege Management (GFIPM) program. In addition, since 2008 GTRI has been providing operational support for the National Identity Exchange Federation (NIEF), which leverages GFIPM to serve law enforcement and other, related COIs.

The Perspective from the Law Enforcement CommunityThe Perspective from the Law Enforcement Community

Here is what we have learned over nearly 10 years working with the LE COI.

  • The LE COI is large (1M+ users in 10k+ agencies) and diverse (autonomous agencies with funding from a variety of sources and a variety of heterogeneous requirements).
  • Many LE agencies requiring 3rd-party verified trust in other agencies (i.e., bilateral trust relationships are often a non-starter).
  • Since the events of September 11, 2001, the LE COI has been working under a Federal mandate to share data across jurisdictions, but to do so with respect to applicable laws and other policies regarding access control.
  • LE agencies have a business need to communicate and collaborate with a multitude of other COIs: first responders (firefighters, EMTs, etc.), healthcare, courts, critical infrastructure industries (the electric power industry, the oil & gas industry, etc.), insurance, finance, and others.

In other words, we have learned that if the Identity Ecosystem is to adequately serve the needs of the LE COI and other complex and diverse COIs, then we must design it from the ground up so that it can scalably fulfill many diverse and challenging requirements that it cannot handle today.

How Trustmarks Can Help Fix What is Wrong

If an Identity Ecosystem based on a collection of monolithic and opaque trust frameworks cannot fulfill the needs of the LE COI and others, then what type of Identity Ecosystem can meet those needs? We believe that one viable way forward is to begin building trust frameworks using modular, reusable components.

If trust frameworks were modular, then we can get:

  • Greater transparency of trust frameworks’ requirements;
  • Greater ease of comparability between trust frameworks;
  • Greater potential for reusability of trust framework components;

And, most importantly:

  • Greater potential for entities in the Identity Ecosystem to participate in multiple trust frameworks with incremental effort and cost that is well-scoped and well-understood.

In a world of modular, reusable trust components, the components themselves are called trustmarks. The figure below depicts in principle how these trustmarks could be used to replicate the existing trust and interoperability requirements of today’s monolithic trust frameworks, thereby unlocking the potential for realizing the benefits listed above. Please note that the specific trustmarks identified in the diagram below are for illustration purposes only, and are not necessarily intended to represent actual trustmarks.

Trust Frameworks Based on Modular Trust Components, or “Trustmarks”

Some Example Trustmarks

The trustmark concept is generally applicable to any well-scoped set of trust or interoperability criteria that have meaning to one or more COIs. As indicated in the diagram below, trustmarks can be defined for a wide variety of trust and interoperability concerns, including:

Note that trustmarks can also address legal aspects of trust and interoperability. The legal aspects of trustmarks are conveyed not through the trustmarks themselves, but via the trustmark policies and/or trustmark agreements under which trustmarks are issued and used.

The next section illustrates how trustmarks can be used to represent some of today’s monolithic trust frameworks in a more componentized manner that can facilitate trustmark reuse.

Componentized Trust Framework Example: NIEF

As noted above, each trustmark captures a specific set of requirements related to trust and interoperability. It is therefore possible, given the right set of trustmarks, to capture the full set of trust and interoperability requirements for any monolithic trust framework. For example, the diagram below illustrates how the NIEF trust framework looks when broken down into reusable chunks of requirements that could be represented as a set of trustmarks.

NIEF Trust Framework ComponentsNIEF Trust Framework Components

At a very high level, the NIEF trust framework contains the following components.

  • A membership lifecycle policy that defines how an agency becomes a member of NIEF, how an agency is removed from NIEF if/when necessary, etc.
  • A bona fides policy that defines what documentation and other artifacts an agency must produce to verify its legitimacy for the benefit of other NIEF members
  • A certificate policy that defines what steps each NIEF member agency must take to adequately protect the private key material it uses to sign sensitive messages, such as SAML assertions, upon which other member agencies rely
  • An audit policy that defines the level of rigor an auditor must follow when assessing a prospective or current NIEF member with respect to NIEF’s other policies
  • An end-user privacy policy that defines the privacy rules each NIEF member agency must respect
  • A COI-specific attribute vocabulary that defines the syntax and semantics of various terms that NIEF IDPs can assert as user attributes and NIEF SPs can accept as inputs into their access control policies
  • A technical and cryptographic trust specification that defines NIEF’s rules for distributing and using its cryptographic trust fabric, which is the authoritative source of public key material and other relevant information about each NIEF member agency
  • A set of technical interoperability specifications that define NIEF’s rules for electronic communications between member agencies using standard protocols such as SAML, SOAP Web Services, etc.
  • A legal agreement that defines the legal roles and responsibilities of NIEF and its member agencies

Note that these components of the NIEF trust framework may not necessarily map directly into trustmarks. This analysis is merely intended to illustrate how a typical monolithic trust framework can be componentized.

Potential Cost Savings Due To Componentized Trust Frameworks

The previous section described how a trust framework (NIEF) can be componentized into small chunks of trust and interoperability requirements, or trustmarks, that have the potential for reuse. But is the reuse of trustmarks a worthy goal? Why bother with it in the first place? To help justify the concepts of trustmarks and trust framework componentization, it is important to consider the cost implications of componentized trust frameworks versus monolithic trust frameworks as the Identity Ecosystem grows in size and scope. The diagram below is a notional depiction of three different cost growth curves for an agency in the Identity Ecosystem, based on three different starting assumptions about how it establishes trust with other agencies. Note that this diagram represents the results of a theoretical cost analysis exercise. While we believe the actual cost curves are likely to resemble these notional curves, we do not yet have the necessary data to confirm or refute this assertion. Our analysis and justification for each line in the diagram appears below the diagram.

Potential Cost Savings from a Trustmark FrameworkPotential Cost Savings from a Trustmark Framework

The blue curve represents the growth of costs when establishing trust through a series of pairwise (bilateral) trust relationships. This curve is linear, because on average, each new pairwise relationship established requires roughly the same amount of time and effort as was required for each previously established relationship. This curve represents a worst-case scenario, and is an unacceptable strategy for any agency that wishes to establish more than a trivial number of trust relationships with other agencies.

The red curve represents the growth of costs when establishing trust through a series of traditional trust frameworks. As we have discussed above, it is unrealistic for an agency in the Identity Ecosystem to assume that a single monolithic framework will be able to meet its needs over time, across each COI in which the agency needs to do business. Therefore, going the route of monolithic trust frameworks tends to imply joining multiple monolithic trust frameworks over time. The strategy of joining multiple monolithic trust frameworks to connect to multiple COIs does not scale as poorly as the bilateral trust strategy discussed above; however, it is still suboptimal. Since each new monolithic trust framework is opaque, it is unlikely that a significant amount of the prior work, which was performed during the process of joining previous monolithic trust frameworks, will be applicable when joining the next monolithic trust framework.

The green curve represents the growth of costs when establishing trust through a componentized trustmark framework in which individual trust components tend to be reused between trust frameworks. In this scenario, joining a new trust framework requires three steps.

  1. Determining which trustmarks are required by the new framework
  2. Determining which required trustmarks are already possessed, and which need to be acquired
  3. Acquiring the necessary trustmarks that are not already possessed

Over time, as the agency seeks to join multiple componentized trust frameworks, it is increasingly likely to already possess many or most (or all) of the necessary trustmarks based on its previous efforts to join other trust frameworks. This causes the cost growth curve to become flat, or nearly flat, over time.

This analysis illustrates one of the most important benefits of trustmarks: not only do trustmarks enable componentization and reuse of trust and interoperability criteria, but they also carry the potential for significant cost savings over time as the Identity Ecosystem grows to encompass many COIs that engage in a variety of cross-COI collaboration scenarios.

For a more detailed discussion of the trustmark framework, please see the Technical Framework page.