Electronic Identity

Online Transactions

Electronic Identity The Who, What, Why, and How eID Will Impact the AAMVA Community

September 2013

Cover photo credits: iStockPhoto/Thinkstock.com Contents

Executive Summary ...... 2

Introduction and Background ...... 4

Electronic Identity Defined ...... 4 National Strategy for Trusted Identities in Cyberspace ...... 5 Cross-Sector Digital Identity Initiative ...... 5 Identity Credential and Access Management (Federal and State) ...... 6 Federal Implementation ...... 6 State Implementation ...... 7 The Issue of Electronic Identities ...... 9 Roles in Electronic Identity (Government and Commercial) ...... 10 Building Trust and Longevity in Electronic Identities ...... 13 Final Thoughts ...... 15

Glossary of Acronyms ...... 16 Bibliography ...... 17 Appendix CSDII Pilot Project Trust Framework (TF) Gap Analysis ...... 18

1 Executive Summary

Increasing numbers of people are using the Internet AAMVA was selected to demonstrate four to perform tasks that once could only be done in capabilities: 1) to verify attributes, 2) to enable person. The rise of this reality has given way to a identity providers to use verified attributes to issue new frontier—dealing with electronic identities a “leveled-up” credential, 3) to authenticate (eID). A chief focus of the eID Working Group is credential, and 4) to enable relying parties to use to identify solutions and standards that yield a high verified attributes to make authorization decisions. level of identity assurance for online transactions. According to the 2010 United States Census, it The actual driver license/identification card places the number of Internet-connected Americans (DL/ID) is the identification credential of choice at an estimated 245 million 1. A broad study throughout North America, with growing conducted in 2007 by Microsoft with 540,000 popularity elsewhere. Online, the information used participants suggests that online users maintain in connection with the DL/ID can become an eID. approximately 25 online accounts 2. The complexity A subtle difference between a physical DL/ID and of how vulnerable people are with the sheer volume eID is that the information connected to a claimed of information that exists in the “ID cosmos” is identity (the vetting/proofing of a claim of staggering. identity) can serve the purpose of an eID. The White House initiative, National Strategy for The Identity, Credential, and Access Management Trusted Identities in Cyberspace (NSTIC), is (ICAM) subcommittee was established by the working collaboratively with the private sector, Federal CIO Council’s Information Security and consumer/privacy advocates, public sector agencies, Identity Management Committee, and tasked with and other organizations to improve the privacy, aligning the Identity Management activities of the security, and convenience of sensitive online U.S. Government. Ultimately, two significant transactions. implementations have arisen from this—a federal roadmap and then by adoption a state roadmap. In this new era we will operate within an “Identity The Federal Identity, Credential, and Access Ecosystem” that will protect the privacy of Management (FICAM) 3 and the State Identity, individuals by reducing the need for individuals to Credential, and Access Management (SICAM) 4 share personally identifiable information (PII) in provide states and provinces a set of solutions for order to identify themselves at multiple web sites increasing security, enhancing compliance and by establishing consistent policies about how capabilities, improving interoperability, eliminating organizations use and manage PII in the ecosystem. redundancy, and, most important, enhancing the NSTIC provided grant opportunities in which protection of PII contained within information

1 https://www.cia.gov/library/publications/the-world-factbook/geos/us.html 2 http://research.microsoft.com/pubs/74164/www2007.pdf 3 http://www.idmanagement.gov/documents/ficam-roadmap-and-implementation-guidance 4 http://www.nascio.org/publications/documents/SICAM.pdf

2 systems. SICAM, and to a lesser degree FICAM, and entities use and rely upon. The development of provide public and private entities with the tools to such a framework will not only benefit the guide them through to developing a secure identity AAMVA community but will serve to benefit infrastructure. similar communities of interest. In the end, all participants in a standardized, properly Ultimately, in order for the ecosystem to deliver on implemented Identity Ecosystem will realize its objective there must be a framework that tangible benefits from greater security, privacy, and enables trust in the electronic identities individuals trust in online transactions.

Executive Summary 3 Introduction and Background

With the advancement of technology, more and more Association’s focus will first be the vetting process that people are using the Internet to perform tasks that needs defining and the technical recommendations on historically were required to be done in person. In light what an electronic identity credential should conform of these realities, AAMVA created a working group to to. AAMVA recognizes that partner organizations like monitor this progression and guide its membership in the National Association of State Chief Information addressing the issues surrounding these changes. Officers (NASCIO) and those in the Federal government are pursuing electronic identification at a Government agencies at all levels, not just those higher level with an emphasis on the role as a relying involved in motor vehicle administration, face party. To that end, the Association plans to support challenges regarding their dependence on and participate in their activities like the SICAM identification. This dependence relates to the issuance subcommittee. of credentials and the privileges that the credential makes available to the individual 5. As has been In addition to the constant evolution of technology, referenced in similar efforts, one privilege that the mounting budget pressures in many jurisdictions credential affords citizens is electronic access to continue to motivate the desire to migrate transactions federally funded programs (such as health and out of the office to the Internet. The move to online wellness, for example—Medicaid). However, issuance services offers a key opportunity for cost reduction and remains program-specific and has redundancy issues improved citizen experience. The current situation is for many of the impacted agencies. In issuing an such that citizens need to create and maintain many electronic (digital) identity, built with multi-platform different identities for access to services. Since the options, the aim is to yield outcomes that result in a assurance level of these electronic identities is low, there more efficient and convenient system for all is a lack of confidence in performing high-value stakeholders, including issuing authorities, identity transactions such as title transfers online. Another focus providers, and relying parties. An additional goal is to of the working group is to define, describe, and deploy allow for commercial entities to participate in order to (and/or enable deployment of) solutions and standards expand benefits of an architecture that can provide that yield a high level of identity assurance for online secure online transactions. These transactions should transactions in intra- and inter-state/province scenarios. not only be between citizens and government, but also between citizens and business, as well as government Electronic Identity Defined and business. The driver license/identification card (DL/ID) is now the identification credential of choice throughout Initially AAMVA’s working group was mandated to North America, with growing popularity as a means of explore, study, and test the identity verification and identification in many other countries. With a photo, proofing functions of the Motor Vehicle signature, and physical description, the DL/ID Administrations (MVAs). The scope of the

5 AAMVA DL/ID Security Framework – February 2004

