Identity and Technology
Identity and Technology
In this section we are trying to develop a model that can be used to characterize identity systems and technologies. The basic approach is to define a number of basic qualitative parameters and an (extensible) list of features that can be used to describe the capabilities of a given system.
This approach is not universal and there are many other ways to do this. For example, Kim Cameron formulated the "Seven Laws of Identity" that deal with user-centric aspects of identity.
Parameters of Identity
Identity is a very multi-faceted problem. Trying to squeeze the different aspects of digital identity alone in a small number of principles will invariably result in errors of omission and oversimplification. However, in order to be able to classify and address the issues with digital identity, it is useful to abstract from the complex problems associated with identity and introduce a few simple parameters that can help in classifying the various applications domains and aspects of identity systems.
Different identity systems have different characteristics, some of which have profound impact on how the system works, while others are of minor importance. For the purpose of this article we propose a set of first order parameters that determine some of the principal aspects of identity:
A fourth parameter that seems quite useful, particularly in the classification of existing systems is the extensibility of an existing system.
When evaluating a given identity system it is critically important to distinguish between the capabilities of a given technologies and how they are deployed. For example, one given identity technology might be capable of storing an arbitrary number of freely defined user attributes. However, a simple deployment could restrict the number of attributes to a very small number. As such, for the deployed system, the parameter "Number of Attributes" would be quite small. During the lifetime of such a deployment this could easily change by populating or defining more attributes.
The idea behind defining abstract qualitative parameters is reduce some of the complexities within identity systems to a preferably small aspects that can be evaluated in a straightforward way. The selection of these parameters in this paper is somewhat arbitrary and not necessarily ideal.
Identity systems differ significantly in scope: there are application specific systems, that are only work with that application, and others that are designed with a very far reaching, sometime global scope in mind. Obviously, a local system is typically by far less complex than a global, federated system, that aims at providing a unified approach to identity across a large variety of applications are locations.
While some systems deal only with a small number of attributes (like e.g. an email address or a username handle) many systems that are intended to be used with a wide scope in mind will hold many more attributes. In complex systems, these attributes are not necessarily stored at a central location like a directory or a database. In fact, many systems will depend on a variety of authoritative/trusted and non-authoritative/non-trusted data sources. This can also include storage locations that are with the user of the system.
The extent to which a user can exercise control over his data is very important in the context of privacy and also regulative requirements. While users of distributed applications like e.g. online retailers might want a very high level of user control in order to limit the risks of identity theft or misuse, highly regulated industries such as healthcare will have to use identity systems to create a non-reputable audit trail.
All identity systems that are supposed to be used for more than a single application must be designed with some extensibility in mind in order to allow the enablement of interoperability.
Features within identity systems really define the capabilities of a given system.
Attribute Schema Extensibility
Systems with this feature do not have a fixed attribute schema, but instead allow arbitrary attributes to be included. Many systems that do allow this put no limit on the number of attributes that can be defined.
Limited Attribute Schema Extensibility
Some systems provide a limited number of "User Defined" attributes in their schema that can be used for storing additional information. In all such cases the type for these extension attributes is fixed and cannot be changed.
Single Sign In
Typically for identity system (and - in fact - a motivator for many of them) is the capability to require only a single login. All further resource access to systems participating in the deployment of the identity system will be authenticated and - as policy permits - authorized.
Single Sign Out
This feature is the inverse of the Single Sign In feature: it allows a user to sign out of an entire deployment.
Security itself is typically realized through cryptographic mechanisms. Such mechanisms can change over time, since their strength and capabilities depends on available resources and algorithms. The security of an identity system – in particular a system that is designed to last for a long time – will depend on its extensibility and ability to accommodate new security technologies.
A more general view is that here security is an assessment of various trusts: to crypto science that underlying mathemtics are invincible, to crypto software that it is correct and not tampered with, to hardware that it is reliable, to certificate authorities and registration officers that certificates are properly managed.
Scope / Centralization
The level of privacy that a system allows for is directly related to the capability of the user to control the flow of identity attributes and the number of attributes. For example, a simple system that requires the user to share the first letter of his birthplace in order to get access to resources will offer a higher level of privacy than a system that requires the user to disclose name, address, telephone number and birth date to a limited number of individuals.
Level of Assurance
Many deployments are deeply concerned about codifying and expressing the degree to which identity and attributes can be "believed" by the relying party, based on the credential management, processes, and policies of the asserting party.
This is a government publication that attempts to synthesize many aspects of identity systems into a simple linear scale. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
Based on their different aspects, identity systems are useful or typically used in certain types of applications. E.g. in Web 2.0 applications (like blogs, wikis, etc.) identity systems have typically only a very limited number of attributes (often only an email address), but a very high degree of user control. On the other hand, federation systems like e.g. the Liberty Alliance have a large variety of user control and contained attribute information, but usage only makes sense on a fairly global scale.
There are a number of typical identity domains that are quite common:
Application Centric Identity
Applications have (and probably always will) maintain their own identity system or authentication database. To a certain extent, even operating system user databases can be considered application specific identity systems – their usefulness obviously depends on how the contained identity information can be used elsewhere. Isolated Identity When the extensibility is low or non-existent in a given application centric identity system, it is effectively isolated from all other applications.
As soon as computers obtained the ability to network – i.e. essentially with the advent of IBM’s S/360 class mainframes – enterprises and large organizations started to create their own identity systems. At first, the number of attributes was quite limited. But with directory technology starting to become a reality in the early 1980s, organizations extended the amount of information immensely. Today, enterprise identity systems are typically large and complex federations of different attribute sources that contain a huge number of attributes on employees, business partners, customers, and inventory. Managing such extensive federation systems often requires a lot of effort and resources, particularly since stricter guidelines on identity auditing are being mandated by regulatory bodies. Problems
- different regulations regarding accounting, auditing and privacy across the world
- proper backup and disaster recovery
- integration of users other identities, e.g. in private life etc.
User Centric Identity
User centric identity systems (such as e.g. Windows CardSpace) are aiming at enabling the user to take a larger control of their digital identities. As such, user control has to be very high, by definition. User centric identity system can have a broad variety of scope and the contained information. The Web 2.0 centric OpenID system has typically a fairly small number of attributes, but is used best across simple, “low profile” web applications.
User centric identity systems have the potential to allow the accurate modeling of social networks of users in real time. To enable this, the system must allow the user to edit their own identity information – specifically all information on how he relates to other users in the system. This can be achieved e.g. by maintaining lists of links and related meta data about these links.
All previous identity systems play a crucial role in their respective domains. But without a high degree of extensibility, there are doomed to stay fairly isolated from each other. Network identity systems are explicitly designed to be able to bridge the gap between existing and emerging identity systems.
Distributed and Federated Identity
Relation to Other Characterizations
Identity Gaps and Exposures
?How do todays identity artifacts expose individuals to privacy breaches, etc.
The Seven Laws of Identity
- User Control and Consent
- Minimal Disclosure for a Constraint User
- Justifiable Parties
- Directed Identity
- Pluralism of Operators and Technologies
- Human Integration
- Consistent Experience across Contexts