Commentary by Mark Wahl
Organizing principles for identity systems:
Repurposable identity management systems (part 2)
(2005/5/10)
Many of the emerging identity systems being proposed are structured around representing information about persons, and associations between those persons (e.g. groups, organizations).
At the same time, Internet services continue to be used, not just by individuals and software applications operating directly under the user's control (e.g. email and web client), but also by devices, sensors, autonomous agents, web services, etc.
Today, these devices have minimal or no identity services available to it from the underlying lower layers: DHCP, service location are typically deployed with open networks, and self-configuring networks with improved security (e.g. building multi-hop networks from wireless sensors scattered across the landscape) are subject of research projects. This situation appears a bit better at the application layer: protocols have authentication elements, and implementations of many protocols (directory, web, etc.) have some form of access control.
In some cases, e.g. intelligent agent software, it is conceivable to delegate identity to the software, although most identity systems have no convenient way to represent this form of delegation.
Similarly, today web services are given credentials (e.g. username and password, or a public/private key pair) when they are installed.
But each of these are only the basic part of identity. These non-person identity have requirements for attributes and relationships, just as for persons, although the semantics of attributes are different, e.g.
- client-server and peer relationships for different applications
- locality
- ownership
- reputations (e.g. interaction quality, reliability)
Currently these are hosted externally, in spreadsheets, databases, MIBs well outside of the 'control' of the identified user. Indeed, many identity systems even lack the ability for the user to update or revise their credentials.
If the goal of emerging identity infrastructure protocols and services is to enable the user, through user-centric models and federating at the user level, do these work at the level of non-human users?
For example, in a Microsoft PDC presentation on Longhorn identity, the "Info-Card", the basic unit of identity, is described as consisting of:
- display name
- identity claims: unique identifiers
- disclosed information
- certificate
- use policy
Two basic questions emerge: the first being: what is a display name for a recipient without a display, but the second and more critical is: how are the use policies represented?
Policies, as described in X.509 extension attributes (or even LDAP controls), typically require code be present in each of elements. Some are self-contained, e.g. a path validation constraint: this is an end-entity, don't validate certificates signed by the certificate. Others are not machine processable: the control contains a 3-page English language legal document which the processor should 'agree to' before validating using this certificate. These sort of issues need to be worked through each of the emerging protocols.
In addition to representing the identity, can the non-human user maintain their identity? Even if the application layer protocol has an authentication element, it may lack a 'change credential' element. Nor are there any protocols today in which a non-human user may view and manage their reputation, associations, report and recover from identity theft, etc. More basically, there's not yet a "help desk" for these non-person users to contact in case there's a problem in their environment.
More notes on approaches to solving these limitations to follow in later posts.