4 assumes a role beyond its original purpose. The continues to support innovation and a thriving credential is now readily accepted as an official marketplace of products and ideas. identification document for both licensed drivers and non-drivers (issued by same authority that issues the The strategy was developed with substantial input from driver license). The MVAs who issue these documents the private sector and the public. It calls for the effort have unique, continuous and long-lasting contact with to be led by the private sector, in partnership with the most of their constituents from the individual’s pre- federal government, consumer/privacy advocacy teenage years onward. It’s this contact that over time organizations, privacy experts, state and local agencies, has made the DL/ID issuers the most experienced in and others. Establishment of an Identity Ecosystem assuring that people are who they say they are.

The Identity Ecosystem would protect the privacy of Online, the information (some to all) used in connection with the DL/ID can become an eID. A individuals by reducing the need for individuals to share PII subtle difference between a physical DL/ID and eID in order to identify themselves at multiple web sites and by is that the information, also referred to as attributes, establishing consistent policies about how organizations connected to a claimed identity can serve the purpose use and manage PII in the Identity Ecosystem. of an eID.

National Strategy for Trusted Identities would allow individuals to validate their identities in Cyberspace securely when conducting sensitive transactions (such as banking or viewing health records) and let them As stated on the U.S. NSTIC 6 web site, it is a White remain anonymous when they’re not (for instance, House initiative to work collaboratively with the while blogging or surfing the Web). The Identity private sector, advocacy groups, public sector agencies, Ecosystem would protect the privacy of individuals by and other organizations to improve the privacy, reducing the need for individuals to share PII in order security, and convenience of sensitive online to identify themselves at multiple web sites and by transactions. The Strategy calls for the development of establishing consistent policies about how organizations interoperable technology standards and policies — an use and manage PII in the Identity Ecosystem. identity ecosystem — where individuals, organizations, and underlying infrastructure — such as routers and Cross-Sector Digital Identity Initiative servers — can be authoritatively authenticated. The goals of the strategy are to protect individuals, NSTIC provided grant opportunities in which businesses, and public agencies from the high costs of AAMVA was selected as one of five grantees (out of cyber crimes like identity theft and fraud, while 180 applicants). AAMVA is leading a consortium of simultaneously helping to ensure that the Internet private industry and government partners to

6 http://www.nist.gov/nstic/

Introduction and Background 5 implement and pilot the Cross-Sector Digital Identity I Enabling trust and interoperability in online Initiative (CSDII). The goal of this initiative is to transactions, through the application of common produce a secure online solution within the Identity policies and approaches, in activities that cross- Ecosystem that will lead to safer transactions by organizational boundaries. enhancing privacy and reducing the risk of fraud in online commerce. In addition to AAMVA, the CSDII Federal Implementation

Thanks to the work conducted by ICAM, a federal The goal of this initiative is to produce a secure road map came into being, FICAM 7. Its aim is to online solution within the Identity Ecosystem that will provide agencies with architecture and implementation lead to safer transactions by enhancing privacy and guidance that addresses existing ICAM concerns and issues faced daily. In addition to helping agencies meet reducing the risk of fraud in online commerce. current gaps, FICAM provides significant benefits around security, cost, and interoperability which will have positive impacts beyond an individual agency in pilot participants include the Commonwealth of improving the delivery of services by the federal Virginia Department of Motor Vehicles, Biometric government. It also seeks to support the enablement of Signature ID, CA Technologies, Microsoft, and systems, policies, and processes to facilitate business AT&T. The CSDII demonstrates four capabilities: 1) between the government and its business partners and to verify attributes, 2) to enable identity providers to constituents. use verified attributes to issue a “leveled-up” credential, 3) to authenticate credential, and 4) to enable relying The benefits associated with the implementation of parties to use verified attributes to make authorization ICAM converge in increased security, which correlates decisions. directly to reduction in identity theft, data breaches, Identity Credential and Access and trust violations. Specifically, ICAM closes security gaps in the areas of user identification and Management (Federal and State) authentication, encryption of sensitive data, and The ICAM subcommittee was established by the logging and auditing. ICAM also addresses compliance Federal CIO Council’s Information Security and with laws, regulations, and standards as well as Identity Management Committee and tasked with resolution of issues highlighted in Government aligning the Identity Management activities of the U.S. Accountability Office (GAO) reports of agency Government. progress; improved interoperability, specifically between agencies using their personal identity ICAM mission includes: verification (PIV) credentials along with other partners carrying PIV-interoperable or third party credentials I Aligning federal agencies around common practices that meet the requirements of the federal trust by fostering effective government-wide identity, framework. Additional benefits include minimizing credential, and access management; the number of credentials requiring lifecycle I Collaborating with federal government and external management; enhanced customer service, both within identity management activities (non-federal, agencies and with their business partners and commercial, and more) to leverage best practices constituents; facilitating secure, streamlined, and user- and enhance interoperability; and friendly transactions—including information

7 Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance Version 2.0, December 2, 2011.

6 Introduction and Background sharing–which translates directly into improved State Implementation customer service scores, lower help desk costs, and The SICAM 8 Guidance and Roadmap outlines a increased consumer confidence in agency services; strategic vision for state-based identity, credential, and elimination of redundancy, both through agency access management efforts, and emphasizes the consolidation of processes and workflow, and the importance of implementing the SICAM architecture provision of government-wide services to support and services in support of the challenges associated ICAM processes. This results in extensibility of the with trust, interoperability, security, and process information technology (IT) enterprise and reduction improvement. States must provide a secure, auditable in the overall cost of security infrastructure; increase in environment for the processing and exchange of protection of PII by consolidating and securing information across the entire spectrum of state identity data, which is accomplished by locating business. SICAM consists of the programs, processes, identity data, improving access controls, proliferating technologies, and personnel used to create trusted use of encryption, and automating provisioning digital identity representations of individuals and/or processes. These benefits combine to support an non-person entities. This guidance promotes a improvement in the cyber security posture across the federated approach where the identification of the federal government, with standardized controls around information requester and supplier are guaranteed. identity and access management. This is of vital importance in an environment where phishing, scamming, and identity theft are rampant. It The ICAM target state closes security gaps in the areas is essential that state governments take the initiative to of user identification and authentication, encryption of ensure the integrity of the data entrusted to them and sensitive data, and logging and auditing. It supports provide a high level of security and privacy to citizens, the integration of physical access control with customers, and partners. The SICAM architecture enterprise identity and access systems and enables enables states and their partners to share and audit information sharing across systems and agencies with identification, authentication, and authorization across common access controls and policies. Leveraging the state enterprise boundaries. This architecture will digital infrastructure in a secure manner will enable the significantly reduce administrative and technological transformation of business processes, which is vital to overhead caused by incompatible and un-auditable the future economic growth of the United States. This identity management systems (silos), lead to improved document presents the Federal Government with a business processes and efficiencies, and reduce cyber common framework and implementation guidance security risk. needed to plan and execute ICAM programs. While progress has been made in recent years, this document Multiple initiatives are underway to address these is a call to action for ICAM policy makers and challenges—PIV cards are being issued in increasing program implementers across the Federal Government numbers, the public key infrastructure (PKI) has to take ownership of their role in the overall success of connected government and commercial PKIs via a the federal cyber security, physical security, and trust framework, working groups are tackling relevant electronic government (E-Government) visions, as process, technology, and operational questions for supported by ICAM. mission-specific functions, and many others are leveraging digital identities to enable trusted government to citizen, government to business, and government to government transactions. The primary

