The NSTIC pilot identity solutions to be evaluated will be awarded through FFO 2013-NIST-NSTIC-02, NSTIC Pilots: Trusted Online Credentials for Accessing Government Services Cooperative Agreement Program. The funding for these pilots and their evaluation is provided by the Partnership Fund for Program Integrity Innovation.  Proposals for this opportunity were submitted May 16, and are currently undergoing evaluation. 

With this new FFO, the Federal government is seeking an entity to perform an evaluation of these state-focused pilots, looking at their benefits to the government entities involved, as well as to the users of those government services.  By advancing the knowledge gained from the pilot projects and disseminating it broadly to policymakers, state agencies, and the public, the evaluation will assist in moving forward the objectives of both the NSTIC, as well as the Partnership Fund.

The two-day meeting opened with remarks from the newly elected leadership team and a presentation on a formal work plan for the IDESG to guide its work in establishing the rules, policies, and standards that will constitute the identity Ecosystem Framework.  Importantly, the work plan asked: “What must the IDESG accomplish in 2013?”

Paul Laurent of Oracle led an exercise that identified five key, short-term objectives to drive activity in 2013:

• Establish and Implement an IDESG Self-Sustainment Plan
• Establish and Implement an IDESG Accreditation and Trustmark Program
• Implement IDESG Accreditation Program for at least 2 NSTIC Pilots
• Establish Defined Liaison Relationships
• Establish and Implement the Identity Ecosystem Framework Development and Adoption Process

The NPO agrees that focusing on these core objectives in 2013 will constitute major progress toward establishing the Identity Ecosystem, as well as  demonstrating the value of the IDESG. 

A use case workshop led by Cathy Tilton of Daon helped to further focus the work by providing important context for the development of IDESG components such as standards and best practices.  The Plenary is expected to further focus and refine actionable use cases in the near future.   

Presentations from the NSTIC pilots only increased the sense of impending emergence – in some cases, actually taking flight very soon in important segments.  Pilots presented on details of their real world progress to date and on important lessons learned.  For the pilot presentations materials, please click here and scroll down the agenda to select a presentation. 

If there is one lesson to be learned from these pilots, it is that their collective experience only underscores the need for a robust Identity Ecosystem Framework.  It’s been remarkable that as the five pilots, all different, have collectively progressed, they also all have dealt with struggles because of the lack of such a Framework – forcing their participants to sort out a number of thorny technical and policy issues on an ad-hoc basis. 

In the days and weeks leading up to Santa Clara, we posted a series of blogs about these issues, which we dubbed “Common Considerations.” The pilots discussion at the plenary provided an excellent place to air these issues, and reinforced the need for an Identity Ecosystem Framework that can help the pilots and other fledgling efforts in the Identity Ecosystem to become truly scalable. 

Day two of the Plenary started with Kim Little of LexisNexis presenting on a proposed business plan, laying out options for a path to sustainability as the IDESG in 2014 transitions operations from a NIST-funded entity to a truly independent and self-financing organization.  Plenary participants then broke out in Committee meetings to continue crafting Identity Ecosystem Framework components, before rejoining in a closing session of the entire Plenary. 

Between concrete work plans, tangible evidence of the Identity Ecosystem emerging in NSTIC pilots, and with a vision for long-term continued success, the Santa Clara Plenary left participants with the clear sense that the patient start-up work of 2012 is now beginning to yield tangible results for the organizations and individuals engaged.

We appreciate your feedback, and continued participation.  The next in-person meeting of the IDESG is set for July 24-26 in Cambridge, Massachusetts, hosted by MIT.

 *Yes, our mind is on the impending cicada invasion here in Washington.

We have encountered the following three related Common Considerations around attributes:

1. Existing trust frameworks do not adequately consider or incorporate attribute providers/verifiers.
2. There are some instances where a party requesting attribute provision/verification does not require all of the information provided by an attribute provider/verifier – but the requesting party has no way to request or receive less.  This has presented challenges as pilot participants work to adhere to the NSTIC’s guiding principle on privacy, which emphasizes the importance of data minimization.  Pilots instead are encountering an ecosystem which seems to encourage what we’ve dubbed “data promiscuity” – where attribute providers/verifiers overshare as a default. 
3. In attribute based systems, there is often not a clear “flow-down” of consent requirements to end-users, or a standardized mechanism to accommodate redress of user data.

