Identity Use Cases

Draft for Comment;  Version 0.3; April 25, 2012.  Please share your feedback.

Preface: This work is a work in progress update of the content at:, to be published under permissive creative commons. It is hoped that it may be usable in some form as a constructive input, in whole or in part, or perhaps only in concept, for the work of the ABA Task Force on Federated Identity.  It is also clear that some of the use cases and approach will be constrictive inputs to standards groups, academic efforts and other initiatives, and for that reason, the approach of publication under permissive creative commons, with any necessary grants for use, is being followed.  Use of the site is intended solely as am initial place-holder, with the intention of transitioning the authoritative page to a stable and credible URL at a domain such at or the or perhaps a standards group or a .gov, for further iteration over time.

Attribution: Upon receiving permission to print their names and/or affliliations, attribution to collaborators will be included here. The method of approaching networked systems analysis at the business, legal and technical distinct dimensions was developed at the eCitizen Architecture Program at MIT in 2007, and has since been used by the World Economic Forum’s Tiger Team on Privacy and Security, the OIX Attribute Exchange work group, and the eCitizen Foundation, among others.  It was Scott David, of K&L Gates who had the brilliant suggestion to order the words as business/legal/technical so that the acronym BLT, being both memorable and also connoting the concept of a whole being more than the sum of it’s parts (and a lot tastier).

PART I: Introduction and Overview:

One of the most confusing aspects of federated and claims based identity systems from a legal perspective is that there are actually several materially different types of systems and furthermore, several different underlying contexts of use that change the legal analysis and outcomes.  This website provides a business, legal and technical methodology for making the material distinctions needed to enumerating and define multiple use cases and apply appropriate legal analysis based on relevant context.

The concept of defining use cases to describe the salient aspects of a system is widely adopted. Typically, a use case will reference who is doing what.  This can be accomplished by identifying all “actors and actions” that can be accomplished within a given system.  At this point, a technologist can design and build a system that can, in theory, be tested against the use cases to determine whether the final implementation does or does not accomplish each such use case.  This is an aspect of “traceability of requirements”.

The notion of applying the method of defining use cases to the business dimensions of a system, rather than more strictly to the technical dimension, is also widely adopted.  When a business use case is being defined, the focus is on the business roles of the actors, such as “customer” or “sales agent”, and the type of transactions they are conducting, such as “purchase goods” or “lodge a complaint”.  Ideally, the business use case does not suppose any particular technology or implementation, however sometimes the lines between business and technical dimensions blur when the interactions are deeply enmeshed in particular technologies.

Another application of use cases is to the legal and regulatory dimension of the interactions within a system.  This is especially important when modeling federated identity interactions, because those who would build, use or rely upon such systems seek to understand their rights and obligations.  The uncertainty around the legal overlay for federated identity is problematic for adoption.  In order to clarify the legal dimension, however, it is necessary to better define the underlying factual basis upon which the law is to be applied.  The most significant value achieved by defining federated identity use cases at the legal and business dimensions is derived from the exercise of noting the relevant comparisons and contrasts between different applicable use cases.  Noting the comparisons and contrasts enables a reasoned enumeration of each category and type of use case, and allows for actionable strategies for addressing the different factors for each cluster of cases.

The above diagram depicts how the business, legal and technical dimensions of a system can be described and aligned.  When this approach is applied to writing System Rules for an identity federation or other transactional community, a document with business rules, legal rules and technical rules, can be aligned together using the same roles, processes and contexts.  An example of such a document is the ID Federation Trust Framework System Rules.  When the business, legal, technical method is used for eliciting requirements and establishing use cases to scope a software development project, it can provide a more complete and holistic description of the salient facets of the system being designed.  When this business, legal, technical method is used for system rules, it is also possible to literally integrate some of the rules together, by codification in a unified method, as depicted in the video demo below:

Some dialogs related to legal analysis of federated and claims based identity can be confusing because it appears some participants have one scenario in mind, while others have a different scenario, and from there, misunderstandings, argument or just dumbfounded confusion can ensue.

