Last September, NIST awarded grants to five organizations to stand up NSTIC pilots focused on advancing the NSTIC vision, objectives and guiding principles, demonstrating innovative frameworks that can provide a foundation for the Identity Ecosystem, and tackling barriers that have, to date, impeded the Identity Ecosystem from being fully realized.
Six months into the implementation of the pilots, they are all making great progress – as will be evidenced when they make a formal presentation to the Identity Ecosystem Steering Group (IDESG) plenary next month. Progress not only in advancing the Identity Ecosystem – but also in raising questions that must be addressed for the Ecosystem to be fully realized.
In advance of the IDESG plenary, we’re launching a series of blog posts that focus on some of the common questions that have emerged as the pilots have moved forward. Given that NSTIC relies on a multi-stakeholder collaborative process to advance the Identity Ecosystem, our hope is that these blogs on pilot “Common Considerations” will kick off discussion and collaboration on these questions.
This blog sets the scene by laying out the terminology that will be used throughout this series. To be clear, the terminology we propose here may differ from what the IDESG decides to use – this is simply a way to level set terms for these blogs. As with all the blogs in this series, we hope and anticipate that the material will be further refined by the work efforts of the IDESG, including the pilot recipients - all of whom are active IDESG members.
An organization (Service Provider
) wishes to provide a commercial service (in the private sector), or is mandated to support a government entitlement (in the public sector). The organization has completed a risk analysis of the consequences of providing the service or entitlement to an incorrect person, and has thereby established the degree of confidence that they require in the consumer or citizen (more generally termed as an individual
)’s identity. The individual’s uniqueness (identity
) is defined by biographical information (such as name, date of birth, passport number, etc.) and biological attributes. The individual’s identity can be confirmed by an Identity Provider
, or, alternatively, an Attribute Verifier
may corroborate certain aspects of an individual’s identity. The organization relies on this identity validation to ensure that the individual is who they claim to be: as such, they are termed a Relying Party
Eligibility for the requested service or entitlement is typically determined by the organization based on some aspects of the individual: i.e. has good credit rating; is of a particular age; or is eligible for a social service, etc. Note that the eligibility testing that an organization fulfills may be derived from information relating to the individual’s identity (i.e. over a certain age), or not (i.e. a particular entitlement may be based on the status of an individual, such as being unemployed). In either event, determination of the eligibility (authorization
) is independent of validation of identity.
In some instances, there is an operational layer between the Identity Providers, Attribute Providers and Relying Parties in an identity ecosystem, such an operational layer may be known as an Intermediary
. The Intermediary may be a passive pass-through transactional layer, or it may have logic to process transactions in accordance with policy.
The Relying Party may be operating as a stand-alone entity, or it may be operating in a consortium of similarly-interested parties (Community of Interest
), or as a member of a more formal alliance with other organizations (under a Trust Framework Provider
). The Community of Interest operators or the Trust Framework Provider prescribes the operating principles or “rules of engagement” of various actors in the system, such as operating policies, and means of technical interoperability, etc. The rules of engagement for the Community of Interest or Trust Framework may also include a contractual framework for items such as: remedy of a breach; system protection via security safeguards; or compliance with privacy principles (such as the Fair Information Privacy Principles
). Any Community of Interest or Trust Framework contracts that are in place are in addition to prevailing legal or regulatory requirements.
The required degree of confidence in the individual’s identity by the Relying Party is based on their risk analysis and business practices: or it may be pre-determined by a regulatory environment, for government, healthcare, financial, or other industries.
The degree of confidence in the individual’s identity is often termed as the required “Level of Assurance
”, although this term evolved out of specific federal risk assessment practices. The level of assurance defines the level of confidence in identity required
by the Relying Party. It is also used to express the level of confidence provided
by Identity Providers, Attribute Providers, or by an Intermediary (by combining inputs from Identity and Attribute Providers).
The ability for an individual to assert a claim of identity in support of a transaction depends on: the underlying confidence that a set of attributes ties them to their actual identity (identity Proofing
), and the level of confidence that the individual is actually that person at the time of transaction (authentication
). Two additional considerations relating to the strength of the system are the data transport mechanisms used to convey identity information, and the strength of binding of identity proofing and authentication.
Once enrolled with a service provider the individual is typically assigned a user-name, or other identifier, by which they are known to the service provider. The user-name is usually linked to the individual in a logical or physical credential
– which may be a physical credential or a logical credential. The process of issuing, maintaining, and authenticating a credential is fulfilled by a credential manager
Certification schemes to date have been based on accreditation of credential service providers
– which comprise identity providers and credential managers. In response to commercial activities, there have been some recent activities to separate the components of identity provider and credential manager.
Certification of components in identity ecosystems is a critical step that enables Relying Parties to have an adequate degree of confidence to outsource this functionality to third parties.
to leave this site and visit the IDESG's discussion forum on this topic.