8 State Identity Credential and Access Management (SICAM)—Guidance and Roadmap Version 1.0, September 2012.

Introduction and Background 7 audience for the document is the state Chief common framework for SICAM in the state Information Officer, state Chief Information Security government, it is understood that agencies are at Officer, state Enterprise Architect, and other SICAM different stages in the implementation of their SICAM implementers at all stages of program planning, design, architectures and programs. As a result, they will need and implementation; however, the document may also to approach alignment with SICAM from varying be used as a resource for systems integrators, end users, perspectives. The SICAM Guidance and Roadmap will other entities, and commercial business partners also serve as an important tool for providing awareness seeking interoperability or compatibility through state to external mission partners and drive the development programs. While this document serves to outline a and implementation of interoperable solutions.

8 Introduction and Background The Issue of Electronic Identities

The World Fact Book, with corroborating information Nigerian money laundering scheme and the Scottish from the 2010 United States Census, places the number lottery scheme, many of these nefarious activities are of Internet-connected Americans at an estimated 245 based on the online information maintained by million 9. A broad study conducted in 2007 by consumers on the Internet. How can we secure that Microsoft with 540,000 participants suggests that piece of the puzzle, ensuring that consumer online users maintain approximately 25 online information is secured and trustworthy across the accounts 10 . By simple calculation, this equates to Internet landscape? roughly six billion distinct accounts. To further complicate, each Internet site offering one of these six One answer is trust. Trust, when considering online billion accounts has its own criteria for maintaining a credentials, carries many connotations—trust in the user account; one might enforce a minimum password credential’s integrity, trust in the individual using the criteria of six characters comprised of letters, numbers, credential, trust in the methods used to define and vet and special characters which is changed every 60 days, the credential, and trust that the level of vetting and another may enforce a password minimum of four completed is sufficient to meet your business characters comprised of numbers only. The onus then is requirements. Trust is the basis for ensuring that online on the user to maintain account information according transactions are accurate, valid, and secure. Trust, in to the varying levels of characteristics. This invariably today’s online world, is based almost entirely on the leads to a minimalist mentality for the end user, using online credential based on the username and password easily remembered and frequently re-used passwords, pair. Oftentimes, especially in merchant situations, this making the interaction ripe for fraud. The account trust is backed by the consumer’s credit card, hardly a username and password pair, a simple online credential, secure control. Simple online credentials provide access is the most untrusted form of credentialing available for to an online resource for an individual but are not online transactions, short of anonymous transactions. adequate for security and are not constructed for cross- organization utilization (federation). The compromised username and password pair represents a small portion of the online theft and fraud Fortunately, for consumers, and public and private that consumers experience in online transactions. The organizations, the online credentials that are overarching problem, however, is so prevalent that the commonplace on the Internet today represent a Federal Bureau of Investigation and the National starting point in securing online transactions. That Center for White Collar Crimes established the starting point represents the baseline from which Internet Crime Complaint Center 11 , a clearinghouse public and private entities can start developing an organization for online theft and fraud activities. integrated approach to Identity, Credential, and Access While the areas identified include issues such as the Management. The FICAM 12 and the SICAM 13

9 https://www.cia.gov/library/publications/the-world-factbook/geos/us.html 10 http://research.microsoft.com/pubs/74164/www2007.pdf 11 http://www.ic3.gov/default.aspx 12 http://www.idmanagement.gov/documents/ficam-roadmap-and-implementation-guidance 13 http://www.nascio.org/publications/documents/SICAM.pdf 9 Figure 1. FICAM Overview

roadmaps provide a set of solutions for increasing I Entities can leverage identity establishment and security, enhancing compliance capabilities, improving vetting processes based on agreed upon standards interoperability, eliminating redundancy, and most for identity providers, ensuring that credentials importantly enhancing the protection of PII contained match their business requirements. within information systems. I Entities have the ability to provide products such as hardware tokens and smartcards to enable deeper At the high level, Figure 1 displays the interactions assurance levels for consumers. associated with electronic identities as a FICAM overview. The figure illustrates the identity life-cycle I Entities share in the governance process necessary and underscores some of the potential application of for operating a successful Identity Ecosystem based electronic identity across jurisdictional and corporate on standards. borders. I All parties benefit from consumer information not being propagated throughout the Identity Roles in Electronic Identity (Government Ecosystem, instead relying on token passing and and Commercial) attribute validation. SICAM, and to a lesser degree FICAM, provide public I Entities benefit from increased security as public and private entities with the tools to guide them and private entities can work to actively establish through to developing a secure identity infrastructure. the governing principles for a successful Identity Building trust frameworks across the public and Ecosystem. private sector provides many potential benefits.