For example, some people when discussing federated and claims based identity systems have in mind the situation of a user logging into a website, application or other service using a mass-market identity such as a Twitter, Linked-In or Yahoo log-in.  There is, to be sure, much exciting and important activity around this use case, and it carries with it several relevant assumptions about the legal relationships of the parties, the types of transactions that are occurring, the connections between the identity providers and relying parties, and many other factors.  By contrast, other people are very focused upon public sector identity schemes such as use of a government issued card or an “eID”.  Again, this is a very important re-usable identity context, complete with many highly secure, carefully thought out and widely deployed solutions.  Still other people have in mind the traditional private sector workplace “Single-Sign-On” type system, whereby an employee can access many different networks and systems and applications using their username and password or just based on an active session at their desktop or virtual private network connection.  A variant of workplace SSO, taking it to the next level, is federation across many workplaces either from the bottom-up based system by system, or based on a broader consortium or “industry trust framework” such as SAFE, Indentrust, InCommon, or the ID Federation, Inc.

In the case of the Workplace SSO scenario, while there are several different use cases that fit in that general category, the legal context has many particular and very salient features.  For starters, the “user” is an employee of an organization that is making the service available as a part of that person’s scope of work.  An employment or contractor agreement will apply, and will cover many of the questions of liability, rights and other responsibilities.  The entire body of agency law can be applied to fill in gaps and establish a basis for predictable legal outcomes.

Where a Workplace SSO scenario exists within a broader industry transactional consortium or federation, there will likely be a multi-party agreement, such as operating rules, a joint venture agreement, a trust framework agreement, etc.  These multi-party agreements will frequently include very specific terms defining the legal outcomes in many situations, as well as lines of responsibility, allocation of risk, precise role definitions and other relevant factors.  The rules of these multi-party agreements can and do differ from one consortia or federation to the next, meaning that an otherwise identical seeming Workplace SSO use case will in practice have different legal outcomes based on the applicable terms of the agreements each organization has entered within that community.  Nonetheless, it is still a very useful exercise to clarify the general legal basis of the different use case types, providing a basis to understand the impact of contractual terms.

PART II: Use Cases

USE CASE #1: Workplace SSO, “Tightly Bounded Circle of Trust”

Diagrammatic Summary of Common Example for Use Case #1:

Note that in the diagrams above, the ovals represent the interaction, with top oval relating to the identity federation and the bottom oval relating to the underlying context for the Use Case.  [Draft note: these are VERY rough place holders.]

Textual Summary for Use Case #1:

The business scope extends to multiple companies that have opted into an agreement for the purpose of increasing efficiency usability and security by enabling employees re-use their workplace log-in to access the applications or services of other companies in the “circle of trust”.  The business roles include 1) Policy Authority, which is the body responsible for promulgating the applicable rules governing participation in the “circle of trust”, 2) Users, who are the people, such as employees or contractors, that are using the identity system to access the applications or services of companies in the “circle of trust”, 3) User Authorities, which is responsible for identifying participating individual users, such as employees or contractors of a company participating in the “circle of trust”, 4) Relying Parties, which are the companies that accept the log-in and other identity information of users to access applications or services, 5) System Operator, which is one or more companies that operate and manage certain shared or central repositories, business functions or other services used by participants in the “circle of trust” and 6) and Identity Provider, which may be the User Authority directly on behalf of it’s own Users, or may be a third party such as a vendor with a federated identity service, that manages the identity assertions on behalf of the User Authority and Relying Party (note that in this context, the IdP is not creating a trust relationship between the parties, because the parties already exist in a business context from which their trust emerges, and the IdP merely expedites the method of access).

The transactions supported directly by the identity system include 1) transmitting a secure assertion of the identity of a user to enable single-sign on, 2) possibly transmitting additional attributes related to a user, such as authorization privileges, 3) possibly maintaining a meta-data repository including interoperability and related information for participating companies in the “circle of trust”.  The transactions supported indirectly by the identity system may include 1) use of a collaborative work system, such as a CMS, Wiki or file server, 2) use of a shared service, such as directory services of the Relying Party company, 3) access to project management applications, 4) potentially access to a wide range of other applications, including financial management, intellectual property, human resources, marketing or any other application or service the Relying Party company chooses to open for access by authorized users of other participating companies via the federated identity system.