The identity functions of proofing and authentication have been historically carried out sequentially in a single enterprise, as part of series of steps (see, for example, NIST SP 800-63).   However, the relative timing of identity proofing (binding to an individual) and authentication (establishing confidence that a user making a valid claim) is evolving in response to relying party needs.   For example, in some cases, a relying party may seek only to re-affirm the validity of a user based on a sub-set of the full set of attributes required to uniquely identify them.   The sub-set chosen will depend on the transactional type and risk and may provide sufficient authentication that the user is who they claim to be, without incurring the cost of the complete attribute set query (cost here can mean both the financial cost, and the “privacy cost” in terms of superfluous personal information distribution).   The use of supplementary attributes may also be used in cases where credentials have been corrupted and a bypass operation is required, or when a critical emergency situation has arisen.   In other cases, attributes may augment the degree of confidence required in an authentication transaction, by temporarily “strengthening” an existing credential, to facilitate the authorization of a “higher-risk” transaction.

Thus, relying parties’ demand for different combinations of attributes is increasing, some of which may be supplied by the traditional identity provider, but some of which may need to be sourced from specialized and authoritative sources. In either case, attributes are typically managed in one of two ways: attribute provision or attribute verification. Attribute provision is the case where a certain set of attributes is requested and received by a party, and the requesting/receiving party applies logic to determine the validity of a user’s claim.   On the other hand, attribute verification is simply a yes/no confirmation that a submitted set of attributes is valid.   As attribute verification is typically based on a user-driven assertion of attributes, there may be more transparency built into this system, addressing some of the privacy concerns, however, as discussed later, actual implementations usually require closer examination to ensure that user oversight flows with the data.   Note that the verification of an attribute set establishes that it is a valid set, but does not necessarily link them to an individual.   To do so, some form of knowledge-based or in-person confirmation is required at some point in the identity process.

As stated above, attribute management has traditionally been encapsulated within the functions of identity proofing or authentication and was not exposed an “API level”.   As the operations of attribute provider and verifier move to the level of API exposure, we believe that it is critical that guidance be given regarding the incorporation of attribute services in identity architectures, to ensure that appropriate security and privacy safeguards are in place.   To date, existing Trust Framework Providers, such as Kantara and OIX have not yet formally incorporated attribute management in their architectures – although both these examples have active working groups in this domain, such as Kantara’s Attributes in Motion Working Group and OIX’s Online Attribute Exchange Trust Framework Working Group.   Some of the questions that these groups are asking include:

• How can various attributes be combined in a quantitative way?
• What pre-requisites are required for an attribute source to be authoritative?   How can this be quantified?
• How much more confidence should there be in receiving information from an organization that included an in-person step in its credential issuance versus a completely online process?
• If there are three independent sources for an attribute, does that necessarily make it more authoritative?   How much more?
• How should the “freshness” of attribute be characterized?

We believe that the IDESG should also be contemplating such questions, to ensure that the NSTIC Guiding Principles are upheld as the use of attributes within identity ecosystems continues to develop.

As a couple of indicators of interest in the IDESG on these topics, we note that the Security Committee has a work item on Attribute Assurance and Confidence Levels, which would “provide guidance on the types and quality of attributes used for authentication/re-authentication, and to securely and efficiently access and share information.”   In addition, there has recently been significant discussion at the joint Security and Standards Committee meetings on the definition of attribute and related terms such as identity and authentication.

Another fundamental consideration regarding the use of attributes in identity systems is that there is sometimes a disparity between a relying party’s attribute requirements and the sets of attributes that a service provides.      In a blog at IDManagement.gov, the concept of determining the “minimal set of attributes (attribute bundles) needed to uniquely identify a person” in order to map them to a user account in a particular context is discussed.   Of course, different contexts may require different attribute bundles and this may lead to a relying party (or intermediary) receiving more personal information than they requested or need, if there is a disparity between the requested attribute bundle and the attribute sets supported by an attribute provider.   In this case, the challenge becomes how to operationally deal with the varying bundles of personal data without losing alignment with the Fair Information Practice Principles (FIPPs).   In particular, the NSTIC calls for organizations to “only collect PII that is directly relevant and necessary to accomplish the specified purpose(s) and only retain PII for as long as is necessary to fulfill the specified purpose(s),” as well as to use claims for authorization that can avoid collection of specific attributes when possible (e.g. an individual is over 18 rather than the actual birth date).   Attention to this principle will likely require some iterative changes in the commercial practices of attribute providers and other identity ecosystem participants.