10 The Issue of Electronic Identities The true benefit of a federated secure identity describes the interactions between a user of infrastructure is the ability to leverage the identity government services (citizen beneficiary) and a systems across an entire domain, to the benefit of government organization, from the citizen perspective. partner organizations. It also means that public and The citizen has a clear need to interact with private entities have the ability to provide ancillary government to obtain services such as registering a services to further vet credentials to match agreed upon vehicle or requesting benefits. The citizen establishes assurance levels. Naturally, this extends to new business an electronic identity with one of the identity opportunities. providers within the Identity Ecosystem. The citizen performs the actions required by the Identity Besides the benefits to the business and government Ecosystem to establish an electronic identity at a communities, consider the following scenarios that certain level of assurance (as approved by the operating may underscore the point. For example, a company or “trust” rules of the federation). The citizen may elect that sells online products and provides online support to utilize a private sector entity such as Microsoft communities implements a full-scale identity Account ™ to establish an electronic identity. Once the management system. The company has the citizen has completed the vetting process as required, responsibility to manage all of the customer the credential can be utilized across the federated information related to the customer identity entities. credential. This may include personally identifiable and financial information. In this case, the company The citizen, using a vetted credential, logs into a holds singular responsibility for user data, government portal offering the services required. The authorization, and authentication, ultimately being portal directs the transaction based on the assurance responsible for managing the identity of the user for level required and requests additional information enabling a secure purchase transaction. from the citizen as needed to grant the necessary authorization for the transaction. The citizen opts-in as If, however, the company participated in an Identity necessary and successfully completes the transaction at Ecosystem where they were a relying-party, the the first department. As indicated earlier, the citizen company could enjoy the benefits associated with the also needs to complete a second transaction, such as a full-scale identity management system, with few of the vehicle registration and logs in to the appropriate pitfalls. In an Identity Ecosystem, the company may government web site using an established credential not need to maintain repositories of personally (notice no additional credential is necessary as the identifiable or financial information on customers, and information on the citizen is federated across the may be able to focus instead on validating attributes of Identity Ecosystem). At this point, the second system the customer identity credential with identity service requests information as necessary to provide providers. This scenario provides the merchant with appropriate authorization and the transaction is the ability to scale back on their identity management completed. The citizen has the benefit of interacting system and focus on their core mission, sales. An with public and private sector entities using a single example of this type of identity case is found in the credential, only providing additional information as OpenID standard in use by online payment companies necessary to authorize the user to complete to streamline online purchases. transactions. An example of this type of credential would be university and college systems utilizing In addition to the online merchant scenario, the InCommon to federate identities across the education interaction between citizens and varying levels of community. The benefits of this use case: government cannot be overlooked. This scenario

The Issue of Electronic Identities 11 I Citizen views government (services and benefits) propagation of public and private information to that through a single point of entry, providing additional necessary to complete a transaction. The trust information as necessary to increased framework that specifies the standards is critical to the authorizations. success of the Identity Ecosystem.

I Citizen data is more secure, as less information is These scenarios represent the potential to streamline stored in centralized repositories and transmitted identity management from the consumer and business less often. perspective, offer enhanced security including I Citizen can further secure credential and PII by advanced multi-factor authentication, and have the increasing the assurance level of a credential by capability to cross online domains. The Identity adding multi-factor authentication 14 mechanisms to Ecosystem based on trust also brings in new the credential. opportunities for public and private sector entities to grow business value while enhancing the services I Citizen saves time, effort, and reduces opportunity provided to their respective customer communities. for error through less duplication in entering information multiple times across web sites to Roles in electronic identity have been defined in many obtain government services and benefits. trust frameworks and carry monikers such as “identity provider,” “relying party,” and “assuring party,” among The scenarios presented here have a common thread in others. They are all based on standards that have been that they are based on standards adopted by an developed through the concerted efforts of many Identity Ecosystem. The standards allow the Identity dedicated individuals the world over. The federations Ecosystem participants to play multiple roles in that are based on these standards likewise have enabling a secure federated trust model. These implementations that speak to the validity, security, standards allow for advanced security measures to the and benefit of the new online identity model. benefit of users of the system and minimize the

14 Multi-factor authentication is an approach which requires the presentation of two or more of the three authentication factors: “has”, “knows”, and “is”.

12 The Issue of Electronic Identities Building Trust and Longevity in Electronic Identities

In order for the ecosystem to deliver on its objective I InCommon Trust Framework—Trust framework there must be a framework that enables trust in the designed to facilitate authentication and identity electronic identities people use and rely on. The management for students, faculty, staff, and other framework is a compilation of enforceable rules, service providers for institutions of higher defined governance, and standards. For the AAMVA education. community in the wake of 9/11 a framework was developed around the challenge of issuing DL/IDs. In order for the ecosystem to deliver on its objective What was developed then is similar to what is needed there must be a framework that enables trust in the now—rules for how an identity is vetted/proofed; methods for ensuring those within the community electronic identities people use and rely on. are all operating by the same set of rules; a system for dealing with those that are not. These basic principals I Kantara Initiative Trust Framework—Trust are at the heart of what is referred to as a “trust framework developed on a for-profit, subscription framework (TF)” in the NSTIC space. Not wanting to basis to enable secure, identity-based, online reinvent the wheel the CSDII team has performed a interactions in a secure environment. comparative analysis of those most prevalent frameworks in existence in order to make a I Open Identity Exchange (OIX)/OITF Model—Set recommendation on a way forward. Having completed of guidelines and recommended mechanisms (Level this, a decision was made to endorse the use of the of Assurance and Level of Protection) for InCommon TF (for the CSDII pilot). developing and implementing a trust framework for secure, confidence-based exchange of information. Model TFs reviewed in the analysis: I CIVICS/IDCubed.org Trust Framework—Model I AAMVA DL/ID security framework—Set of designed by Civics (in partnership with the MIT requirements, recommendations, and standards Media Lab) and IDCubed.org, a private non-profit maintained by AAMVA for use by Motor Vehicle organization, which outlines the business, legal, and Administrations to ensure drivers license and technical elements of a trust framework. identification security.

I eHealth Exchange Data Use & Reciprocal Support Key Findings Agreement (DURSA)—Trust framework The model TFs ranged on a continuum from established to support the exchange of health “descriptive,” those setting minimum standards for information and messaging within the Nationwide trust-based information exchanges without actually Health Information Network (NwHIN, now structuring an exchange, to “prescriptive,” those eHealth Exchange). establishing specific agreements, policies, procedures, and specifications to support an information exchange.

13 Substantive gaps in alignment with the Project TF I Addressed the cited concerns relating to legal issues requirements were observed along this continuum. for state government agencies, including sovereignty, statutory authority, liability, and grant Primary gaps in alignment included the following: of authority.

I The more descriptive TFs lacked the level of I Provided detailed guidance, agreements, and specificity required for the Project TF; these support documentation for structuring an exchange descriptive TFs may be used as high-level checklists in the ID assurance and management space. for the Project TF but failed to provide the I Established binding BLT requirements for all necessary business, legal, and technical (BLT) relevant participant types, including identity provisions for the Project exchange; the Project TF providers (IDPs), relying parties (RPs), and will need to cover the full range of BLT assurance providers. requirements. I Featured extensive use-cases demonstrating the I The prescriptive TFs tended to be either excessively types of participants, types of exchanges, domain-centric or failed to take account of the operational/functional elements, and other unique legal status of government agencies, dimensions of the exchange. particularly state government; issues of sovereignty, statutory authority, liability, and grant of authority I AAMVA would seek to imitate InCommon and its will need to be fully addressed in the Project TF. architecture to use as a baseline/model for our members and the larger state/provincial government Conclusion community of interest.

The InCommon TF Model was found to be the most robust, mature, and scalable of those reviewed for the Project. Primary strengths of the InCommon TF:

