NSTIC Pilot Common Considerations: 2 – Trust Frameworks

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.  Trust Frameworks and Communities of Interest The two related Common Considerations discussed in this blog are: 1.      Pilot programs have made clear that there is a lack of a documented method, similar to service level agreements, for all identity ecosystem participants, including Relying Parties, Attribute Providers, and Identity Providers, to interact and identify the components and outcomes of their interactions, such as duration of interaction, responsibilities, description of services, deliverables, etc. 2.      There is also a lack of sector-specific identity frameworks for applications such as healthcare and financial.   The generic identity frameworks need to be examined in light of sector-specific regulations or interpretations, to define sector-specific “profiles” that provide guidance in such industries. Trust Frameworks have evolved to govern the interaction of service components in an identity ecosystem.   To that end, Trust Frameworks typically encompass the following aspects (to a lesser or greater extent): Legal Agreements including clauses for enforcement and remedies, Operating Policies, Security Safeguards, Privacy Safeguards, Governance Structure, Service Component definition, risk assessment guidance, and authentication methods. Historically, Trust Frameworks were defined around identity service providers, and the “rule set” was defined for a particular context, such as federal applications   However, as identity systems continue to mature, we are seeing several forces inside and outside the pilots that are driving further evolution of Trust Frameworks.   

• The definition of actors within an identity ecosystem is being refined, in alignment with commercial specialization and architectural requirements.  For example, the “full -service” functionality of a credential service provider is now capable of being provided by separate service components of identity proofing and user authentication.  
• Attribute Providers/Verifiers are being used more in identity systems to satisfy claims verification.  
• Intermediary components between Relying Parties, Identity Providers, and Attribute Providers are being deployed in some identity systems.  
• There is growing discussion regarding the role of Relying Parties within trust frameworks.
• The rules of Trust Frameworks are expanding, for example to include further clarification around compliance with privacy principles.
• Sectors such as healthcare, financial, education, aerospace and defense, and pharmaceutical are formulating their requirements for Trust Frameworks, including risk assessment and desired levels of identity assurance

These forces are not always independent.   For example, there are areas where groups of similarly-interested customers are getting together to form “Community of Interest” Trust Frameworks.   In this case, the rules of operation for the Trust Framework are established by those Relying Parties and so they are implicitly included. In other cases, some of the rules of the Trust Framework are imposed by industry regulations, in sectors such as healthcare, education, or financial. Lastly, an important part of Trust Frameworks is their ability to support an auditable process that can yield certified credentials.   This is a critical piece of the identity ecosystem puzzle as it enables Relying Parties to have an adequate degree of confidence to outsource this functionality to third parties. So, as new Relying Parties come to the table and decide which Trust Frameworks to use, it is clear that a number of choices and models are available.   We suggest that the IDESG would do well to actively work with existing and emerging Trust Framework Providers to drive towards as much commonality as possible, while ensuring that the NSTIC guiding principles are maintained.   There are many aspects of potential interoperability between Trust Frameworks that can be considered and, while it is inevitable that sectorial requirements will cause some diversions, it would be ideal to drive towards as much commonality as possible to maximize interoperability.   The following are some aspects of potential interoperability (whether through direct technical interoperability, translations, or mutual recognition) across Trust Frameworks:

• Technical interoperability/Data conversions,
• Alignment/Recognition of Policies,
• Cross jurisdictional data interoperability,
• Service Component Definition,
• Alignment with Standards Development Organizations,
• Risk assessment and Authentication strength,
• Credential certification

We suggest that policy interoperability is just as important as technical interoperability.  We   hope that this blog post will tee up a discussion of these different aspects of interoperability within the IDESG, and hope that the IDESG will look to collaborate with the pilots in attempting to overcome these aspects of Common Considerations.   Initial questions we’d like to see all stakeholders contemplate include:  1)      How generic can Trust Framework “rules of the road” be?   How should requirements of sector-specific implementations be captured? 2)      Should the IDESG establish a mechanism to ensure that the NSTIC Guiding Principles are embedded in evolving Trust Frameworks? 3)      Which factors of Trust Framework interoperability does the IDESG see as the most critical?  Technical interoperability, policy interoperability, legal compatibility? 4)      Should the IDESG work with Trust Framework Providers to try and harmonize rules of the road so that some degree of “mutual recognition” between Frameworks can be attained? 5)      In which IDESG Committees should risk assessment be discussed?   Security, Standards, Sector-Specific Committees? 6)      Can the wide range of emerging authentication types be “categorized” to meet specified risk-mitigation requirements? Click here to leave this blog and view and participate in the IDESG's discussion forum about this topic.