Along with the flexibility of finer grain control of attributes, there is an attendant requirement to understand the implications of continued alignment with the FIPP’s, particularly in regards to consent and redress.   One of the challenges of attribute management is establishing a flow-down of consent throughout the attribute handling process, as well as maintaining traceability to facilitate redress, in the event that a user needs to challenge the attribute provider/verifier’s response.

One idea of establishing traceability with regards to user consent and redress regarding attributes was discussed at the FTC roundtable privacy events in 2009/2010: the potential “lifecycle tagging” of personally identifiable information or attributes so that their history can be traced.   This would allow characteristics such as “strength”, source, and freshness to be identified, as well as offer the user the ability for redress with the attribute source.

We hope that this blog post will catalyze further discussion around these topics within the IDESG, and that the IDESG will look to define recommendations to attempt to overcome these challenges.  Initial questions that we’d offer to stakeholders include: 

1)      Should the certification of attribute providers/verifiers be included in any future IDESG accreditation program?

2)      Can confidence levels be assigned to individual attributes?   How are authoritative sources determined?

3)      How and where is individual consent obtained and maintained in a system that relies upon a series of attribute steps?   How is it ensured that an individual is notified if an error occurs?   Is there a security risk (i.e. possible gaming) to the individual being notified that a claim was rejected?   How should an individual seek redress if he/she suspects that data are corrupted?

4)      Are there methods of “tagging” attributes (a.k.a. attributes of attributes) that can be considered?

5)      Should the IDESG Privacy Committee develop best practices for attribute management, to encourage continuous alignment with FIPPs – and reduce “data promiscuity”?

The IDESG established a forum for further discussion regarding these and other related topics here: https://www.idecosystem.org/content/attributes

This blog is the third in a series that focuses 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. 

The two related Common Considerations discussed in this blog are:

1. There is a lack of standards regarding Relying Party’s (RP’s) risk assessment processes and thereby the required strength of identity needed for a transaction.   Current material relies heavily on OMB 04-04 and NIST SP 800-63, which is only directly applicable to U.S. Federal government use cases – it is not clear how the material in these reference documents should be extended to non-federal use cases.
2. Once an RP has stated the required assurance strength, there needs to be a method to quantify the confidence in an asserted identity, both in terms of identity proofing and identity authentication.   A model needs to be created to objectively state the confidence in asserted attributes, and the confidence in an authentication mode, such as tokens, passwords, biometric technologies, etc.   It would be helpful to compare these methods with the authentication tables in NIST SP 800-63.

As noted in the Terminology blog of this series, the required degree of confidence in an individual’s identity by a Relying Party is based on their risk analysis and business practices; alternatively, it may be pre-determined by a regulatory environment (for government, healthcare, financial, or other industries).   It was also discussed in the Trust Frameworks blog that Communities of Interest are forming with collective viewpoints on operating principles, including risk assessment schemes.   This blog explores some emerging themes around risk assessment and authentication strength.  

The degree of confidence in the individual’s identity is often expressed 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).   Thus, the success of identity ecosystems is based on parity between the expressed requirements of Relying Parties (RP’s) and the asserted or proven capabilities of Identity/Attribute Providers (IP/AP’s).   As mentioned above, to date, such RP requirements have largely been expressed based on federal documents such as OMB-04-04 and NIST SP 800-63, and IP/AP capabilities have been accredited under the auspices of the corresponding program: the FICAM Trust Framework Provider Adoption Process.   We believe that a broader ability to achieve demonstrable parity across the various actors in commercial identity ecosystems, and in the context of a range of industry sectors, is critical to the future success of identity ecosystems.   We anticipate that the IDESG will create a voluntary, consensus framework for accrediting a wide range of identity ecosystem components for commercial and federal industry sectors, incorporating existing material where possible, but also leveraging the fact that it is not constrained by a particular marketplace.   To explore this topic further, we think that it is beneficial to look at both sides of this equation.

