What Is an Identity Trust Framework? Addressing the Legal and Structural Challenges

1. What Is an Identity Trust Framework?Addressing the Legal and Structural Challenges Thomas J. Smedinghoff Wildman, Harrold, Allen & Dixon LLP Chicago Chair, ABA Identity Management Legal Task Force

2. Many Transactions Involve Trust Frameworks Credit card trust framework ACH electronic funds transfer trust framework Privacy (e.g., TRUSTe trustmark) The are a set of specs and rules and legal obligations that address a specific element or issue of importance to the transaction We are addressing an identity trust framework

3. The Threshold Problem We’re not all talking about the same thing What does “identity trust framework” mean to you? Consider some examples of definitions . . .

4. Much Disagreement Re What a Trust Framework Is • FICAM: processes and controls for determining an identity provider’s compliance to OMB M-04-04 Levels of Assurance • ISO 29115 Draft: a set of requirements and enforcement mechanisms for parties exchanging identity information • Kantara: a complete set of contracts, regulations or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements • OIX: a certification program that enables a party who accepts a digital identity credential (called the relying party) to trust the identity, security, and privacy policies of the party who issues the credential (called the identity service provider) and vice versa. • OITF Model: a set of technical, operational, and legal requirementsand enforcementmechanisms for parties exchanging identity information

5. Much Disagreement Re What a Trust Framework Is • NSTIC 4/15/2011 Final: • The Identity Ecosystem Frameworkis the overarching set of interoperability standards, risk models, privacy and liability policies, requirements, and accountability mechanisms that structure the Identity Ecosystem. • A Trust Frameworkis developed by a community whose members have similar goals and perspectives. It defines therights and responsibilities of that community’s participants in the Identity Ecosystem; specifies the policies and standards specific to the community; and defines the community-specific processes and procedures that provide assurance. . . . In order to be a part of the Identity Ecosystem, all trust frameworks must still meet the baseline standards established by the Identity Ecosystem Framework.

6. But In All Cases, the Goal Is . . . • Building an identity system that actually works • E.g., the plane actually flies • Building an identity system that participants trust – i.e., are willing to participate in and rely on • E.g., we are all willing to fly on the plane – we’re confident that it will get us there safely, comfortably, on-time, etc. • For both of these goals, we need to address all of the relevant risks in an acceptable manner

7. All Trust Frameworks Consists of Two Parts Technical and Operational Specifications Content Technical specifications, process standards, policies, procedures, performance rules and requirements, assessment criteria, etc. Goals Make it work Make it trustworthy Legal Rules Content Existing law Contractual obligations Goals Regulate Technical and Operational Specifications Make Technical and Operational Specifications legally binding on the participants Define and govern the legal rights and responsibilities of the participants 7

8. Note How the Operational Specs and Legal Rules Relate • The Technical and Operational Specifications are designed to “make it work” from a functional perspective • The Legal Rules – • Regulate the content and implementation of the Technical and Operational Specifications, • Make the Technical and Operational Specifications enforceable, and • Address rights and obligations of the parties • But note that: • Some legal rules come from existing law • Other legal rules are made up by the parties

9. As An Analogy --Consider a Construction Contract • There will be many requirements and specifications • Blueprints • Electrical specification • Plumbing specifications • HVAC specifications • The specifications reflect much personal choice, but are also subject to regulation by existing law • The specs are attached to a contract whereby – • The builder agrees to build the building in accordance with the specifications, and the buyer agrees to pay for it • Both parties agree to numerous rules regarding price, schedule, warranties, limits on liability, insurance, applicable law, remedies for breach by the other, etc. • Existing law supplies legal rules not covered in contract

10. ABA Proposed Definition of Identity Trust Framework A Trust Framework is the governance structure for a specific identity system consisting of: • the Technical andOperational Specifications that have been developed – • to define requirements for the proper operation of the identity system (i.e., so that it works), • to define the roles and operational responsibilities of participants, and • to provide adequate assurance regarding the accuracy, integrity, privacy and security of its processes and data (i.e., so that it is trustworthy); and • the Legal Rules that govern the identity system and that -- • regulate the content of the Technical and Operational Specifications, • make the Technical and Operational Specifications legally binding on and enforceable against the participants, and • define and govern the legal rights, responsibilities, and liabilities of the participants of the identity system.

11. Note that . . . • The Trust Framework is NOT LIMITED to the rules and requirements the participants agree upon • A Trust Framework is a COMBINATION of – • The rules and requirements that the participants (or trust framework provider) write down and agree to, AND • Existing law • We have to consider the impact of both • Both need to work in harmony

12. Technical and Operational Specifications: Components Necessary to “Make it Work” Partial listing of Technical and Operational Specifications Identity Proofing TechnicalSpecifications Credential Issuance Privacy Standards Security Standards Authentication Requirements Audit & Assessment Oversight RelianceRules Enrolment Credential Management 12

13. Technical and Operational Specifications:Regulated by Existing Law Identity Proofing TechnicalSpecifications Credential Issuance Privacy Standards Existing Law Security Standards Authentication Requirements Audit & Assessment Oversight Reliance Rules Enrolment Credential Management Partial listing of Technical and Operational Specifications NOTE: Must comply with any existing law; Also supplemented by existing law 13

14. Legal RulesTo Govern Legal Rights of the Parties Existing Law as Supplemented and/or Modified by Contract Partial listing of Legal Rules Warranties Liability for Losses Existing Law Dispute Resolution Termination Rights Measure of Damages Enforcement Mechanisms 14