14 Building Trust and Longevity in Electronic Identities Final Thoughts

Much of this document has been dedicated to defining Online service delivery is becoming the norm for electronic identities, defining the value in reigning in public services. Examples include the purchase of the propagation of electronic identities, and the products, payment of government fees and taxes, potential we have in building a secure Identity banking, and social media interaction. Each of these Ecosystem to the benefit of our respective constituents. services requires some sort of credential to be In no uncertain terms, building better electronic established by the user and is a username/password identities based on a trust framework in a trusted pair in most cases. Account credentials require the use Identity Ecosystem will benefit citizens, government, of PII for creation. Since the required information and businesses. varies among providers, the user eventually has a majority of their PII housed in multiple databases All participants in a standardized, properly increasing the risk of misuse of personal information implemented Identity Ecosystem realize tangible that could lead to fraud and stolen identities. benefits from greater security, privacy, and trust in online transactions. Entities building identity systems The eID will reduce these risks and protect user realize cost avoidance benefits by not building privacy by requiring the users to provide minimal unnecessarily redundant systems while users realize personal information to create one account that can be reduced occurrence of theft and fraud due to data loss used for any online transaction. This cross platform and realize increased overall security through the approach will lead to application development implementation of multi-factor authentication efficiencies, a more efficient service delivery model, methods. and a seamless user experience and benefit to all participants.

15 Glossary of Acronyms

AP attribute provider

BLT business, legal, and technical

CIO chief information officer

CSDII Cross-Sector Digital Identity Initiative

DL/ID driver license/identification card

DURSA Data Use & Reciprocal Support Agreement (DURSA)

eID electronic identity

FICAM Federal Identity, Credential, and Access Management

GAO Government Accountability Office

ICAM Identity Credential & Access Management

IDP identity provider/proofer

IT information technology

MVA Motor Vehicle Administration

NASCIO National Association of State Chief Information Officers

NSTIC National Strategy for Trusted Identities in Cyberspace

OIX Open Identity Exchange

PII personally identifiable information

PKI public key infrastructure

PIV personal identification verification

RP relying party

SICAM state identity, credential, and access management

TF trust framework

16 Bibliography

AAMVA DL/ID Security Framework—February 2004, http://www.aamva.org/Identification-Security/ (Background Information Tab)

Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance Version 2.0, December 2, 2011, http://www.idmanagement.gov/documents/ficam-roadmap-and-implementation -guidance

State Identity Credential and Access Management (SICAM) – Guidance and Roadmap Version 1.0, September 2012, http://www.nascio.org/publications/documents/SICAM.pdf http://www.nist.gov/nstic/

https://www.cia.gov/library/publications/the-world-factbook/geos/us.html

http://research.microsoft.com/pubs/74164/www2007.pdf

http://www.ic3.gov/default.aspx

http://www.idmanagement.gov/documents/ficam-roadmap-and-implementation-guidance

http://www.census.gov/compendia/statab/2012/tables/12s1055.pdf

http://www.incommon.org/

17 Appendix CSDII Pilot Project Trust Framework (TF) Gap Analysis

Trust | Security Frameworks – Key Elements & Provisions for CSDII Pilot Project

Business Legal Technical Other

• Definitions for • Definition/ • Performance & • Openness & “Permitted Purpose” Identification of Service Transparency “Applicable Law” Specifications • Governing Body & • TF Lifecycle Change Processes • Legal Agreements • Security, Privacy & Management (Set) for Exchange Confidentiality (“Living Agreement”) • Operating Policies & Structure (Technical: Procedures • Support & Capacity (IdPs/RPs/ITSPs) Infrastructure/ Building (IGs) • Security, Privacy & Architecture ) • Security, Privacy & Confidentiality • Scalability to Consent Provisions • Breach Notification (Business: Support Array of Consent/Auth.) • Assignment of • System Access Participants Liability & Risk for (ID/Authentication) (Horizontal/Vertical) Trust | Security • Suspension & Participants Framework Termination • Provisions for Future • Glossary of TF Comparison (Voluntary & • Representations & Use of Data Terms/Definitions Involuntary) Warranties • Duty of Response • Modular Approach • Data Elements & • Grant of Authority by Participants for TF Elements – Data Classification (IdPs/RPs/ITSPs) IdPs, RPs & ITSPs • Dispute Resolution (Attribute Level/PII) • Onboarding, Testing • Law Enforcement • Authorizations for • Expectations of & Certification (LE) Use Case: Data Requests by Performance Requirements Support for Data Participant Sharing • Use Cases • Handling of Test • Open Disclosure & (Exchange & Data v. Production • Federal Government Anti-Circumvention Participant Types) Data Use Case: Federal • Confidential Agency as RP • Compliance with Participant (FICAM) External/SDO Information Standards • Audit, Accountability & Compliance