Risk Assessment

As the number of industry sectors that depend on identity services increases, it is imperative that some degree of common understanding regarding risk assessment evolves; otherwise a fundamental component of interoperability across operators is missing.   If relying parties and other operators assess identity risks in different ways: they are unable to articulate their requirements using a common lexicon; deployments end up being done in an ad hoc manner; and relying parties ultimately have to make decisions about how to combine identity attributes to mitigate their risks.   This places more of an onus on relying parties than is necessary – leading to higher integration costs and potential liability, which will inhibit the uptake of identity solutions and overall success of the ecosystem.  

Further, a lack of a coherent and mutually-recognizable risk assessment methodology will likely limit the adoption of identity solutions by new industry segments.   For example, the recently-issued Executive Order and associated Presidential Policy Directive-21 mandates the development of a Cybersecurity Framework for use by commercial and federal critical infrastructure operators.   Unless a clear and concise methodology is available to determine risk and potential consequences of identity breaches, new sectors may be apprehensive about incorporating identity technologies, which are essential to underpin any cybersecurity strategy.

There is no doubt that different industry segments have different ways of assessing risk, and that risk related to identity needs to sit alongside other risk factors.   There is also no doubt that having finer granularity in the required identity assurance than the “standard” four levels provides more implementation flexibility, but it also inhibits interoperability in terms of Identity/Attribute Providers’ ability to provide pre-packaged solutions across a wide range of Relying Parties.

As more and more industry sectors such as healthcare, financial, education, aerospace and defense, and pharmaceutical, integrate identity technologies, we think that it would be insightful for the IDESG to continue solicitation of discussions with representatives from each of the sectors with a view to harmonize as best possible the various methodologies used to assess identity risk.

Authentication Strength

In terms of mitigating identity risk, there are an increasing number of available authentication methods, as well as ways and means of combining them.   For example, a growing number of authentication technologies are being made available on mobile phones, so a combination of: device possession, location, out of band communications and biometric technologies can be used in a particular scheme.   Recall that 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).   The capabilities of identity proofing and authentication have historically been provided by a single entity.   However, there are an increasing number of architectural models and commercial forces that are driving more towards a componentized model.   As this occurs, the binding mechanism between identity proofing and authentication becomes ever more important.   The binding mechanism needs to be acceptable at the point of transaction, so that the relying party has sufficient confidence that they are providing service to the appropriate individual.   The mechanism and type of binding used to create a credential will also affect the potential interoperability, or recognition, of the credential by other subsequent relying parties.

Standardization efforts in identity proofing are ongoing, for example, NASPO continues its work towards an ANSI standard on “Minimum Standards for Proof and Verification of Personal Identity”, and the ISO efforts in ISO/IEC SC27 WG5, recently led to the production of a first draft of ISO 29003: “Identity Proofing”.   The ICAO New Technologies Working Group has also previously done work on “Evidence of Identity”.   The other two aspects of a transactional authentication: that of the authentication mode and the binding between proofing and authentication still requires further development.

Most of the authentication work today tends to migrate towards equivalence with NIST 800-63-1, specifically with Table 7.   However, as they types of authentication methodologies increases, as does the range of platforms on which they are used, it would be beneficial to measure and catalog the various technologies used and provide recommendations for how they can be combined to support strengthened identity authentication.   We see this as an extension of the previous work in SP 800-63-1, and something that is required as identity authentication is used increasingly in commercial applications.   Providing a well-characterized set of authentication methods and platforms will provide more assured guidance for relying parties, thus improving the uptake of identity solutions.

The last major piece of the authentication puzzle as we see it is the binding between identity proofing and authentication components.   As mentioned previously, these capabilities were historically undertaken by a single entity.   However, the flexibility of systems is driving more towards separated components that can be supported in various parts of the ecosystem.   For example, a relying party may generally use external authentication methods, but for some transactions, is required to increase the level of confidence that they have in an individual through the use of compensating factors (either on a transactional basis, or on a more permanent basis as contemplated by the OASIS Technical Committee on Trust Elevation).   This can easily be achieved in a well-characterized system by the relying party invoking some additional identity provider/attribute providers for the transaction.   So far, the concepts relating to the binding of identity components have been discussed and developed in the Kantara Initaitive, and observed by our GSA colleague Anil John in his series of blogs.  