15. The Legal Rules Are a Combination of . . . Public Law (statutes, regulations, common law) – Existing IdM-specific law, if any Existing generally applicable law Privacy law, warranty law, tort law (negligence), e-transaction law, defamation law, etc. Supplanted / Revised by Private Law (created via) – Contractual agreements among the parties Standards adopted by the parties Self-asserted undertakings

16. Identity Trust Framework:Putting It All Together Identity Proofing Technical Specifications Warranties Liability for Losses Credential Issuance Privacy Standards Existing Law Existing Law Dispute Resolution Security Standards Termination Rights Authentication Requirements Audit & Assessment Oversight Measure of Damages Reliance Rules Enforcement Mechanisms Enrolment Credential Management Technical and Operational Specifications Enforcement Element Contract: “I Agree” to . . . Legal Rules 16

17. Common Legal Problems to Be Addressed By a Trust Framework • Legal Uncertainty • (i) Lack of legal rules and (ii) lack of clarity re applicable legal rules • Liability Risk / Liability Allocation • Uncertainty over potential liability is a key issue! • Legal Compliance • E.g., privacy law requirements; security law requirements, etc. • Legal Barriers • Some laws may adversely impact Identity systems; • Can they be altered by agreement? • Contract Enforceability • How can we bind all participants (and affected non-parties) in an enforceable Trust Framework? • Cross-Jurisdiction Issues • Regulatory law in one jurisdiction may differ from another

18. Status of Industry Work to Date (1):Limited to Operational Specifications • Technical and Operational Specifications • Much work being done by many groups and governments • Groups: Kantara Initiative, Open Identity Foundation, EURIM, STORK, OIX, WS-Federation, etc. • Governmental: Australia, Belgium, Finland, EU, Germany, India, Scotland, Sweden, U.S., etc. • Intergovernmental: ITU, OECD, etc. • Legal Rules • Largely unaddressed! • Some private (closed) identity systems such as IdenTrust, SAFE-BioPharma, CertiPath, etc. • Some groups, such as OIX and American Bar Association Identity Management Legal Task Force

19. Status of Industry Work to Date (2): Most Existing Docs Are Just Components • Most existing work focuses only on a subset of the of Technical and Operational Specifications, and thus are only components of an Identity Trust Framework, such as: • NIST SP 800-63, Electronic Authentication Guideline • Kantara Privacy Framework (being developed??) • FICAM Security Assertion Markup Language (SAML) 2.0 Profile • NASPO National Identity Proofing and Verification Standards • Entity Authentication Assurance Framework, ISO/IEC 29115:2010 (draft) • Kantara Identity Assurance Framework: Assurance Assessment • FIPS 201, Personal Identity Verification • Examples of complete Trust Frameworks might include SAFE-BioPharma, CertiPath, and IdenTrust

20. A Few Thoughts on Addressing Liability Via a Trust Framework

21. Three-Part Concern • Risk of loss – risk of incurring one’s own losses (that cannot be shifted to someone else) • Risk of liability – risk of being held responsible for losses of others • Risk of non-compliance – risk of fines or other penalties for regulatory non-compliance

22. Basic Rule re Liability • When a party suffers a loss or damage – • That party must bear its own losses • UNLESS there is a basis for shifting the loss from the person that suffered it to someone else • Approaches often used to shift responsibility for losses – • Fault-based approaches • Intentional act or omission of 3rd party caused the loss • Negligent act or omission of 3rd party caused the loss • Strict liability approaches • 3rd party did not cause loss, but still held responsible for the loss based on policy reasons

23. The Default Rule Is Key Starting Point • Sources of approaches often used to shift responsibility for losses -- • Existing law • Contract • We need to know the rule under existing law, and then we can determine whether/how to modify it by contract • But we can’t address the issue unless we know the source of the duty – e.g., warranty, antitrust, tort, contract, duty to authenticate, etc.

24. Consider an Example . . . • Assume an Identity Assertion is inaccurate and a Relying Party and/or Subject suffers a loss • If negligence law applies – • Liability depends on fault of IdP • Relative to the standard that applies (by law) • Depends on nature of loss, the jurisdiction involved, etc. • If warranty law applies – • Liability does NOT depend on fault of IdP • Depends on nature of warranty that applies (by contract or law) • If both apply???

25. Some Potential Liability Models • Warranty model – focus on stated or implied guarantees • Tort model – focus on standards of conduct; negligence • DMV model – no IdP liability; other roles bear all risk • Credit card model – no Subject liability; others bear risk • Contractual model – negotiated risk allocation (in theory) • Strict liability – regardless of fault • Liability caps model • EV SSL model – restricts ability of IdP to limit its liability • But recognize that -- • Liability model unlikely to be a one-size fits all approach • Liability is a zero-sum game

26. The Overall Trust Framework Goal • Develop an acceptable Trust Framework that – • Provides enforceable rules for a workable and trustworthy identity ecosystem that are binding on all participants • Adequately protects the rights of the parties • Fairly allocates risk and responsibilities among the parties • Provides legal certainty and predictability to the participants • Complies with / works in conjunction with existing law • Works cross-border (state or country)

27. The Next Steps • Agree on a general Trust Framework definition • Identify the topics to be addressed for the Technical Operational Specifications and Legal Rules

28. Further Information Thomas J. Smedinghoff Wildman, Harrold, Allen & Dixon LLP 225 West Wacker Drive Chicago, Illinois 60606 312-201-2021 smedinghoff@wildman.com