Identity Design Patterns

Introduction

There has been some discussion about the level abstraction for use cases in the IDESG. Early on and as a way of getting started the Use Case Ad Hoc Group (USAHG) decided that implementation details would not be included in the first level of use case description. Whether or not this is the right approach is still under discussion. One description of the levels of abstraction of the IDESG functions has been proposed in the Functional Requirements. (ARR:?After some discussion it seems appropriate that use cases would be helpful at both top levels.? I don't know what this means.) Most of the existing use cases are oriented to the {ARR: what is meant by "Category"? What are the other categories}category of user scenarios. This page describes the use cases at the identity ecosystem level in the terms of design patterns. While other terminology could be more appropriate, the split between design patterns and user scenarios seemed helpful at this stage.

The rationale for the use of patterns as the building blocks for the identity ecosystem was made nicely by Ray Kurzweil who describes himself as a "patternist, someone who views the patterns of information as the fundamental reality. For example the particles composing my brain and body change in a matter of weeks, but there is a continuity to the pattern that these particles make." So with the patterns of the id ecosystem. It is expected that the patterns will survive for multiple implementations. But all patterns will become inadequate to the job at some time in the future and will need to be replaced.

Levels of Abstraction of Use Cases

• Identity Ecosystem where use cases will look like design patterns that can be used across all frameworks.
• Identity Framework where use cases will look like scenarios that describe the user experience and process steps from the user's perspective within that framework.

Pattern Language

A design pattern is best described in a pattern language. [[1]] The pattern language starts with a pictorial view and statement of the problem to be solved, the context in which the pattern must work and explains how the pattern helps within the overall identity ecosystem. Each pattern describes a problem which occurs widely across multiple identity frameworks. The pattern is presented in terms of a solution to a part of the problem. When facing a problem the identity architect should be able to decompose it into a collections of patterns that have solutions proposed. It is expected that each designer can start with a collection of identity patterns and create software solutions that are unique to their own environment. The language described below is the way that the pattern is built for the IDESG Wiki. The pattern starts with a picture or diagram showing a paradigm of the pattern followed by a description in the form of "meme" or simple idea that will help the architect to select the most appropriate patterns to use. The context section defines the larger architecture where the pattern is known to apply.

Some Features of a Pattern Language

• No pattern is an isolated entity. Each must exist within the ID ecosystem taken as a whole.
• No pattern is a complete solution in itself and must be combined with other patterns to create an organic architecture which is responsive to user needs.
• Identity patterns for early deployments of IDESG solutions need to meet the needs of users who deal daily with web solutions that are not IDESG compliant.

What these Patterns are NOT

These patterns are not meant to provide mechanized processes as are described in the Use Cases. Those are full end-to-end scenarios that describe the functional processes that occur to support that scenario. The design patterns should not be designed to be stand-alone solutions, not a reductionist set of modules that can be plugged together to make a working product. These patterns need to be assembled into a collection of patterns that are used to program a solution that will appear alive to the user; a solution that will live in the internet and provide a holistic experience that users will enjoy, or at least appreciate, for its ability to perform a function efficiently and transparently for each user that comes, whatever expertise using computers that they might bring with them.

The implication of this is that no general purpose web site can, or should, know enough about a user to be able to understand the technical competencies of the user. The privacy implications of any general web sites knowing so much about a user's competencies are too great to expect that solution to work for an IDESG compliant ID framework. The inescapable conclusion is that these design patterns will need to create solutions that are run by and for the benefit of the user, not by and for the benefit of the web site. The challenge will be to find a way to fund solutions to problems that user's have come to expect for free on existing web sites.

Building a Design Pattern

Definition of Design Patterns

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in different situations. Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. Object-oriented design patterns typically show relationships and interactions among objects or entities, without specifying the final application objects that are involved. For in Identity Ecosystem the objects are the roles and the interconnections happen over the internet.

Identity design patterns are created as part of the domain of roles or entities and interconnections. At a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by the entire identity ecosystem.

The Gang of Four (see references) claim the following as advantages of interfaces over implementation:

• entities remain unaware of the specific types of roles they use, as long as the role adheres to the interface specification
• entities remain unaware of the classes that implement these roles; clients only know about the abstract classes defining the interface
• Delegation is an extreme form of role composition that can always be used to replace inheritance. Delegation involves two roles: a 'sender' passes itself to a 'delegate' to let the delegate refer to the sender.

Most of this information is adapted from Wikipedia Software design pattern[[2]].

Pattern Life Cycle

Any ecosystem is built up of organic parts that are born, grow into adults and die. For any organic part to succeed in the ecosystem, it must be able to function during its entire life-cycle. To create successful parts, the designer needs to consider how each part will act organically from its first creation until it is no longer needed. "An acorn transforms smoothly into an oak, although the start and endpoint are radically different." ISBN 0-9726529-2-2 So must a design patter work from today into an ID ecosystem that we fully expect to change over time. Pressures build up within any ecosystem for change rapidly requiring professionals from that ecosystem to adapt to the changes. Especially as the new ecosystem is rolled out, new requirements will be uncovered and new regulations are enacted. Several software design lifecycle systems have been proposed and shown to work well. The key is to get the pattern published quickly and then get rid of it as it is superseded by new patterns that are better suited to the current state of the ecosystem. The following is one example of such a lifecycle:

1. Clearly state the problem to be solved. This is where the real leaders can be judged. If the problem is poorly stated, the design will be suboptimal.
2. Quickly collect all the research needed to understand the current context consisting of: new regulations, standards, customer expectations.
3. Orient the design team to the current context.
4. Design with whatever knowledge and context can be collected including consideration of the community of users, their privacy and safety.
5. Produce some early implementations. These can be pilot implementations where the pattern is new and usability testing is indicated.
6. Distribute the pattern widely, promote its use with implementation guidance.
7. Utilize the implementation in the field and collect feedback on user's experiences.
8. Cycle back to step 2 so long as the pattern shows utility.
9. Eliminate the old patterns as new patterns are shown to be better suited to new realities.

List of potential (and actual where a link is provided) design patterns

>>IT HAS BEEN DETERMINED THAT THIS SECTION SHOULD BE PARTITIONED INTO GROUPS BY LEVEL OF COMPLEXITY<<

>>An initial comparison of this list with the evolving functional interaction model has resulted in the prioritizations shown below<<

This is a list of patterns ordered from the most general to the more specific.

• Common to any Internet Identity Ecosystem is a base level pattern that is inherited by all of the following patterns.
• Privacy Enhancing Technologies is an existing use case that shows that interaction of blinding operations on the three core types of entities.
• Registering with an Identity or Attribute Provider that has an IDESG Trustmark. (security committee priority 1)
• Registering a Simple Cryptographic Authentication Token that is not involved in device authentication. (security priority 3)
• Registering a Cryptographic Authentication Device that does provide device authentication. (security priority 3)
• Registering a Biometric Authentication Factor
• Generalized Presumptive Authentication
• Generalized in-line Authentication (security priority 2)
• Two factor Authentication with a Credential on a Token using offline devices such as smart cards.
• Multiple Factor Progressive Authentication with a Mobile Phone or other portable internet connected device. (security priority 4)
• Trustmark Evolving Pattern shows how users should be able to interact with Relying parties using IDESG frameworks as they evolve over time.
• Back-out or cancel a decision made by the user, including the choice of a governing Trustmark.
• User Intent Pattern describes the ways for a user to interact with policies like DO NOT TRACK.
• User Choice Pattern describes the way a user can pick which attributes to release to a relying party.
• User Personalization Pattern enables each user to make their experience fit their own capabilities and desires.
• Attribute Exchange Design Patterns in the "Backend Attribute Exchange (BAE) v2.0 Overview" [[3]]

References

• Christopher Alexander, et al. "A Pattern Language", Oxford 1977 ISBN 0-19-501919-9
• Functional Requirements where the layers of abstraction of the IDESG are laid out.
• Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of four ISBN 978-0201633610 (n.b. This now 10 year old book is due for an update soon.)
• Eric Evans "Domain-Driven Design" Addison-Wesley 2004 ISBN 0-321-12521-5
• Community and Privacy Pattern Language is an IDESG web page that outlines the source and components of pattern languages.
• Ray Kurzweil "The Singularity is Near" Viking 2006 ISBN 0-670-03384-7