To address identity issues, it is important to understand the concepts of entity, identity, identifier and credential, operations such as authentication and authorisation, and how these apply to dealing with others.
Online interactions generally cover several stages, all having some correlation with what happens normally. First comes mutual checking as to who the other party is. Once this has been established, it is followed by finding out what is generally known about that party (maybe with the help of others, maybe just on past experience with that party). Based on this, a decision can be taken on how they will interact. Finally, a record (ideally provable) should be kept of what happened. These stages are authentication, authorisation and audit.
What are entities, identities, identifiers and credentials?
The essential concepts here are entities, identities, identifiers and credentials, and these are defined below.
An entity refers to a person using the computer, network service or mobile device. Entities own and use credentials and also possess a virtual identity. This identity is known by any systems the user regularly accesses, and will therefore contain all the information (about the user) that the system has been able to obtain. Users (entities) use credentials to prove ownership of an identity. Users are not limited to one identity - for instance, you can have separate identities on different systems. Alternatively, a user can use different identities on the same system; for example, you may have a personal identity and a work identity.
Origins of identifiers and credentials
It is not always obvious whether some items are identifiers or credentials. In fact, sometimes an item can be used as either. An identifier must be unique, but can be an amalgamation of several non-unique items. Likewise, some credentials are not at all secret, though they should be.
An example of this is the login process for an online financial services provider asking for two sets of information - a composite identifier and some credentials. The 'personal details' set includes publicly known information such as name, date of birth and address details - although none of these are unique in themselves, together they can be used to form a unique identifier. This method avoids the user having to remember a particular user ID. The 'security details' section gathers the necessary credential values. Although the password is a private item and should be kept secret to the user, the mother's maiden name is rather less so, but is often used as a semi-secret extra credential.
Other possible candidates for identifiers and credentials are user characteristics such as biometrics and system-originated items. Hybrid methods also exist whereby a user may choose their preferred user ID and it will be accepted if it is unique or replaced by a modified form (often with extra inserted numbers) to make it so. Passwords are often initialised in an out-of-band email but the user must change them immediately, when they first log in, to a value of their choice (within the constraints of a password policy).
Identification, authentication, authorisation and audit
Identification, authentication, authorisation and audit can best be viewed in the context of a typical security operation, such as logging into an online system. Firstly, the user must claim an identity (to the system). This is done by providing an identifier - a user name, for example. Hence, the identifier must be unique within a system, so it is clear exactly which identity is being claimed.
This identification tells the system who might be trying to connect, but offers no proof. So the next step is for the system to obtain proof of this identity and to check it - this is the authentication process. The connecting user does this by providing credentials for that claimed identity, known only to them, for example a password. Credentials (unlike identifiers) are not necessarily unique - for instance, several users may coincidentally have the same password, but only a particular user should know what their password is.
After the authentication step is completed successfully, the system can be fairly certain that the user is indeed the rightful owner of the chosen identity. However, this does not mean that the user can now do anything they like on the system - each user will have a set of allowed actions. These permissions are known as privileges and are determined in the authorisation stage. The system must look up the relevant privileges for the authenticated identity. Therefore there must be a binding of identity to privileges. This binding information must be available to the system, and can be obtained from two sources - either from a database to which the system has access, or contained within a credential or document provided by the user - for example, a driving licence can be used not only as proof of identity but also as binding an identity to an authorisation to drive particular vehicle types, hence acting as a permit to drive them.
There is also an additional concept of audit - this is a record of what happened once authorisation has been granted. In other words, what did the user do? It consists of a set of records, each linking an established identity to an action. Ideally the records should be provable, should a later dispute arise.
Credentials in detail
A credential can exist with two parts - a private aspect used as proof (of a user's identity), and a verifying (or public) aspect that a system will use to validate the former. These exist in pairs:
- Private credential - anything used by a user to prove who or what it is. These can be secrets (password, PIN, private key), physical items (token, company pass card, branded bank card) or characteristics (biometric features such as a fingerprint).
- Verifying credential - the counterpart to the private credential, which is used to check that the private credential was valid. For example, a photograph is a verifying credential used to check someone's face. Other examples are a biometric characteristic, a password hash (check the supplied password generates the same hash) or a public key infrastructure (PKI) or public key (mathematical counterpart to the private key within a PKI).
Binding
Credentials are therefore associated with a particular identity. This requires a binding operation between the verifying credentials and the unique identity. Binding instruments are often used here, as they provide the association, or linkage, between the pieces of information. A system may have access to a database storing such binding information, or the user may submit a binding instrument to the system for this purpose. Binding information may be created by the system itself or by a third party.
The information itself could just be a record in a database, linking a username with a password hash. A digital certificate can bind a public key to a name (or email address), thereby verifying the user of the matching private key. Another example is a driving licence, which binds a signature (or photograph) to a name, binds name to address, and name to ability/ permission to drive - thereby giving a driving licence multiple uses. A binding instrument has the following structure:
- identifier - providing a link to the subject's identity;
- identity information - other public items (such as address, date of birth, name), which help to distinguish the identity as an alternative to an impersonal system identifier;
- verifying credentials (specimen signature, photograph, public key etc) - binding instruments almost always contain at least one of these, as this is the only link between it and its subject;
- functional information - important data usually related to the primary purpose of the binding instrument, for example vehicle types and endorsements on a driving licence;
- notarisation and provenance data used to validate the actual binding itself, for example an expiry date shows when it can no longer be trusted and a digital signature indicates who produced the binding (the issuer), while physical attributes, such as form, look and feel, holograms and special paper/plastic, are also used. However, these offer no value in a purely online context other than as a convenient place to keep the information.
Credential life cycles
There is a defined life cycle for credentials, and indeed for entities, identities and identifiers. This addresses what happens in the various phases of a life cycle - birth, in-life and death. Human entities have well-understood concepts of birth, in-life and death. The difficulty is in synchronising their associated identities and credentials with this. However, there are several intermediate thresholds and stages. For instance, different rules apply at certain ages (driving at 17, consuming alcohol at 18).
Identities are associated with entities. The birth stage is generally the registration of an entity into a system (resulting in the creation of an identity in that system), and the death stage may not be a simple cessation, as records may need to be kept after an account is terminated. In-life can include credential updates, suspensions etc. Identities may be terminated while the associated entity still lives (for example when a person closes their bank account), or may continue upon an entity's demise (either deliberately to maintain records, such as bank accounts during probate, or accidentally, due to poor communication and lack of synchronisation).
An identifier is a unique pointer for an identity, and it generally follows the life cycle of the associated identity. However, identifiers may need to be retained indefinitely, to ensure they are not reallocated, which could cause confusion, or permit fraud, later on. Often credentials and bindings have their own life cycle, quite separate to the associated entity/identity. Passwords may only last for 90 days. Passports typically last for 10 years, after which they are no longer valid.
Conclusions
Any strategy for dealing with identity must be based on a full understanding of the life cycles of its various components - how they are created, how they are used and maintained, and how they are removed after they are no longer needed or available. Identities must be tied to their subjects (entities / users) in registration processes, and the security in many systems can fail through weaknesses in this registration process, despite great security in the credentials.
Finally, no system of identities is entirely isolated, as they all interact with other systems and providers, continually modifying and checking their own records of identities. Although there are security advantages in not having a single point of trust for identities, there are disadvantages in having too many sources of trust with no set processes or standards, making it too easy for false identities to exist among the legitimate ones.