18 Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Data element-level + Assumes MVA + Electronic verification + Compliance and verification and compliance with (w/issuing entity) of implementation validation (§1.3 #9, applicable law, DL/ID data elements support thru FDR §1.4 #10, §1.4 #13, document use, data (§1.3 #9, §3.3.3, employee training §3.3.4, §7.4, Appdx.) sharing (§1.5 All §6.3) (§1.1 #1, §3.3.1, Recs., §3.1, §3.2, §4.1) + Data (Name) + Standards for MVA §3.3.5, §4.5, §8.3, collection, use and system integrity, + Common definition Appdx.) maintenance (§3.3.4, interoperability & of “residency” (§1.3 §7.1, Appdx.) + Enforcement thru reciprocity (§2.0, #6, §3.3.3) tied to business §3.1, §3.3.2, §4.2, DL/ID verification + AAMVA DL/ID requirements (§2.0, §4.5) (§1.3 #7, §3.3.3, Personal ID Card §3.1, §4.5) §6.1) Design Specification + Compliance & (§1.4 #12, §3.3.4, + Audit plan (§1.1 #2, oversight with + “End of stay” on 7.3, Appdx.) §1.2 #5, §3.3.2, §5.1, adopted standards immigration doc. as Appdx.) (§3.3.2, §4.5, §5.2) expiration date for + Procedures for initial DL/ID - data element customer ID and + Compliance and + System integrity, derivation (§1.4 #11, validation (§3.3.3, oversight, internal security & privacy §3.3.4, §7.2, Appdx.) §6.0) controls (§3.3.2, (§4.6) §4.4, §5.2) + Horizontal scalability + Record & document thru reciprocity use, permitted + Risk assessment & AAMVA DL/ID (§3.1) Security purpose (§3.3.5, management (§1.1 Framework §4.6, §7.1, §8.0) #3, §3.3.5, §4.2, + Openness enforced §4.4, §8.0) thru privacy + Benefits/ business provisions (§4.6, drivers (§2.0, §3.1) + Privacy (§1.1 #4, §7.1) §4.2, Appdx., §3.3.4, + Business-driven §3.3.5, §4.5, §4.6, + Limits on disclosure agreement among §7.1, §7.4, §8.3) enforced thru MVAs (§3.1, §3.3, privacy provisions §4.5) + Common set of (§4.6, 7.1) verifiable resources + Business (§1.3 #8, §3.3.3, + Glossary of requirements for §6.2, Appdx.) abbreviations/ P&Ps, document acronyms (§9.0) issuing systems, and + Machine-Readable internal controls, Technology (MRT) + LE Use Case (§1.5 Driver License (§3.3.5, §8.2, Rec. #8, data Agreement (DLA) Appdx.) sharing §3.3.5, §8.3, (§3.3.1, §4.2, §4.5, Appdx.) + Restrictions, Appdx.) minimum penalties and sanctions (§3.3.5, §8.1, Appdx.)

Appendix 19 Trust | Security Framework – Gaps ( –) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

– Does not bind RPs – Does not contain – Contains only limited – Does not support or or ITSPs to same set necessary set of operational/technical anticipate non-MVA of business legal agreements to components participants, except requirements as IdPs structure an for LE – Fails to clearly exchange (horizontal/vertical – Fails to establish establish scalability) governing body (also – Lacks the force of performance & no granting of law (i.e., legal service specifications – Does not bind RPs authority) or change contract) to compel or applicable or ITSPs to same set processes to participant standards of training maintain framework compliance or requirements as IdPs – Does not bind RPs or performance – Does not address ITSPs to same set of – Lacks governance participant – Fails to establish technical provisions to ensure suspension or P&Ps for dispute requirements as IdPs a “living” framework termination resolution – Does not address – Structured as a – Does not bind RPs breach notification or AAMVA DL/ID voluntary agreement or ITSPs to same related security Security rather than a binding legal requirements as requirements contract; inadequate IdPs Framework – Limited to structure an – Does not include specifications for exchange anti-circumvention system access provisions (one-off policies agreements) – Lacks requirements – Due to scalability on participant duty to issue, fails to assign respond to requests liability & risk to non- – Does not address MVA participants treatment of test data – “Thin” assumption of v. production data; participant future use of data compliance with applicable law may be inadequate to meet legal (OAG) scrutiny

20 Appendix Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Definitions of + Definition/ + Performance & + Openness & permitted purpose compliance w/ service transparency (§1.jj; §3; §5.01-5.03) applicable law (§1.a; specifications (§10; (overview; recitals) §15.11; §23.01; Appdx.; change + Governing body (§4) + TF lifecycle Appdx.) process in §10.03) & change processes management (“living (§10.03; §11.03) + Legal agreements + Security, privacy & agreement”) (set) for exchange confidentiality (§7; (overview; §4; + Operating policies & structure (recitals; §8; §14) §10.03; §11.03) procedures (§11; §1.ee; §3.01; §23.07) Appdx.; change + Breach notification + Scalability to process in §11.03) + Security, privacy & (§14.03) support array of consent (§14) participants + Security, privacy & + System access (§6) (horizontal/vertical) confidentiality (§7; + Liability (§18) + Provisions for future (participant types §8; §14) + Representations & use of data (§5.02) defined in §1; + Suspension & warranties (§15; expectations in + Expectations of eHealth termination (§19) disclaimers in §17) §12.02; duties in Exchange Data participants (§12) §13) + Data elements & + Grant of authority Use & + Duty of response by data classification (§4.03) + Glossary of TF Reciprocal participants (§13) (attribute level/PII) terms/definitions (§1) Support + Dispute resolution (§1.v; §1.w; §1.kk) + Onboarding, testing Agreement (§21; Appdx.) + Modular approach & certification (DURSA) + Expectations of for different + Authorizations for (§10.01) performance (§12) participant types data exchange (§12; + Handling of test data (types defined in §1; §13) v. production data expectations in + Open disclosure & (§15.07) §12.02; duties in anti-circumvention §13; warranties in (§15; §23.04; §23.07) §15) + Confidential participant information (§16) + Audit (§9) + Accountability & compliance (§10.01; §11.01; §15.03; §15.06)

Appendix 21 Trust | Security Framework – Gaps ( –) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

– Definition of – Definition of – Regulations – Limited scalability “permitted purpose” “applicable law” governing security, outside of the health assumes all would need to be privacy & IT/HIPAA domain; participants will expanded to cover confidentiality differ requires expanded exchange same type required data based on scope of applicable of data/message elements and government agency law and participant content; no domains levels and domains; types (IdPs; RPs; distinction between TF needs to address ITSPs) – Uncertain whether participant types (or at least take into state agencies would – Acts as a blanket TF (IdPs; RPs; ITSPs) account) have legal ability to under which each – Governing body not execute TF – Breach notification participant must fully established in agreements, and if and other technical execute/comply or statute/regulations so at what level requirements would forfeit participation; may have limited (agency head? need to be no modular capacity to issue Secretariat?) reconciled with approach for binding actions applicable different participant – Assignment of statutes/regulations types (IdPs; RPs; – Legal status of TF liability, ITSPs) eHealth may be too limited to representations and – Expectations for Exchange Data bind government warranties, as participants may be – Training and Use & agencies to written, would be interpreted as a implementation Reciprocal operational P&Ps barriers for state government agency support (IGs) left up Support agencies ceding its statutory/ to individual – Governing body Agreement regulatory authority participants or action to suspend or – Grant of authority to vendors; disparate (DURSA) terminate may be governing body mechanisms interpreted as a would not be government agency possible for state – Contains only ceding its statutory agencies general references to authority (sovereignty) use cases and other business elements – Assumes transmittal – Audit, compliance of a standardized and dispute “document” (HL7 resolution CCD) and message requirements may be content; does not interpreted as a specify down to the government agency attribute level ceding its statutory/ regulatory authority – Does not provide guidance on risk analysis or management

22 Appendix Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Definitions of + Definition/ + Performance & + Openness & permitted purpose compliance w/ service specifications transparency (ICBP; (ICPOP; IAS; limits applicable law (PA (FTG; ICBP; PA §6, §7) ICBL) on use of ID §15) + Security, privacy & + TF lifecycle information in PA §9) + Legal agreements confidentiality (ICBP; management (“living + Governing body & (set) for exchange ICPOP) agreement”) (ICBL; change processes structure (ICB; ICPP; ICBP; PA §17) + Breach notification ICBL; ICPP; ICPOP; PA §6, §7.b) (PA and addenda; + Implementation PA §17) + Security, privacy & ICPOP) support (ICBP; + Operating policies & consent (PA §6, §9) ICPOP) + System access procedures (ICBP; + Liability (PA §11, (ICBP) + Scalability to ICPP; ICPOP) includes disclaimer & support array of + Provisions for future + Security, privacy & limitations) participants use of data (ICPOP) confidentiality (PA (horizontal/vertical) + Representations & §6, §9; ICPOP) + Expectations of (participant types warranties participants (ICBP; defined in Join §1, + Suspension & (addressed in PA PA §6, §7) Participants; ICBP) termination (PA §5.b, §7.b) §5.c; ICBL) + Duty of response by + Glossary of TF + Grant of authority to InCommon participants (ICBP; terms/definitions + Data elements & executive (PA §18) Trust PA §6, §7) (InCommon Website) data classification Framework + Dispute resolution (attribute level/PII) + Onboarding, testing + Modular approach process (PA §10; (IAS; FTG; PA §6.b) & certification (ICBP) for different ICBL §5) participant types + Expectations of + Handling of test data + Authorizations for (ICB; Participants) performance (ICBP; v. production data data exchange (PA PA §6, §7) (ICPOP) §18) + Use cases and + Open disclosure & examples anti-circumvention (InCommon Website; (PA §14, §16) ICBP; Participants) + Confidential participant information (PA §8, §9) + Audit (IAF) + Accountability & compliance (PA §15; IAF)

