Identity Use Case Background

More background resources and examples will be provided here shortly.  In addition, a template for describing Use Cases and relevant scenarios from a business and legal perspective will be developed for this activity.  The business and legal Use Cases will correlate to the Technical Use Cases related to Federated Identity Management.

According to this (archived) Wikipedia page, a “Business Use Case” is intentionally “technology-free”, and focuses upon the parties, their business processes and goals.  Here is an excerpt, including a distinction between a business and system use case:

Business vs. System Use Cases

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

  • A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description.
  • A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, “create voucher”) and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor’s actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined.

Generally, for the Use Cases needed to ground the ABA Task Force report, it is recommended to define three dimensions (or layers) for each scenario: Business, Legal and Technical.  The Business Use Cases will focus on Roles and Relationships and Transactions between and among them,  noting the applicable business or other context.  The Legal Use Cases will focus on the Rights and Responsibilities of the parties.  The Technical Use Case will focus on the Actors and Actions and the technology used to effectuate the interactions between the actors and within one or more Systems.  As with the fundamental rule of relevance in evidence (that one must first know “relevant to WHAT”) so too with an identity use case, we will define the vantage point.

Ideally, there will be a relatively few use cases to start, and they will illustrate several points on a spectrum that are especially relevant for purposes of the legal analysis.  Choosing on the business access more than one industry and type of transaction, choosing on the legal access more than one type of duty and party, and choosing on the technology axis more than one type of action (e.g. from an enterprise SAML cross-directory implementation to an individual user of OpenID, etc).  Using these three dimensions of Business, Legal and Technical, our use cases will provide an adequate basis for applying the law to fact and generating an analysis.

Eve Maler has made an important contribution to the task of clustering scenarios of usage with her “Ven of Identity” perspective and analysis.  The following illustrations describe her vantage point:

Cite: http://www.flickr.com/photos/dullhunk/3953605716/

Cite: http://identity-centric-architecture.blogspot.com/2007_04_01_archive.html#2770762844023362750

One important implication of the above ven perspectives is that there are more open and more closed environments.  The SAML environments are quick tightly closed, with complex and comprehensive agreements among parties at the business, legal and technical levels.  By contrasts, the OpenID environments are frequently much more open, but open in this case does not mean that no contract exists.  A click-through or similar contract wrapper is usually in place, but there may not be a pre-existing relationship between the parties and no other business or commercial contract.  Eve’s current thinking on access control is also worth understanding, and is described on her blog.

As a follow on task to development of the primary use cases, there are “Federated Identity Mock Trials” currently being developed in association with MIT and it could be interesting to use one or more of the defined use cases from this Report as the basis to develop a full “Fact Pattern” upon which a hypothetical case can be adjudicated.  More on that later.