Legal parties in this use case would include the specific companies that participate in the “circle of trust”, but is limited to companies that fit the business scope and purpose agreed for the circle of trust.  Contracts to participate in the circle of trust include 1) a participation agreement of some kind that, most notably, ties each individual party to one or more roles, and therefore an interlocking set of rights and responsibilities, 2) a set of “System Rules”, sometimes called “Operating Rules”, “Federation Rules”, “Trading Partner Agreements” or “Network Rues”, among other names, and that define key aspects of the identity system.  Other contracts may include pre-existing commercial contracts in place between the companies whereby they have agreed to engage in the underlying transactions that are facilitated by use of the federated identity system.  For example, a supply chain management system may have a Trading Partner Agreement setting forth the basic rights and duties of all the parties, and a later addition of a federated identity system would likely either be an addenda or would be subject to the terms of the commercial contract that creates and governs the business relationship of the parties.  For a clear example of how existing commercial contracts are treated, see the (in which insurance and financial services companies that do business with each other have added a federated identity system with trust framework system rules, but explicitly acknowledge that their underlying business contracts will take precedence over any inconsistent terms of their system rules, participation agreements or other documents related to the identity system.  This is one key way in which the business to business federated identity use cases may differ from mass-market consumer identity or public sector issued identity system.

The key technical standards expected for this use case are SAML and/or WS-Federation.  The technology likely include enterprise federated identity platforms sold by major vendors, that implement the standard and have various administrative, management and interoperability features. The actors and actions would include 1) A User who logs into 2) the application or service of  Relying Party by 3) Authenticating themselves using their home company log-in regime while 4) the IdP (whether that is the User Authority or separate outsourced vendor) manages the hand shake and token transfers necessary to asset the user’s identity and ensure an authenticated session for the Relying Party. (There is a lot more to this, but for purposes of this summary, these are the salient points.)

Detailed Analysis of Use Case #1

Business Roles and Value Transactions:

[Drafting Note: In version 0.4, this title and corresponding the section headers are planned to be updated to: “Business Context: Scope/Purpose, Roles/Relationships and Transactions”.  The thinking being that the Scope/Purpose defines the essential boundary conditions and intention for the identity system, framing the highest level aspects of the applicable context.  The business drivers, rather than legal or technical drivers, are the source point for this context and the decision makers for this are exercising executive business domain prerogatives.  The “Roles/Relationships” and “Transactions” flow from the scope and purpose.  By touching on these essential elements, the relevant features of the business dimension can be quickly established.]

The business roles in Use Case 1 include the a) Policy Authority, who is responsible for providing the identity system and the rules that apply to it’s use, b) the System Operator, who is responsible for managing the identity system, and may be the same or different from the Policy Authority, c) the User, who is the person identified by and using the identity in the system to identify and authenticate themselves to a network, application or service, d) the User Authority, who is responsible for identifying the User as an authorized member of an organization allowed to participate in the identity system, e) the Relying Party, who owns the network, application or service that accepts the federated or claims based identity of the Use.  Other common roles include a “Transaction Processor”, that may provide routing or other intermediary services, “Certification Providers” which may include an assessor such as an auditor, who has been accredited by the Policy Authority or System Operator to provide certification of compliance with applicable rules and requirements, and many others. The role of an “Attribute Provider” is also under active consideration, and while these general functions are currently handled in very non-standard ways, a more common approach and detailed use cases are currently being developed in a methodical manner by the Open Identity Exchange workgroup on attribute exchange.

The Transactions for Use Case 1 are varied, including:

A) An Employee signing into their own workplace network and personal applications suite, such as e-mail, calendar and file storage, as well as “shared services” such as directory lookup, human resource applications, and many others.  This federated or claims based identification and authentication for access to applications and services may span many different but connected subsidiary, parent or otherwise connected corporate networks and cross both regulatory fields (where for instance some applications must comply with the rules of HIPAA, other with GLB and many others regulations) and various state and national jurisdictions.