Join= www.incommon.org/join.html ; Participants= www.incommon.org/participants/ FTG=InCommon Federated Technical Guide; ICBP=InCommon Basics and Participating in InCommon, Jan. 21, 2011 ICPP=InCommon Policies and Practices; ICPOP=InCommon Participant Operational Practices; ICBL=InCommon Bylaws PA=InCommon Participation Agreement; IAS=InCommon Attribute Summary; IAF=InCommon Assurance Framework

Appendix 23 Trust | Security Framework – Summary of Alignment with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment

The analysis failed to identify any substantive gaps in the InCommon TF Model, which ranked as the most robust, mature, and scalable of those reviewed for the CSDII Pilot Project. Primary strengths of the InCommon TF: • Addressed the cited concerns relating to legal issues for state government agencies, including sovereignty, statutory authority, liability, and grant of authority. InCommon Trust • Provided detailed guidance, agreements, and support documentation for structuring an exchange Framework in the ID assurance and management space. • Established binding BLT requirements for all relevant participant types, including Identity Providers (IdPs), Relying Parties (RPs), and Assurance Providers. • Featured extensive use-cases demonstrating the types of participants, types of exchanges, operational/functional elements, and other dimensions of the exchange.

24 Appendix Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Definition of + Definition/ + Performance & + Open & transparent permitted purpose identification of service governance model (KTR MTAU) applicable law (KTR specifications (AP; (MA goals #3, #4; MTAU; see also KTR/KTV; KTR op; BL §3) + Governing body (BL “Governing law and MTAU; KIC; Member §4; OP §2) & + TF lifecycle jurisdiction” protection & change/ amendment management (MA provision in KTR treatment in IPRP) processes (BL §12; goals #4, #6) MTAU) OP §9; MA §3) + Security, privacy & + Support & capacity + Legal agreement for confidentiality (AP; + Operating policies & building (IGs) exchange structure MA) procedures (OP) (MA) + Scalability to + Technical + Security, privacy & support array of + Security, privacy & certification & testing confidentiality (AP; participants consent provisions (AP; KIC) MA) (horizontal/vertical) + Liability (KTR MTAU) + Standards for (member types BL + Suspension & technical & §8) termination (MA §2; + Warranty (KTR operational BL §8.11; KTR MTAU) + TF definitions (BL Kantara interoperability (KTR; MTAU) §1; OP §1; IPRP Art. Initiative + Grant of authority MA goal #3; #7; KIC) 2) Trust + Data elements & (MA) Framework data classification + Authorizations for (KTR; KIC) data requests by + Expectations of participant performance (AP; + Open disclosure & KTR MTAU; KIC) anti-circumvention + Use cases (Working (Other agreements in groups for business KTR MTAU) cases-trusted + Confidential federations) participant information (Options set in IPRP; IPRP Art. 3) + Accountability & compliance (w/ antitrust laws in BL §17; MA)

BL=Bylaws; IPRP=Intellectual Property Rights Policies; MA=Member Agreement; OP=Operating Procedures KTR=Kantara Trust Registry; KTV=KTR Trust Validation; KTR MTAU=Metadata Terms of Access & Use; KIC=Kantara Interoperability Cert.-SAML, OATH, etc. AP= Assurance Programs; Identity Assurance Accreditation & Approval and Interoperability Certification Programs

Appendix 25 Trust | Security Framework – Gaps ( –) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

– Permitted purposes – TF contains a well – Performance, service – Governance model limited to assurance established legal and other technical sets up for a “living” & interoperability framework for specifications set for TF thru an extended dimensions; “thin” membership & IdPs, Credential lifecycle, with on provisions for RP governance but does Service Providers & horizontal and use not structure an Assurance Providers; vertical scalability; actual exchange limited coverage for however, limited on – Governance model & RPs RPs and other operational – “Thin” statements re potential procedures do not compliance with – RPs play narrow role participant/member structure an actual applicable law as inputs on IdP and types exchange rather assurance – TF limited to setting designed to be used requirements requirements for by members for their member use of – Specifications do not exchanges technical and cover an actual Kantara – TF focuses on IdPs, operational exchange but Initiative Credential Service assurance programs designed to support Trust Providers & for their own member use in their Framework Assurance Providers; exchanges exchanges provisions limited for – TF does not fully – Certification & testing RPs address audit but “thin” coverage requirements for RPs or other potential – Legal provisions participant/member contain only limited types provisions for RPs; main focus on IdPs, Credential Service Providers & Assurance Providers – Bylaws and operational policies do not provide for dispute resolution

26 Appendix Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Definitions of + Compliance w/ + Performance & + Openness & permitted purpose applicable law (OIX; service transparency (OIX; (OITF §III.B, §III.C, OITF §V) specifications (OIX; OITF §I; statement in §V) OITF §II, §III.A, §III.B) OITF §V, §VI) + Legal agreements + Governing body & (set) for exchange + Security, privacy & + TF lifecycle change processes structure (OIX; OITF confidentiality (OIX; management (OIX; (OIX; OITF §III.C) §II, §III.C) OITF §III.A; §V) OITF §II) + Operating policies & + Security, privacy & + Expectations of + Scalability to procedures (OIX; consent (OIX; OITF participants (OIX; support array of OITF §II, §III.B, §III.A) OITF §III.A, §III.B, participants §III.C) §III.C) (horizontal/vertical) + Liability, (OITF §II, §III.C, §IV) + Security, privacy & representations & + Onboarding, testing confidentiality (OIX; warranties (OITF & certification (OIX; + High-level definitions OITF §III.A, §V) §III.C) OITF §II, §III.B) (OITF §I) Open Identity Exchange + Suspension & + Grant of authority + Modular approach (OIX)/OITF termination (OITF (OIX; OITF §III.C) for different §III.C) participant types Model + Dispute resolution (OIX; OITF §II, §III.C) + Data elements & (OITF §II, §III.C, §V) data classification + Use cases & + Authorizations for (attribute level/PII) examples of TFs data exchange (OIX; (OIX; OITF §III.A, (OITF §IV) OITF §III.A) §III.B) + Anti-circumvention & + Expectations of open disclosure performance (OIX; (OITF §V) OITF §II, §III.C) + Audit (OIX; OITF §II, + Use cases for §III.B, §V) agreement, transaction & + Accountability & participant types compliance (OIX; (OITF §I, §III; OIX) OITF §II, §V)

Appendix 27 Trust | Security Framework – Gaps ( –) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

– Highlights primary – Outlines primary – Identifies primary – Addresses the business-related TF legal TF elements technical elements necessary principles elements and and requirements; and requirements to of openness, requirements; however, fails to be covered in a TF; transparency, however, fails to provide documents/ however, fails to scalability and full provide level of agreements needed provide level of lifecycle specificity needed for structuring an specificity needed for management; for structuring an exchange structuring an however, as with the exchange exchange other domains fails – Provides a checklist to provide the – Reads more like a for the set of – Provides a checklist degree of specificity high-level checklist necessary legal for the set of needed for for TF elements & agreements for the necessary technical structuring an provisions rather TF and a high-level specifications, exchange than an actual TF identification of the certification and (That said, OITF will issues to be covered testing of those Open Identity be useful as a in the agreements specifications; Exchange checklist to ensure (i.e., grant of however, OITF stops (OIX)/OITF alignment for the authority, liability, as simply identifying Model CSDII TF; also, OITF warranties, the specifications provides several use authorization, etc.); and LOA certification cases and examples however, no without giving of an ID exchange) “concrete” examples detailed content or agreement models provisions – States the requirement for participants to comply with applicable law but does not cite governing statutes, laws and regulations for an actual exchange

28 Appendix Trust | Security Framework – Alignment (+) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

+ Definitions of + Compliance w/ + Performance & + Openness & permitted purpose applicable law service transparency (ID3LA (ID3LA §3, §5.2 §5.3; (ID3LA §9.7, §18, specifications (ID3LA §1; CTA §2.4.2.1) CTA §2.4.2.5) §24.8) §9) + TF lifecycle + Governing body & + Legal agreements + Security, privacy & management (ID3LA change processes (set) for exchange confidentiality (ID3LA §1) (ID3LA §9.8) structure (ID3LA; §6, §17; CTA + Scalability to CTA §2.2) §2.4.2.7) + Operating policies & support array of procedures (ID3LA) + Security, privacy & + Breach notification participants (ID3LA consent (ID3LA §6, (ID3LA §17.3) §1, participant types + Security, privacy & §17; CTA §2.4.2.7) defined in Schedule confidentiality + System access 2; CTA §1.2) (ID3LA §6, §17; CTA + Liability (limitations (ID3LA §7.2) §2.4.2.7) ID3LA §13.2; CTA + Glossary of TF + Provisions for future §2.5.2) terms/definitions + Suspension & use of data/services (ID3LA Schedule 2; termination (ID3LA + Representations & (ID3LA §3.8) CTF Addenda 2) §4.4, §11) warranties (ID3LA + Expectations of §19) + Modular approach + Data elements & participants (ID3LA for different data classification + Grant of authority §4, §9; CTA participant types (attribute level/PII) (ID3LA §24; CTA §2.4.2.2.3.1) CIVICS/ (ID3LA §1, (ID3LA §3, §5.2 §5.3; §2.2.1) IDCubed.org + Duty of response by participant types CTA §2.4.2.2.3.1) Trust + Dispute resolution participants (ID3LA defined in Schedule Framework + Expectations of (ID3LA §21) §4, §9; CTA 2; CTA §1.2) performance (ID3LA §2.4.2.2.3.1) + Authorizations for + ID3LA= IDCubed.org §4, §9; CTA data exchange (§12; + Onboarding, testing Legal Agreement for §2.4.2.2.3.1) §13) & certification Trust Framework (ID3LA §4; CTA Data Store, Nov. 8, + Non-exclusivity §1.3.1) 2012/CTF=Civics (ID3LA §5.4, Model Trust assignment ID3LA Framework for §24.3) Person Data, Feb. + Confidential 22, 2012 participant information (ID3LA §7, §10, §17; CTA §2.3.1.1) + Audit (ID3LA §16.2; CTA §2.4.2.8) + Accountability & compliance (ID3LA §16.3, §18; CTA §2.4.2.8)

Appendix 29 Trust | Security Framework – Gaps ( –) with Required Elements & Provisions for CSDII Pilot Project Exchange Assessment Business Legal Technical Other

– CIVICS Model TF – CIVICS Model TF – Model TF does not – Model could be contains the high- features legal provide level of supported more fully level elements & agreements to specificity in key by use cases, provisions to support support an technical areas, examples of business-related exchange; however, including participants & requirements for an it is unclear whether performance & transactions, & exchange; however, the model’s legal service implementation the model has not framework would be specifications; guides achieved a level of adequate to cover onboarding, testing & maturity needed to state agency certification; breach fully support the participants notification & system CDSII Pilot Project security CIVICS/ – For future analysis, it IDCubed.org – Additional model would be beneficial Trust documentation & to have examples of Framework examples, other particularly of the implementations, Commonwealth of particularly the Massachusetts, Commonwealth of would be needed to Massachusetts make a final procurement TF determination (referenced during presentation on – Model does not fully 2/14/2013) address data elements & permitted purposes

30 Appendix American Association of Motor Vehicle Administrators 4301 Wilson Boulevard, Suite 400 Arlington, Virginia 22203 703.522.4200 | aamva.org