Establishing Trust in the NSTIC

The National Strategy for Trusted Identities in Cyberspace (NSTIC) proposes a large ecosystem of identity providers, attribute providers, and relying parties that must establish trust with each other in various ways. NSTIC requires various types of trust within the identity ecosystem. These include:

Users must trust that their Identity Provider will manage their credentials securely and in their best interest.

Relying Parties must trust in the attributes provided by Attribute Providers.

Attribute Providers must trust Identity Providers and Relying Parties to handle attributes, which may include proprietary data such as credit scores, in accordance with their terms of use.

Relying Parties must trust Identity Providers to provide the requested strength of authentication and to manage credentials and attributes correctly.

The term “federated identity” is widely used to refer to identity systems that span multiple organizations, each of which maintains its own identity information. That arrangement is typically used between an enterprise and its business partners, such as contract manufacturers, channel partners, and consulting firms. Trust is established individually with each. A fully meshed federation of n participants would require n(n-1) such agreements, which does not scale well beyond small federations, especially considering that these agreements often take the form of contractual negotiation between each party.

The anticipated scale of NSTIC makes this form of federation wildly impractical. This is where the accreditation model proposed in the NSTIC has a real advantage. To differentiate it from the pairwise-federation model, I often refer to the model used by the NSTIC as accredited identity. These are also sometimes referred to as trust frameworks.

One of the biggest problems with accreditation historically has been communicating clearly the meaning (semantics) of the accreditation. In the context of the NSTIC, the semantics of accreditations should include:

For Identity Providers:

The maximum level of assurance that the Identity Provider’s credential management procedures and authentication mechanisms are sufficient to support.

For Attribute Providers:

The maximum level of assurance of the Attribute Provider.

The domain of the attributes that are accredited, e.g., health care, financial, or employment.

For Relying Parties:

Identification of the Relying Party.

Agreement that the Relying Party agrees to abide by terms of use in the information received.

For Accreditors:

The maximum level of assurance of the Accreditee.

The type(s) of entities that can be accredited, and in the case of Attribute Provider accreditors, the attributes that can be accredited.

Whether lower-level accreditors can be accredited.

All this granularity is intended to make it easier for parties to participate in the Identity Ecosystem. If they are only going to support low levels of assurance, it should not be necessary to bear the burden and cost of being accredited at the highest possible level. Similarly, it is easier to accredit an attribute provider to be a trustable source of certain types of information than it is for all possible assertions.

Another important requirement that is all too often overlooked is the ability to revoke the accreditation of both accreditors and other Identity Ecosystem participants. Without the ability for revocation to be revoked, it means little. Revocation needs to be possible on both a technical and practical basis. From a technical standpoint, it needs to be possible to quickly communicate the revocation to those that are dependent on the accreditation, or for the accreditation to be evaluated in real time. From a practical standpoint, it needs to be possible to revoke an accreditation without causing an excessive amount of collateral damage; no accreditation can be allowed to become so important that it is “too big to fail.” This means that the structure of accreditations isn’t a tree, but a bunch of trees with intertwined branches, as participants are likely to have several accreditations that are applicable for different purposes, to increase their breadth of trust, and as backups.

While the trust framework for the NSTIC Identity Ecosystem is critical to its success, it will take considerable care and attention to build it properly.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.