B) An Employee signing into a (consortia example)

C) Re-Use into Other Use Cases (beyond the rules of that consortia).

Legal Parties and Decision Processes

[Drafting Note: In version 0.4, this title and corresponding the section headers are planned to be updated to: “Legal Context: Parties/Contracts, Rights/Responsibilities & Decisions”.  The thinking being that the Parties and their Contracts, are essential to the legal context, especially given that federated and claims based systems are essentially voluntary, agreement-based interactions arising from private arrangement.   The Rights and Responsibilities, while not meant to be exhaustive at the Use Case level of abstraction, none-the-less is intended to provide a roster of the high level key duties and prerogatives or privileges of the parties, and thereby provide a basic context for the Use Case.  By establishing the essentials of the Business Context, it is possible to predict many important elements of the applicable rights and responsibilities, and it is critical to note that rights and responsibilities in fact shift in profound ways based solely upon the contours and context of the Business Use Case.   Finally, the “Decisions” header is intended to describe the applicable decision making for key aspects of the Use Case, including most importantly dispute resolution decisions.]

The legal parties in Use Case 1 can be postulated to include:

A)    The Employer:

B)   The Employee: (to be completed)

C)   The Partner Company: This may

D)   The Government as Regulator

E)   Outsourced IT Provider

F)    The Federation or Consortium

The Decision Processes for Use Case 1 are at once simple and complex, in that clearly for a workplace system in the first instance the employer can be expected to be “the decider”, but depending upon the type of decision or applicable context, there may be significantly greater variation.

[Drafting Note: There are important legal issues between subsidiaries, parents and divisions that require careful analysis.  This will focus, however, upon the situations where the identity is traveling across the boundary of one legal entity (even very broadly construed to include a sprawling global network of companies) to completely separate, arms-length external organizations.  This is the “Supply Chain” or “Marketplace” or “Clearinghouse” or “Collaborative” type of scenario, and avoids the unknowable questions of how governance and control may be distributed within the sub-entities of a large-scale conglomerate.  This distinction will be complete further.]

A) Decision making regarding change management: (To be completed)

B) Decision making regarding resolution of disputes:

There are two basic categories of disputes in the federated or claims based identity context: between transacting parties and between a transacting party and the system provider.

i) When transacting parties have a dispute related to the use or reliance upon the identity, who is empowered to adjudicate that dispute and what criteria will apply?  This typically is addressed within the consortia or federation agreement suite, and involves wither the Policy Authority or System Operator when the disputes are addressed internally, or defines an Alternative Dispute Resolution process such as the Commercial Arbitration Rules of the American Arbitration Association.

a) The types of disputes usually considered include: Mis-identification of a system user such that either a deliberate attacker has been fraudulently issued an Identity within the system or a valid system user has been somehow mis-identified as a different valid user; An attacker who has not been issued a valid Identity nonetheless breaks through the access control and other protections due to the Identity system failing in a material way on one or more of it’s agreed duties, and; Failure of the Identity system to effectively transmit, receive or otherwise process the identity assertions such that a valid user is unable to access the business system and can not conduct the relevant transactions.  There are many other types and gradations of postulated disputes as well.

b) The most important contextual factor in defining the legal dimension of an identity federation or claims based use case is whether the parties have an existing commercial contract covering the transactions or other interactions they are seeking to conduct by use of the identity system. It is common for legal analysis of identity systems of this type to assume the legal outcomes will depend primarily upon the public law or private contracts applicable directly to the identity system, such as the trust framework or an electronic signature statute or regulation pertaining to the use of online identity.  And yet, very frequently – perhaps in nearly every actual situation – the parties have a contract that directly covers the substance of their interaction and details the liability, caps on damages, indemnities and many other legal rights and obligations.