We believe that it would be instructive for the IDESG to consider the emerging range of authentication technologies and how they can be combined to provide an overall transactional strength of identity assurance.

We hope that this blog post will catalyze further discussion around these topics within the IDESG, and that the IDESG will look to define recommendations to attempt to overcome these challenges…   Initial questions that we’d offer to stakeholders include: 

1)      How much should the IDESG facilitate sector-specific identity risk assessment discussions?   Would the IDESG consider hosting sector-specific roundtables?

2)      In which IDESG Committees should risk assessment be discussed?   Security, Standards, Sector-Specific Committees?

3)      How granular should the levels be within identity risk assessment methodologies?   Four levels?  More?

4)      Can the wide range of emerging authentication types be “cataloged” to meet specified risk-mitigation requirements?

5)      What accreditation schemes are emerging to assess authentication strengths of particular modalities and on specific platforms?

6)      How does the IDESG ensure that accreditation schemes are aligned with international efforts, such as those in ISO/IEC SC’s 27 and 37?

7)      Should levels of assurance be mapped similarly to 800-63, or is another scheme desirable?

The IDESG established a forum for further discussion regarding these and other related topics at the following location:

https://www.idecosystem.org/content/risk-assessment-methodologies-and-authentication-strength

The release of the National Strategy for Trusted Identities in Cyberspace (NSTIC) by the White House in April 2011 put forth a monumental challenge: a call for a new private-public sector partnership to create an Identity Ecosystem, where all consumers could choose from a variety of credentials that would enable more secure, convenient and privacy-enhancing transactions everyplace they go online.  

Monday marked the two year anniversary of the NSTIC release, and we gathered at the National Cybersecurity Center of Excellence (NCCoE) in Maryland – as part of a broader event – to brief U.S. Senator Barbara Mikulski, NSA Director General Keith Alexander, Maryland Governor Martin O’Malley and others about the progress NSTIC has made toward catalyzing a marketplace for trusted identity solutions. 

This progress is due in no small part to the commitment and invaluable contributions of a broad range of stakeholders who have risen to meet the President’s challenge. Today, thanks to these partners, we can point to a number of milestones including: 

• The creation of the Identity Ecosystem Steering Group (IDESG): The IDESG, created to administer the development of policy, standards, and accreditation processes for the Identity Ecosystem Framework, held its first meeting this past August.  Since then, the group has formalized a governance structure, elected officers, and launched a variety of committees that are currently driving the creation of different elements for the Framework.  Today, the IDESG has  nearly 200 organizations as members and more than 400 participating individuals.
• The award of five pilot projects:  On Sept. 20, 2012, NIST awarded more than $9 million across five organizations to fund NSTIC pilots – demonstrating new identity solutions that increase confidence in online transactions, prevent identity theft, and give individuals more control over how they share their personal information.   These pilots are all well underway, with a steady stream of milestones expected over the rest of the year as they each hit “go live” milestones.  The pilots are collectively rolling out new trusted identity solutions across health care, e-Commerce, online banking and brokerages, industry associations, universities, state and Federal government, and organizations serving seniors.  As we look to catalyze a marketplace of private-sector credentials providers, the NSTIC pilots are helping to address the “chicken and egg” problem that has vexed previous identity initiatives and are demonstrating the viability of trusted identity solutions across multiple sectors. 
• NIST released a FFO to award a second round of NSTIC pilot grants this past January, and last week selected 13 finalists to submit full proposals for these grants; we expect awards to come in September. 
• The launch of a new, state-focused NSTIC pilot program:  with funds provided by the Partnership Fund for Program Integrity Innovation, the NPO just launched a new NSTIC pilot opportunity focused on helping state governments pilot on-line identity solutions for accessing government services that embrace and advance the NSTIC vision.  Proposals are due May 16, 2013. 
• Facilitating the Federal government’s role as an early adopter of the Identity Ecosystem:  by working with agencies to help them align with NSTIC, and by partnering with the United States Postal Service and General Services Administration to create a Federal Cloud Credential Exchange (FCCX) solution that simplifies the technical integration process for accepting accredited externally-issued digital credentials. 

