wildman harrold

Wildman Harrold | 225 West Wacker Drive | Chicago, IL 60606 | (312) 201-2000 | wildman.com

Wildman, Harrold, Allen & Dixon LLP

What Is an Identity Trust Framework?

Addressing the Legal and Structural Challenges

Thomas J. SmedinghoffWildman, Harrold, Allen & Dixon LLP

Chicago

Chair, ABA Identity Management Legal Task Force

Wildman, Harrold, Allen & Dixon LLP.

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


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 . . .

Wildman, Harrold, Allen & Dixon LLP. 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 requirements and enforcement mechanisms for parties exchanging identity information


Much Disagreement Re What a Trust Framework Is

• NSTIC 4/15/2011 Final:

• The Identity Ecosystem Framework is the overarching set of interoperability standards, risk models, privacy and liability policies, requirements, and accountability mechanisms that structure the Identity Ecosystem.

• A Trust Framework is developed by a community whose members have similar goals and perspectives. It defines the rights 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.


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


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


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


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


ABA Proposed Definition of Identity Trust Framework

A Trust Framework is the governance structure for a specific identity system consisting of:

• the Technical and Operational 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.


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


Technical and Operational Specifications: Components Necessary to “Make it Work”

Partial listing of Technical and Operational Specifications

PrivacyStandards

CredentialIssuance

AuthenticationRequirements

Reliance Rules

Audit &Assessment

Oversight

Credential Management

SecurityStandards

IdentityProofing

Technical Specifications

Enrolment


Technical and Operational Specifications:Regulated by Existing Law

Partial listing of Technical and Operational Specifications

NOTE: Must comply with any existing law;

Also supplemented by existing lawEx

istin

g La

wPrivacy

StandardsCredentialIssuance


Reliance Rules

Audit &Assessment

Oversight


SecurityStandards

IdentityProofing


Enrolment


Legal RulesTo Govern Legal Rights of the Parties

Existing Law as Supplemented and/or Modified by Contract

Exis

ting

Law

Warranties

Dispute Resolution

Measure of DamagesEnforcement

Mechanisms

Termination Rights

Liability for Losses

Partial listing of Legal Rules


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


Identity Trust Framework:Putting It All Together

Contract:“I Agree” to . . .

Exis

ting

Law

Warranties

Dispute Resolution

Measure of DamagesEnforcement

Mechanisms

Termination Rights

Liability for Losses

Exis

ting

Law

PrivacyStandards

CredentialIssuance


Reliance Rules

Audit &Assessment

Oversight


SecurityStandards

IdentityProofing


Enrolment

Technical and Operational Specifications

Legal Rules

Enforcement Element


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


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


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


A Few Thoughts on Addressing Liability

Via a Trust Framework


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


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


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.


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???


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


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)


The Next Steps

• Agree on a general Trust Framework definition

• Identify the topics to be addressed for the Technical Operational Specifications and Legal Rules


Further Information

Thomas J. SmedinghoffWildman, Harrold, Allen & Dixon LLP

225 West Wacker DriveChicago, Illinois 60606

[email protected]

wildman harrold | 225 west wacker drive | chicago, il 60606 | (312) 201-2000 | wildman.com wildman,...

Documents

identity trust framework

identity ecosystem framework

identity information

specific identity system

legal requirements

identity information

digital identity credential