Where, for example, the federated or claims based identity system is used as part of a long-standing supply chain, or a collaborative system or communications network, there will frequently be one or more commercial contracts covering the purchase and sale and electronic transactions, which the identity system merely replaces a small aspect of the technology within the broader and well defined business, legal and technical arrangements of the parties.  The pre-existing commercial contracts may be completely conclusive, and this is especially true when an “order of precedence” or similar clause within the identity system agreements explicitly recognizes that the primacy of the basic business contracts.  For this reason, understanding the Business Roles and Value Transactions, which is the first dimension of this integrated Use Case approach, is critical to establishing not only what areas of law may apply but also whether there are well established customs or underlying contracts among the Parties.

ii)  When one or more transacting party has a dispute with the Policy Authority or System Operator, it is possible that still different decision making processes will apply.  If the other disputant is funding the identity system for use by their business and there is a service contract in place with the System Operator, for example, it is possible that contract will contain particular provisions defining who adjudicates and what rules apply to disputes between the vendor and the buyer of the system.  In many cases, the consortium or federation agreement also contain particular provisions addressing the resolution of disputes between members or participants and the providers (Policy Authority and/or System Operator) of the system.

iii)  In addition to the two types of disputes above involving parties within the identity system, of course there may also be disputes between third parties and a party within an Identity System [this scenario of third party disputes, including third party beneficiary, intellectual property, tort and criminal liability is to be completed.  The third party case is the weakest dispute vector from which to leverage a use case, because the use cases are based upon design thinking for an inclusive system.  However, defined use cases at the business, legal and technical levels can provide a very solid starting point from which to begin the additional fact gathering and legal analysis necessary to evaluate and discuss third party claims from outside the identity system.]  [In theory, a compliance action by a regulator on it’s own initiative would also qualify as a dispute with a third party not within the identity system.  This would not necessarily be the context when the government agency is acting within it’s capacity as identity system participant as opposed to regulator, in which case the rules of the consortia or federation agreement may apply, or in some cases the rules of the relevant government contract procuring the identity service.  This analysis remains to be completed.]

C) Decision making regarding acceptance or termination of membership: (to be completed)

D) Decision making regarding the meaning and reliability of the identity: (to be completed)

Technical Actors and System Actions

[Drafting Note: In version 0.4, this title and corresponding the section headers are planned to be updated to: “Technical Context: Standards/Technology, Actors/Actions and Security”.  The thinking being that the “Standards and Technology” will reveal much about where the possible failure points exist, as well as act as another source of obvious rights and obligations of the parties and functions of the roles.  It is important to note that there are many different ways to implement any one of the three Use Cases at the technical level, and some carry different legal and even business implications from others, including by requiring more or fewer direct parties to the interaction or defining types of information that must be exchanged or agreed in advance and sometimes defining sequences of actions that must occur.  The Actors and Actions are the core of a technical use case.  Security is added for version 0.3 because a technical facet of an integrated use case would be incomplete without reference to the type and method of security in play, and the security features can be highly relevant or even dispositive for legal analysis.]

Use Case #2: Public Sector Issued Identity Credentials and Token

a) Employee and Contractors Identity (HSPD#12/PIV/CAC)

b) Citizen Identities (eID)

(to be completed)

Diagrammatic Summary of Use Case #2 (To be completed)

Textual Summary of Use Case #2 (To be completed)

Business Roles and Value Transactions:

(to be completed)

Legal Parties and Decision Processes:

(to be completed)

Technical Actors and Actions:

(to be completed)

Use Case #3: Mass-Market Consumer “Lightly Bounded” Reusable Identity

a) OAuth and OpenID “in the wild” among partners with no prior relationship

b) Reusable Branded ID (e.g. Facebook, Google & Twitter)

(to be completed)

Diagrammatic Summary of Use Case #2 (To be completed)

Textual Summary of Use Case #2 (To be completed)

Business Roles and Value Transactions:

(to be completed)

Legal Parties and Decision Processes:

(to be completed)

Technical Actors and Actions:

(to be completed)


The following sections on a possible format for Fact Patters and Dispute Analysis Anchored in the Use Cases suggests potential methods for selecting a hand full of especially interesting or important scenarios to drill down.