Together, these initiatives are helping to influence the marketplace, address barriers to marketplace adoption, and create a framework to support a viable Identity Ecosystem. 

The potential of the Identity Ecosystem has always been exciting; indeed, nobody captured it better than President Obama in his introductory letter in the NSTIC, when he said: 

“The simple fact is, we cannot know what companies have not been launched, what products or services have not been developed, or what innovations are held back by the inadequacy of tools, like secure passwords, long ago overwhelmed by the fantastic and unpredictable growth of the Internet. What we do know is this: by making online transactions more trustworthy and enhancing consumers’ privacy, we will prevent costly crime; we will give businesses and consumers new confidence; and we will foster growth and innovation, online and across our economy – in some ways we can predict, and in others ways we can scarcely imagine. Ultimately, that is the goal of this strategy.”  

But as powerful as the ideas in NSTIC are, its realization depends on continued robust public and private sector participation.

For us, this means not slowing down. Going forward, the Federal government will continue to lead as an early adopter of NSTIC-aligned solutions with the rollout of the FCCX and additional grant funding for NSTIC pilot projects this summer.

And with the marketplace responding to problems with passwords, as evidenced by firms like Google, Microsoft, Amazon and Apple starting to offer customers multi-factor authentication, the government will continue working to ensure individuals have choices that are privacy-enhancing, secure, interoperable, cost-effective and easy to use.

For you, this means taking your seat at the table to help achieve shared goals of enhancing online choice, efficiency, security, and privacy.

Without question, the most important forum for stakeholders to convene and collaborate on solutions to enable the Identity Ecosystem is the IDESG. We encourage you to learn more about the organization and register to attend its next meeting, May 9-10 in Santa Clara, Calif. where members will develop a work plan for the summer months, hear from the NSTIC pilot projects and see demonstrations of their progress, and, participate in a workshop to identify a set of use cases of the Identity Ecosystem in use in real world applications.  For more on the IDESG, visit: http://www.idecosystem.org/.

We appreciate the efforts so many of you have made over the last two years; we are truly making progress!  We look forward to working more with you over the months and years to come as we drive material improvements in the way we enable trusted identities in cyberspace.

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.

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.

Terminology

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.

Click here to leave this site and visit the IDESG’s discussion forum on this topic.

Takeshi Okada of Japan’s METI (listening to translation), Jim Sheire of the NSTIC NPO, Colin Wallis of New Zealand, and Stephen Ufford of Trulioo discuss international identity programs at the Japan Identity and Cloud summit March 2013

Since NSTIC’s release nearly two years ago, one of the most frequent questions we get is:  just how seriously should we take the “N” in NSTIC?  Stakeholders both in the U.S. and abroad have asked whether the fact that NSTIC is a “National” strategy somehow implies that the U.S. is trying to create an Identity Ecosystem that stops at our borders.

The “N” may cause some occasional confusion, but the answer is clear:  the NSTIC recognizes that cyberspace is a global community, and that the Identity Ecosystem must be integrated internationally.

The NSTIC, by design, seeks to ensure that emerging identity solutions deployed by the NSTIC pilots, implemented in the Federal Cloud Credential Exchange (FCCX), and developed by the private sector-led Identity Ecosystem Steering Group (IDESG) take into account emerging international standards and approaches – and look to integrate to every extent practicable.  An internationally coordinated architecture can maximize the benefit of the Identity Ecosystem to American individuals and organizations by creating new business opportunities and advancing U.S. goals in international trade, while also increasing trust when global Internet users interact with U.S.-based businesses and other entities and individuals online. 

To help achieve this, the NPO continues to reach out internationally, especially in Europe and Asia.  NPO outreach is intended to inform the global identity management community on the commonalities and differences of the NSTIC’s goals and objectives to other efforts across the world, and to recruit interested entities and individuals to join the IDESG.  The NPO is also engaging foreign governments to provide updates on NSTIC implementation, especially on U.S. government identity initiatives such as the FCCX.  This intergovernmental dialogue serves our common goal of moving government services to the cloud and improving the safety and security of transactions online. 

In the course of this outreach, the NPO has noticed a number of common themes voiced by governments, businesses organizations, and individuals in many parts of the world:

