Draft 2: 4-2-04
Identity and relationship management
A discussion paper
Mike Martin
Centre for Social and Business Informatics,
Institute for Policy and Practice,
University of Newcastle upon Tyne
mike-martin@btconnect.com
Introduction
One of the key evolutions in information systems architecture which has taken place in the
last decade has been the shift in the location of integration components and facilities from
middleware, behind or underneath applications, to the hub/portal which is in front of
applications. This removes the assumption that the components or applications which are
being integrated are necessarily parts of the same domain of ownership and enterprise and
changes what we mean by "application". In this reconfiguration of the ICT infrastructure, the
concept of the index as the means of establishing and maintaining consistency of identity and
identification within a domain of integration and of relationship, has become a central issue.
The purpose of this paper is to explore the issues of identity and identification at the
integration and federation levels, that is to say within domains of mutual trust and
understanding and between domains of trust and understanding. The current presenting
problems in the real world of systems development are described, at the user level, in terms
of issues such as “single log on”, authentication and identity management and at the
computational level in terms of the handling of state among web services and resources. In
the architectural view which will be presented here, the relationship between the efforts of
initiatives such as Liberty Alliance (http://www.projectliberty.org/) and those of Globus
Alliance (http://www.globus.org/) appear to be more than merely nominal even if these
communities seem to have little to say to each other (so far).
Proposals and developments in these particular initiatives have been pragmatic and have
mostly been focused on immediate requirements in Net based commerce. When these ideas
are applied in the world of public services, particularly when we include health and social
care, we are faced with a more complex and subtle set of requirements compared with the
relatively simple worlds of commercial product and service relationships. This paper argues
that it is in the public service domain that we will find the real challenges for the next
generations of information and communications infrastructures. If there are useful meanings
to be constructed for terms such as "ambient intelligence" and "ubiquitous services", it is here
that we will discover them.
Defining some terms
If we are to be able to talk about systems that deal with identities, there are a number of
distinctions we must make and terms we must sort out. In particular we must be clear about
the difference between the labels we attach to things and the things themselves. The former
exist in our language and our information systems and are referred to, technically, as
intensions. The latter exist in the world which is external to our systems and are called
extensions.
Consider the case of identifiers, such as my national insurance number and my NHS number,
and me, the individual to whom they refer, who is employed in Great Britain and is
sometimes a patient of the National Health Service. There were definite acts, performed in
different organisational and administrative settings, that generated these particular
identifiers, allocated them to me and recorded the fact in certain registers. Those systems
were responsible for ensuring that, within each register or list of allocated identifiers:

no two different individuals are given the same identifier,

each individual has only one entry,
1
Draft 2: 4-2-04

that, within reasonable and appropriate constraints, the link between an individual and an
identifier can be validated.
The way that the last of these conditions is achieved is by associating a number of items of
data, that are indicative of a specific individual, to each identifier in a register. Such things as
given name, date and place of birth, the names of parents and current address are commonly
used. Stronger and theoretically more reliable verification can be based on biometric data
such as fingerprint, retinal scan or DNA profile. The purpose of this data is to support
authentication processes, i.e. the validation of a claimed identity. Thus, we have a third
concept which must be distinguished from both identifiers and the individuals to which they
refer: an identity is a set of indicative data used to recognise and authenticate an individual.
Notice that different registers may use different data items, called identity attributes, and any
particular set of attributes may or may not provide, or continue to provide, a dependable
basis for the authentication of a particular individual. Possible faults in an attribute data set
used as an identity are:

Under-indication: authentication data indicates more than one individual.

Misindication: authentication data indicates the wrong individual.

Non-indication: authentication data does not indicate anybody.
The notion of individuality that applies to me is, of course, a physical one. There is only one
of me and, as long as I exist, (in the period between the event of my birth and the event of
my death) I can only be in one place at a time. There is another class of “individual” which
has important characteristics concerning identity. The members of this class are legal entities
such as companies, corporations or other collectives such as clubs and associations, which
are constituted and operate under some public registration framework so as to be able to
engage in both internal and external transactions and relationships.
The ideas about identifiers and identities we have defined for individual people also apply to
these virtual individuals but the external reality - the extension - that they refer to is
constituted by a set of human laws and contracts rather than by the laws of logic and
physics. So, my business partner and I own, and together, are a Company. This Company
has a registered name and head office, a unique registration number on the British
Companies' Register, a VAT number etc.
We have defined the terms, identifier and identity together with the concept of a register
which maintains the link between them and allows an identity to be associated with an
individual. From the examples, we have shown that a particular individual may have a
number of different identifiers and this leads to the requirement for indexing.
An index is a (table) mechanism for associating identifiers which designate the same identity.
The row of an index records the a set of identifiers from different relationship domains which
are associated with a particular individual. The columns map the distribution of the clients of
the provider domain. Returning to our example: if my NHS number and my National
Insurance number appear on the same row of a shared index, a possibility for the clinical and
the employment domains to communicate with each other about me has been created.
Transaction and relationship.
The reason why identity is important is because it is through identity that we can have
relationships that persist over time and in different places. So identity and relationship are
closely linked and the concept that ties them together is that of a transaction.
The use of information from previous transactions in subsequent transactions, by the same
parties, constitutes a relationship between them.
The necessary conditions for a relationship are:


the same parties engage in multiple encounters,
they recognise each other,
2
Draft 2: 4-2-04


they remember and make use of their mutual history and, as a result
they engage in further transactions.
Anonymity
Anonymity, like identity, is defined in relation to transaction. A party is anonymous if no
identity related information regarding them is generated. A consequence of this is that an
anonymous transaction can not be part of a relationship, there is no means by which the
party can subsequently be recognised and any responsibility attached to them.
A party is pseudonymous if there identity is entirely local to the immediate transaction or
relationship and does not include indicative data which could be correlated with a domain in
which it may be nested such as a public identity.
Publication and permissioning
Granting access to an index is publishing the fact that certain relationships exist between a
set of relationship providers and a set subjects. (We use these terms to distinguish the
column identifiers from the row identifiers.)
R
k,
R Pb
l,
P
R b
m
,
R Pb
a,
R Pb
b,
R Pb
c,
R Pb
d,
Pb
A relationship type +
A provider identity
Identifiers associated with
the same individual.
Figure 1: The implementation of an index as a table
Access to an index generates the possibility of services which implement consents and
permissions for transactions and relationships. The form of a permission could be the
following:
I, the individual with relationship W to individual I know as ABC, am willing to enter
transactions e, f or g with anyone who has relationships X, Y or Z with ABC.
Such publications may be subject initiated, subject permissioned, joint between subject and
supplier or subject independent. Each case has consequent editorial rights, responsibilities
and consequences.
An individual taking advantage of this service can do so with the query:
With whom can I engage in transaction e, regarding the individual I know as LMN?
3
The INDEX
R
k,
R Pb
l,
R Pb
m
R , Pb
a,
R Pb
b,
R Pb
c,
R Pb
d,
Pb
Draft 2: 4-2-04
A narrow cast channel of
communication about a client.
Identifier
Identity attributes
Record
Provider of
relationship Rb.
Provider of
relationship Rk.
The client
Figure 2: integrated relationships
The INDEX
R
k,
R Pb
l,
R Pb
m
R , Pb
a,
R Pb
b,
R Pb
c
R , Pb
d,
Pb
The result of such a query will be a set of messages which are narrow-cast to the parties that
share the indicated relationships with the subject and whose relationships have associated
permissions – i,e, there local identifiers for this client are entered in the same row of the
index. These messages will only identify the subject to each party my means of their local
identifiers within their relationship and the process preserves pseudonymity. Any sharing of
information about mutually identified subjects would be part of a subsequent local transaction
between the collaborating parties.
Identity Management
Provider
Provider of
relationship Rb.
Provider of
relationship Rm.
Figure 3: locally managed identity
The relationships entered into a particular row of an index are considered integrated. Any
provider who has placed a local client identifier on a row can narrowcast requests for
transactions regarding that particular client to any other providers on that row.
Identifiers referring to the same individual may be placed on different rows of the same index
thus creating uncorrelated local identifiers. We now introduce a special type of relationship
supplier, the identity manager, who operates in the following way: if a client who has
identities entered on more than one row of the index forms a relationship with an identity
manager, any narrow cast message on any of the rows occupied by this client will be
transferred to the relationship providers on the other rows under a set of local rules and
permissions. This is represented on Figure 3.
4
Draft 2: 4-2-04
Federated permissioning
If we now introduce the concept of an identity manager who provides services to clients who
have relationships in different index domains and who operates a further set of protocols and
consents for routing client related narrow cast messages, we have a means of implementing
a distributed and federal identity management infrastructure. This is represented in Figure 4.
Registers which
use different
attribute sets to
indicate
identities.
Register 1
Register 2
Register 3
IM
P
Ra b
,
Rb Pb
,P
Rc b
,
Rd Pb
,
Re Pb
,P
Rf b
,P
Rg b
,P
IM b
Pc
IM
P
Rk b
,P
Rl b
,P
R b
m
,
Ra Pb
,
Rb Pb
,P
Rc b
,
Rd Pb
,P
IM b
Pa
Identity Management
Provider B
Identity Management
Provider A
Two domain
indexes with
shared identity
management
services
Sets of profiles
and records of
the same
individual with
different
relationships in
two different
domains.
Relationship Rb.
Relationship Rc.
Relationship Rk.
Relationship Ra.
Fugure 4: Federated identity management
In this scenario our client has two relationships in each of two index domains, i.e. domains of
trust and service coordination. Relationships Ra and Rc are integrated and their providers are
able to share information and transactions. Relationship Rk and Rb are coordinated via
identity manager A who implements a set of agreed rules about which requests for which
transactions are passed between them. The link between relationships Ra and c, on the one
hand, and relationships Rk and b, on the other, are handled by federal identity management
service B which links relationship Rk to Ra and Rc creating a transaction request routing
between the two domains regarding this client.
Note further that identifiers a and c are mutually traceable because they were originally
authenticated through register 1. Relationships k and b are not reliably traceable to each
other outside of the system because they are each based on authentications from different
registers which use non identical attribute sets.
Distribution and centralisation
We have developed transactional concept of relationship and a relational concept of identity.
We have further defined an identity management architecture based on these concepts which
involves registration and indexing. With this framework we are now able to identify the
different forms that distribution or centralization could take and, in this way, define the range
of possible policies and consequent configurations of an identity management infrastructure.
5
Draft 2: 4-2-04
Our identity information architecture defines three levels:
1. The registration level,
2. The indexing level,
3. The relationship level.
In the terms of our architecture, relationships at the third level are nested in collective
relationships at the first level.
At the level of a federation, policy could mandate a single register in an attempt to guarantee
the ultimate traceability of all identities. Alternatively, the benefit of closer association
between registers and their members, in terms of data quality and testability of coverage,
may justify a policy of multiple, relatively local registers. Recursion here would imply an
indexing of registers and the meta-registration of local registrars, producing an identity
hierarchy rather than centralised identity.
Policy might dictate that there is only one (logical) index and that all identity management is
“local” to it. Such an approach has limited political stability requiring the exercise of strong
central power. A further control option would be that individuals may only have identifiers on
a single row within an index: all the relationships of a given individual are correlated and may
be linked.
While multiple indexes may be sanctioned, policy could dictate that there is only one,
universal identity management service which is present in all of them. This places very high
demands on the trustworthiness and dependability of such a provider. Alternatively, there
could be a central licensing authority so that identity management service providers are
registered and regulated.
Finally, there could be a free market in identity service providers.
Such policies, of course, have economic and commercial consequences as well as political
ones.
Concluding remarks
Current developments and, in particular, Liberty Alliance, represent a pragmatic and
evolutionary approach to the issues of identity in the context of commercial transactions and
relationships and current technology and systems practice. As such, we believe that it is a
specialization of the framework presented here. Current developments, which respond to
commercial and infrastructural realities, tend to conflate the idea of the authentication role of
the register and the transactional support of the index into a single third party system onto
which the concept of the circle of trust and a peremissioned identity management service can
be mapped.
Hopefully, the most useful way of regarding the architecture presented here is as an attempt
to represent and rationalise the current and expected evolution of identity management
concepts taking into account the different requirements of public service, administration and
commerce.
6