The second section on potential inputs and outputs suggests various ways the Use Cases can serve as cross-community reference points, to facilitate “apples to apples” discussion and legal and policy work products related to federated identity systems.  By housing the Use Cases at a static and credible URL (e.g. something under, the, a standards group or even a .gov) it can be possible to a) enable any community to refer to the Use Case by it’s number and b) allow for a growing content of commentary and attempts at dispute analysis, suggested relevant materials and even possible guidance or practice tips to avoid or prevail in such disputes – notably this can be done simply be including the URL of the Use Case within the additional materials from any other organization’s website or social media, and does not require the host of the core Use Cases to literally update the site to include all commentary on it’s site.  This is because, assuming the commentary is not behind a firewall or password and is intended to be shared publicly, search engines will pick up the URL of the Use Case within the blog post, other html page or other web-content, and it can be filtered, sorted and curated as part of a broader base of knowledge.  It is also possible, of course, for the host to maintain and update the Use Cases and related pages to include new content, updated version of the Use Cases and totally new Use Cases as the field continues to unfold.

Finally, the below format of a) General Scenario, b) Relevant B/L/T Context and c) Dispute Overview is intended as a (very rough) starting point for elicitation of the relevant aspects of each fact patterns necessary to support a mock trial (one is planned to be held by MIT, and there are others that have been and will be held on the topic over time), and/or a common reference point for scholarly work by multiple and not necessarily related people or organizations.

1. Specific Fact Patterns For Each of the Three Use Cases:

The following is a (very) rough initial outline for a “benchmark” fact pattern, in which one of the initial 3 Use Cases (and/or a future Use Case to be added) is fully spelled out in a particular context, for purposes of performing a more complete legal analysis and assessment.

a. General Scenario: [E.g.: Joe, an employee of InterWidget, signs into her VPN and the logs into the order management system for SupraSystemix, a partner system, noticing a new interface that seems to enable ___.  She chooses to ____.  Later, she discovers that ____  and InterWidget is served notified that ___ by SupraSystemix.  As a result of Joe’s choice to ___, there was a ___.]

b. Relevant B/L/T Context: [In this section, the specific factors, described generally above, related to the business, legal and technical dimensions of the scenario, may be postulated in a fixed “fact pattern”.  What is sometimes called in the law  a “case and controversy” can therefore be defined in enough detail to apply the law to facts and derive outcomes.

i.     Business Roles and Value Transactions

ii.     Legal Parties and Decision Process

iii.     Technical Actors and Actions

c) Dispute Overview: [This section would provide a more concrete definition of the particular point in time from which the Use Case and dispute may be analyzed, based upon the substantive and procedural history to that point.]

i.     SupraSystemix filed a claim with the [Policy Authority? Arbitrator? District Court?]

ii.     InterWidget filed a motion for dismiss/summary judgment, claiming XYZ, which was rejected because the [adjudicator] held the claim had sufficient merit to proceed

iii.     Dispute Dynamics: Either write up or leverage the MIT Identity Mock Trials, to refine the key likely claims and counter-claims, defenses, and the types of evidence needed to support them, along with the desired application of the applicable postulated rules from the perspective of each disputant.

2. Potential Use Case and Fact Pattern Dispute Dynamics Outputs and Inputs

a) ABA Report: Based upon the Dispute Dynamics of several representative Use Case Based Scenarios (once refined and more broadly agreed), extract and extrapolate the relevant legal guidance for each of the sections of the ABA Federated Identity Task Force.

b) Standards, Policy and Professional Associations: Provide the Use Cases to groups such as OASIS, the W3C and the OpenGroup/Jericho Forum, as well as to other organizations and bodies establishing approaches to federated and claims based identity systems, to help inform and level-set a more common reference approach to the legal issues.  Ideally, by numbering each Use Case and associating a standard URL and home for it, such as at an or stable link, it will be possible to help advance and “apples to apples” dialog about the applicable context people mean when they seek to discuss and apply their work to “identity” systems, such that they can note which types of technical systems and more importantly, which business and legal contexts.

c) Academic Template: Based upon the Dispute Dynamics of several representative Use Case Based Scenarios, create practice-driven and theoretical educational materials, referencing the applicable Use Cases as common anchor-points to the ABA and other relevant work.