• Identity is key as governments move to the cloud.  Governments globally are looking to move services to the cloud, to improve customer service while reducing costs – but they cannot take advantage of many cloud services without solving the identity conundrum.  Like the U.S. FCCX, the UK Identity Assurance program seeks to enable a trust framework that will allow UK citizens to prove their identity online, leveraging private sector services.
• Digital by default.  At the recent Japan Identity and Cloud Summit, Nat Sakimura, Chairman of the OpenID Foundation, noted that many governments are seeking to go “digital by default” by reducing paperwork and the need for in-person support, which will require strong identity management schemes.  And by “digital,” Nat sees governments offering structured data useful to individuals in innovative new cloud applications and services, not just posting .pdf versions of existing print documents.  Indeed, “digital by default” has become a key principle in the United Kingdom as they look to change the way the government does business with its citizens. 
• The global marketplace.  Businesses operating in multiple geographies strongly prefer harmonization in cloud identity architectures to ensure international interoperability and a seamless experience for their increasingly global customer base.
• Avoiding multiple certifications.  Global businesses are especially concerned that governments may set up different, overlapping certification schemes, requiring multiple, costly, and time-consuming processes.  The private sector is urging governments to explore potential cross-certifications of other countries’ schemes, useful for citizen-to-government, citizen-to-business, and business-to-business applications.
• Leverage international standards.  Both governments and industry are looking to emerging international standards initiatives based on private sector innovation, such as OpenID and OAuth, to ensure maximum interoperability.
• Privacy is key.  Enhancing privacy is a consistent theme globally, and governments especially agree that international identity architectures need to design in privacy from the start – not just in policy, but also in the technologies themselves. 

As governments, businesses, and other entities deploy more solutions and services in the cloud, we expect many of these common themes to help shape the emerging identity ecosystem.  The NSTIC NPO will continue international outreach to ensure that these emerging solutions will address the needs of U.S. entities and individuals while also benefiting those in the global Internet community that share the NSTIC vision and guiding principles.  If you have recommendations for our international outreach, or would like a member of the NSTIC NPO to join you for inter-governmental dialogue or present at relevant conferences or other events, feel free to contact us at james.sheire@nist.gov. 

In addition, the Identity Ecosystem Steering Group – particularly the IDESG’s International Coordination Committee – is an excellent forum where many of these issues are being discussed and advanced.  Membership is free, and participation is supported virtually; indeed more than twenty countries are already represented.  More details are at http://www.idecosystem.org/.

The Identity Ecosystem Steering Group (IDESG) is shifting into high gear to develop the policies, standards, and accreditation processes for the Identity Ecosystem Framework.    The upcoming May 9-10 Santa Clara, CA plenary will feature the Management Council discussing the IDESG’s work plan for the months ahead, reports by the NSTIC pilot projects on their progress in catalyzing the marketplace in key sectors, and, very importantly, a workshop that will identify a consensus set of use cases – specific examples of the Identity Ecosystem in use in real world applications.

Led by Standards Coordination Committee Chair Cathy Tilton, the workshop will identify the use cases that will help guide the work of the IDESG.   Made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal, the use cases will provide important context for the development of IDESG components such as standards and policies.    For example, use cases can help identify security requirements for a particular application.  Based on this, the IDESG can begin to examine what security standards might be available that reflect those requirements – as well as identify whether there are gaps in existing standards that need to be addressed.  

An express purpose of the use case workshop is to elicit requirements from the broad membership of the IDESG.  Use cases help define the problem we are trying to solve and, by identifying commonalities, can help ensure the IDESG remains well-aligned as a group.  This workshop will support the success of the IDESG by ensuring that the Identity Ecosystem Framework reflects the needs and requirements of a variety of business sectors and communities.  The recent IDESG Work Plan Report to the Management Council includes plans for various stakeholders to develop requirements, and this workshop will provide a framework, a common set of terms and concepts to use, and the opportunity for groups to gather the requirements. 

The workshop will start with presentation of a small set of well-developed and analyzed use cases, followed by breakout sessions in which Privacy, User Experience and Security stakeholders and Domain Expert Working Groups such as Financial and Healthcare  will review the use cases and identify requirements that are applicable to their domains of interest.  Workshop leaders intend to capture a sense of the population that is affected or excluded from each use case, which will provide important input to future business value modeling efforts.  The workshop will culminate with a presentation and discussion of the results.   Please contact Cathy Tilton at cathy.tilton@daon.com for more information.

