Laws of Identity in Practice

If you are not familiar with Kim Cameron's identity blog or his "laws of identity" they are worth a read. I have been involved in a number of identity management (IDM) projects so I thought I would analyse how I have found the laws applied in practice in banks in Australia and London. The laws are more applicable for designing identity systems and maybe not identity management systems but I shall press on and consider them in an enterprise context.


The identity management systems implementations I have been involved in, all from a requirements, design and architecture perspective have had a conceptual design such as follows:

Again I would stress that the laws of identity are talking about an identity meta-system that could be applicable in all contexts  consumers, individuals, government interactions, and corporate interactions thus there is not a direct mapping to a corporate IDM system but I will do what I can to analyse them in that context.

Law 1: User Control and Consent

"1. User Control and Consent: Digital identity systems must only reveal information identifying a user with the user’s consent"

Key factors that I got in complying with this law: trust, predictable, translucent, simplicity, ease of use, use in control (of both the identity they use and the information disclosed), identity of the requester is verified, purpose that the identity information is being collected is clear and adhered to.

How well do enterprise IDM systems comply with this in each context:

Staff (employee, contractors etc.) - Low compliance. Staff often do not have any control or consent over the identity information that they need to provide and the information contained in each identity. Typically there is only one choice as part of the contract of employment/service staff must disclose a huge amount of information including personal contact details, DOB, government identifiers (SSN, NI etc.), closest relationship details (next of kin, emergency contact), medical details. This is then linked to their name, salary or employee number which must be used to authentication to every system. Employers would argue that this information is required to vet the staff member: i.e. perform background, criminal record, reference checks etc. This is fine but unfortunately this information is then retained and linked to the corporate identity LDAP for use in every other corporate context.

Staff do have a good of control over the identity information through features such as employee self-service, where they can maintain their identity information. However they rarely get any option to delete any identity information.

Customers / clients - Medium compliance. For individual consumers signing upto a e-commerce service there is often no choice on the amount of identity information that is required to be provided if you want to use the service. For the most part this is minimized to what is required e.g. name, address, contact tel/email, etc. Some services do collect DOB, mother’s maiden name etc. when it is not required and even address and contact details when the product or service will never use these. Much more services should allow anonymous 1 off transaction choice, only the option for identity information to not be retained beyond the single transaction. Far more business should support user as the identity provider e.g. with technologies such as Open-ID

It is actually worse for B2B identity provided in a customer context. Due to the need to contract there is a huge amount of identity information e.g. company financials, history, directors, weaknesses in control environments etc. that are obtained and linked the customer identity when the same principal of initial verification and then business as usual use could apply.

Maintenance same as employees - typically there is an account management type self-service function.

Vendors - Medium compliance. As above for B2B customer transactions

Law 2: Limited Disclosure for Limited Use

"2. The solution which discloses the least identifying information and best limits its use is the most stable, long-term solution

Key factors: minimum identity information collected, minimum retained. Least amount of identifying information collected, allowing use in the least applicability / use in multiple contexts. Limit use to a specific scenario.

Staff (employee, contractors etc.) - low compliance. As I detailed above the amount of identifying information collected is far greater than what is required beyond the initial vetting process. The employee login identifier is available for use in multiple contexts. Interestingly the problem gets worse as IDM systems get better and more widely implemented, where you previously had 10 separate identities for use in 10 systems now you have one that is also linked to your HR information. Achieving compliance with this also has the competing challenges of full accountability, non-repudiation and inter and intra system segregation of duties.

Customers / clients - Medium compliance. This is only because few companies have achieved the CRM nirvana of one customer view. There are also conflicts with consumer convenience such a s remember me and single sign-on.

Vendors - As above for staff.

Law 3: Law of the Fewest Parties

"3. Digital identity systems must limit disclosure of identifying information to parties having a necessary and justifiable place in a given identity relationship

Key factors: disclosure limited to minimum number of parties required for identity relationship, Subject who discloses identity information understands who they are dealing with and why and have delegated rights policy for the information disclosed. All parties have a published policy of identity information use.

