The Identity Management Laws
(and some FAQs at the end)
In this context a "Law" is simply a directive, a rule, a best practice or a design principle.
There are three classes and each class has its own assertion.
They are not a natural or scientific fact such as the law of gravity, basically because we are not born with an identity (although we are born with unique credentials) – we are provided with identities by others through different systems that are intended to assist in authentication and access.
These Identity Management Laws are equally applicable to human (manual) and non-human (computer) systems. It has been my experience that adherence to these laws will result in better systems and services.
They are akin to Assimov’s Laws of Robotics:
1. A robot may not harm a human being, or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given to it by human beings except where such orders would conflict with the First Law.
3. A robot must protect its own existence, as long as such protection does not conflict with the First or Second Law.
The full set of nine Identity Management Laws are:
ID LAW 1 . . . An Entity may have many Identities
ID LAW 2 . . . An Identity does not identify an Entity
ID LAW 3 . . . Only an Entity may federate its identities
ID LAW 4 . . . An Identity may only provide sufficient information to meet authentication
ID LAW 5 . . . An identity does not need a new credential if it already has one that you can trust
ID LAW 6 . . . A credential should only be authenticated by the issuer
ID LAW 7 . . . Proving an Identity does not grant any access rights
ID LAW 8 . . . Access is a product of identity, credential, role, profile and transaction
ID LAW 9. . . Access rights change dynamically
The nine Identity Management Laws are detailed below.
Note – "An Entity is a unique person or thing, anyone (a natural or legal ‘person’) or anything with a separate existence that can be characterised through the dimension of its original attributes. It cannot be owned."
From The identity Dictionary
Identity Laws :
Assertion: “this is who I am”
ID LAW 1. An Entity may have many Identities
An Identity is an instance of an Entity – examples are a username, a logon-id, a bank account number, an employee number.
Identity is provable, and is owned by the entity that can verify the identity assertion. It is not subjective. A person may have an employment Identity at work, which may be provisioned with an account on the LAN, an account on the mainframe, an email account and several on the Linux development server. The same Entity may also have other identities such as an eBay user ID, a HoTMaiL identity, a drivers licence number, different customer account numbers at several Utilities, numerous contact phone numbers, and so on.
ID LAW 2. An Identity does not identify an Entity
An Identity is able to transact independently of the entity.
Each identity can function on its own. An account at eBay, HoTMaiL or a service provider does not need to be linked to other identities, nor to the Entity. Complete anonymity of the Entity is not possible in any IDM system that seeks non-repudiation (most business applications), but pseudonymity is certainly permissible, and often desirable.
ID LAW 3. Only an Entity may federate its identities
The Entity is the only thing that knows of the link between identities.
Therefore the Entity is the only one with the capability of joining its multiple identities into a single identity, or granting the ability to determine a federated identity. This can achieve improved services to the Entity, such as a single sign-on to several services. It has no effect on the Entity. The entity may wish to be seen as a single customer of a group of financial institutions and may or may not want a new identity with which to unite them.
Authentication Laws :
assertion: “this is who I am and here is the proof”
ID LAW 4. An Identity may only provide sufficient information to meet authentication
An Identity should not need to provide more proof than is necessary to access the service being offered.
You don’t need a digital certificate to ask for basic assistance; you don't need to tell HoTMaiL your birth date to send emails. “Step up” authentication models, as an alternative to “strongest possible” authentication, are a reflection of this law – they are more user friendly, and each credential is more easily administered (cancelled, renewed, upgraded).
ID LAW 5. An identity does not need a new credential if it already has one that you can trust
Additional credentials are both an inconvenience and an unnecessary cost, to the issuer and the identity.
You don’t need to be issued a new drivers licence for a new state if you have a current one from another state – it’s all a matter of trust. The ATM for one bank can trust a credit-card from another financial institution, for certain transactions. Trust and risk are inversely related. The level of trust will be determined by the service provider’s Assurance Framework.
ID LAW 6. A credential should only be authenticated by the issuer
A credential issued by a third-party should preferably be authenticated by that third-party.
For example, a digital certificate should be authenticated by the original Certificate Authority itself, otherwise there may be differences in the authenticity of the credential that can’t be picked up at the time. Also the relying party will be accepting a higher level of risk if it conducts its own additional registration process. Each provider will still have its own Assurance Framework, and therefore assign a trust level to it that may be different to the level other service providers assign.
Access Laws :
assertion: this is who I am, here’s the proof, now what can I do?
ID LAW 7. Proving an Identity does not grant any Access Rights
Authenticating an Identity does not guarantee that the Identity can do anything it wants.
Each site’s Assurance Framework will reflect its view of both the identity issuer’s registration rigour and the credential strength, and will reappraise this for each proposed transaction. For example, I may not be permitted to do any transactions at all, or any above a given $ value unless I present a stronger credential (or perhaps use a different identity).
ID LAW 8. Access is a product of identity, credential, role, profile and transaction
The combination of credential strengths and identity registration strengths will meet a predetermined Assurance Level in the Framework.
In order to gain initial access an Assurance framework should be created, and then the user’s role will further define levels of access. It will also be affected by the channel being used, such as from an internet café, telephone banking, face-to-face (over the counter).
ID LAW 9. Access rights change dynamically
Just because you could do something last time, doesn’t mean that you can continue to do it.
This may happen if a user’s credential expires, is revoked, or an identity attribute changes, or a business rule changes or a new law is enacted. The entitlement to access a service will change in real-time. For example your digital certificate expires, or be added to a revocation list, or you resign from employment, or your drivers licence is revoked. This may also be the case if Law 6 is not adhered to. The owners of resources might set and change the access rules and assign the permissions as they see fit.
Some questions and answers that may help clarify the use of these laws.
Please refer to The identity Dictionary for definitions of terminology:
Who owns my identity ?
You do. But who are you? This question usually means who owns the “me” (the entity, not one of its identities). In general an Entity cannot be owned, in the way that an identity can be owned, except in some legislative sense. Shareholders of a company may claim ‘ownership’, when they in fact only have some legal entitlement to the assets. Animals (eg horses) and humans (eg slaves) cannot actually be owned in the Identity sense, only possessed due to legal arrangements.
a. The definition is the key.
The First Law of Identity Management clarifies the situation: “An entity may have many identities." Others might put it thus: "An Identity can have multiple Digital Identities...". Either way, customers of service providers are Identities (not Entities). Carl Ellison (SUN) is correct when he refers to an Identity as an instance of an Entity. Why does this matter, especially when access credentials are issued to identities, not entities? Because it is the entity that establishes each identity, and it is the entity is legally responsible for the actions of the identity.
b. No one 'owns' it.
No one can 'own' an Entity. But people can and do 'own' Identities. How? By being able to authenticate them (eg know the password). Those identities that you can't authenticate you don't actually own.
Note to those that believe Reputation is an Identity or a Credential; it isn't. I agree with Bob Blakely, although for different reasons: a) a written article is NOT an identity, and it does not affect an Identity. It's just a story and the rest is only semantics. b) Identity does NOT allocate risk, only trust can allocate risk. Trust is created in an Identity Management Assurance Framework, not in a newspaper. c) An Identity's Reputation CAN be a registration strength in your own Assurance Framework, with whatever value you wish to allocate it, but not a credential strength . You can see this in the concept of a "known customer", or in an eBay seller's history.
Which is the real identity, Clark Kent or Superman ?
Neither. They are two Identities of the one Entity - the entity called Kal El.
I wonder if he has fingerprints, DNA, or other biometrics.
Iris identification could be an interesting challenge ;-)
What is the best way to implement IAM, to maximise the return on investment ? Or to put it another way, how can each phase of the project pay for the next phase ?
Here is the best sequence:
1. Self-service & password reset.
2. Password policy enforcement.
3. Password synchronization.
4. Assurance Framework (User Registration and Credential matrix)
5. Trusted sources & business processes.
6. Data quality
7. Meta-directory & Consolidated Identity.
8. Publish, subscribe and data synchronisation.
10. White pages & contact messaging.
11. User deprovisioning.
12. Delegated administration.
13. Role definition and creation.
14. Role management.
15. RBAC (organisational, functional and resource/entitlement)
16. Workflow and approvals.
17. User provisioning.
18. Self-service role matrix and rights management.
19. Enterprise reduced sign-on.
20. Audit, alerts, archives
21. Event reporting
22. Multifactor strong authentication.
23. Web/enterprise access management.
24. Federated identity management.
What is the the problem with passwords ?
On the surface it is a good idea – a password has a False Acceptance Rate of 0% and a False Rejection Rate of 0% (you can’t get any better than that . . . . . unless someone else knows it, then it can't get any worse).
But this methodology speaks for itself :
Step 1 – Pick a unique password for a LogonID, obeying the site rules. A typical example: it must not be a dictionary word, must contain an uppercase Alpha, a numeric, one or more special characters and must be changed every 30 days to a different non-dictionary word that you have never used before. You have about 1 minute to choose one. This guarantees that you cannot easily remember it.
Step 2 – Don’t write it down or record it anywhere . . . or else !
Step 3 – For the next LogonID, go to step 1.
One suggestion is to remember a pasword phrase, such as "My brothers name is John. He is 27 years old" and derive the password from it (MbniJHi27yo). But try changing that every month!
Single Sign-On may be a convenience; it reduces the number of accounts needed, and it therefore reduces the number of passwords to remember. But it only magnifies the password problem. To overcome the inherent unreasonableness or inhumanity of this method, most users who have multiple accounts (and it is not uncommon for users have ten or more accounts) will choose the same password for all accounts and will make sure it is easily remembered. For example it may be their middle-name starting with a capital letter and ending with a number that is incremented by one every time it expires). Then they still write them down because they might forget them. And they do forget them, as they get out of sync due to differing expiry lengths (causing more overheads for password resets).
Users will also prefer to have unexpiring passwords so they don’t need to remember them. This then is the default for the internet, and any service that forces password changing is quickly avoided.
Some sites allow the password to be entered in an unsecure session, and the password is transmitted in a human-readable form.
Lately keystroke-capture virus software has made it difficult to keep the password secure.
The real problem with all of this is that the user is understandably trying to minimise the site rules’ negative effect on their productivity, with the result that it makes it easier for others to guess their password.
More importantly there is a growing trend to admitting that you wrote it down and stuck it on your computer screen (even if you didn't), especially when it means that you can repudiate an accusation that you were the one that took certain actions (because fraud has a longer jail sentence than stupidity).