This is an opportunity to ensure that your organization’s needs, as reflected in use cases, are addressed – and will help guide the IDESG in their important work in the months ahead.  Details as follows:

What:                  Santa Clara IDESG Use Case Workshop

When:                 IDESG Plenary Day 1 (Thursday, May 9, 10:15am)

Where:                The Network Meeting Center in Silicon Valley’s TechMart

                             5201 Great America Parkway, Suite 122

                             Santa Clara, California

Please register for the IDESG Santa Clara Plenary here to attend.  While remote participation will be enabled, the workshop will strongly benefit from your in-person contribution and offer the unique opportunity to network with your peers.  We look forward to seeing you there.

Last September, the National Institute of Standards and Technology (NIST) awarded five NSTIC pilots and earlier this month, we received nearly 70 new NSTIC pilot proposals, submitted in response to a Federal Funding Opportunity (FFO) posted in January 2013.

We’re pleased to announce that NIST will soon release a second NSTIC pilot opportunity for 2013, distinctly separate from the initial FFO that just closed. Whereas the first FFO focused on a broad call for pilots from all sorts of private sector stakeholders, this new opportunity is targeted specifically at state governments.

Why the state government focus? States play a vital role in the Identity Ecosystem – both as potential credential providers, and also as relying parties. With the myriad services that state governments offer – and the number of state services that are not yet offered online, in large part because cost and risk issues involving identity make them challenging to implement – states are ideal partners for NSTIC pilots.

Moreover, the source of funding for these pilots is another federal program set up specifically to help states test improvements in the delivery of Federal assistance programs administered in cooperation with states, or where Federal-state cooperation could otherwise be beneficial. The Partnership Fund for Program Integrity Innovation  was established by Congress in 2010 with the express purpose of helping Federal agencies and state governments work together to find smarter ways to meet the demands of citizens and act as responsible stewards of taxpayer resources. Administered by the Office of Management and Budget (OMB) in consultation with the Collaborative Forum of states and other stakeholders, the Partnership Fund enables Federal, state, local, and tribal agencies to pilot innovative ideas for improving assistance programs in a controlled environment.

Identity and authentication issues are at the forefront of many state government challenges. As state and local governments increasingly shift eligibility and enrollment processes for state services to a virtual environment, they are challenged to develop effective and secure identity verification solutions to support convenient customer access and program integrity across different services and agencies.

While identity issues present major challenges to public benefits programs, many past efforts to address these challenges have failed to gain significant traction due to a number of barriers, including:

1. Concerns about applicant and beneficiary privacy, such as concerns that identity proofing techniques may be too intrusive, as well as concerns that data collected will be inappropriately shared with other programs or parties;

2. Difficulties conducting identity proofing and ensuring that commonly-used identity proofing approaches can adequately cover the beneficiary population;

3. High per-user costs of many identity solutions, some of which even exceed the budgets of agencies, particularly when the solution would only be used in a single service, as well as challenges demonstrating the ability to show how costs could be recovered; and

4. Security challenges faced by some states in demonstrating an ability to securely store sensitive information.

As a step toward addressing these issues, the Partnership Fund is working with the NSTIC National Program Office (NPO) to fund pilots with state agencies or non-profits to enable multiple human services programs to use trusted online credentials that meet NSTIC’s four Guiding Principles – that identity solutions be 1) privacy-enhancing and voluntary; 2) secure and resilient; 3) interoperable, and; 4) cost-effective and easy to use. Additional details on this Trusted Online Credentials for State Agencies pilot program are posted online at the  Collaborative Forum.

The NSTIC NPO intends to release a solicitation in the next 45 days seeking proposals for these pilots. Priority will be given to projects which demonstrate the potential for interoperability of identity credentials issued in partnership with a private provider with both state and Federal programs. The goal is to encourage partnerships between private sector providers and governments at all levels. For this upcoming round of pilots, NIST anticipates awarding up to two pilots.

We advise all interested stakeholders to keep an eye out for the upcoming FFO, which will be posted at both nstic.gov and grants.gov. You can get updates on the FFO and other NSTIC items by following us on Twitter @NSTICNPO.

UPDATE - The FFO is now available here.