Staff (employee, contractors etc.) - Medium compliance. Typically staff are only disclosing identity information to their employer. This gets a lot more complex and compliance drops where outsourcing, cloud computing and federation comes into play. Federation is particularly interesting where there is federation of access using a third party in the middle e.g. Ping Identity in many implementations this law is not adhered to. There is a very rarely an information use policy that both parties publish, an even more rarely a delegated use policy.

Customers / clients - Medium compliance. Organizations which have certain jurisdictional requirements such as Swiss Secrecy laws are very good at conforming to this principle. Again the water gets muddy where identity as a service is used, outsourcing, cloud computing and federation again. It’s actually interesting to contrast Microsoft Passport v. Facebook connect. People and business are happier to use Facebook connect because Facebook adds something to the transaction rather than the identity provider. E.g. the user can share what they want from the application with their friends and the application gets access to referral network allowing it to provide social value added services.

Vendors - as per staff.

Law 4: Directed Identity

"4. Universal identity metasystem must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for private entities, thus facilitating discovery while preventing unnecessary release of correlation handles."

Key factors: omni directional identifiers should be for public and not private use. Uni directional identifiers private and not public

Staff (employee, contractors etc.) - Medium compliance. This one really depends on the company. Many do use a staff members name e.g. rakkhi.samarasekera as their corporate identifier including email. This has many benefits in terms of ease of use, memory, simple for vendors and customers e.g. email is very convenient. Others do provide an obscure number e.g. 23429042389 as a private staff identifier and pay the price in other ways.

Customers - Medium compliance.  Most companies do allow the user to select an identifier which is controlled by them whether it is public or private e.g. username or provide them a customer identifier which is private. More and more are using email address which I view as a public identifier as the username again for convenience and reduced password/username forgotten issues

Vendors - as per staff.

Law 5: Pluralism of operators and technologies

"5. Universal identity metasystem must channel and enable the interworking of multiple identity technologies run by multiple identity providers"

Key factors: support for multiple identity providers including the individual, multiple identity systems supporting different even contradictory features. Enable a single person to provide different identities in different contexts, allow selection of different providers with different features in different contexts.

Staff - Low compliance. Staff are usually restricted to a single corporate identity provided by the corporation with a single set of features. This may change with the move to mobile user controlled endpoints. I am hopeful organizations in the future will support the user selecting Facebook, Google, Open-ID as their identity provider and third party federated identity management systems in addition to the corporate IDM. Technology is where there is real improvement due to standards such as SAML, WS*, O-Auth etc. there is now a great deal of interoperability between identity management systems.

Customers - Medium compliance. More and more organizations especially with e-commerce are supporting Open-ID and federated identity providers.

Vendors - same as customers

Law 6: Human Integration

"6. A unifying identity metasystem must define the human user as a component integrated through protected and unambiguous human-machine communications"

Key factors: meaningful to the user, predictable, unambiguous, allow for informed decisions.

Staff - Medium compliance. Where identity is provided within a company’s location this is there by default. Staff have a good idea that the identity information they provide is to the company, however this has been exploited by Trojans, hardware key loggers etc. For remote access compliance is low. Cheap technologies that verify the company to the user e.g. via displaying a user selected photo or phrase should be used far more than they are.

Customers - Low compliance. Very few business positively identify themselves to the customer.

Vendors - same as staff.

Law 7: Consistent Experience Across Context

"7. A unifying identity metasystem must provide a simple consistent experience while enabling separation of contexts through multiple operators and technologies"

Key factors: simple consistent experience across contexts and technologies, relying parties identify which identity information is required, user presented with identity "things" that contain the required information for their choice.

Staff - Low compliance. Relying parties tend to ask for everything and users typically have only one identity "thing" that they can provide which is the complete identity

Customers - as per staff

Vendors - as per staff


I like the Laws of Identity, although I would call them more principles or aspirations than laws currently at least in the enterprise. I think anyone planning or working on an IDM system could use a frank assessment of the program against the Laws to see how they could improve their system and thus reduce transaction costs by increasing transparency and trust in their identity system.

No comments:

Post a comment


Written by