Digital Identity for beginners: 1

Why you have a digital identity.

The fact is, you probably have a lot of digital identities. (1)

The people who provide all the information and services on the internet have good reasons to want to know some things about the people (you) who use them.

Sometimes a service provider only wants to know general things, like what countries their users are coming from. But when you want to use a service continuously, they need to recognise and remember you.

If your email provider couldn’t identify and remember you, it couldn’t deliver your emails. Facebook or Twitter couldn’t show you your posts if it couldn’t identify you. Dropbox would lose your files. Amazon couldn’t deliver your purchases if it didn’t know your address.

Many of the things you do online require trust. Money may change hands. You may have access to restricted material because of your job.

It may not be enough to just recognise and remember you. Another party may want to be assured they can trust you. Most of the ways to establish trust fall into one of three methods.

  1. Ask you to prove your identity.
    This is what banks and employers do. They want to know your legal, or ‘civil’, identity. Civil identities are provided by governments and are usually proven with documents like birth certificates, driver’s license and passports.
  2. Ask another, already trusted, party to be a reference or an intermediary.
    Often, this is what is happens when you shop online with your credit card. The seller doesn’t need to trust you, only the bank, who has already established your civil identity and can vouch for your ability to pay.
  3. Get to know you.
    For many free services this is as simple as giving you a user name and password. That they gave them to you is enough to trust that it is you connecting. They may ask for additional information such as your age and sex. But many service providers do not need your civil identity. They let you pick your own username and you could easily choose something like Slartibardfast42 if you wanted too.

So, when you use the internet you are usually identified. How you are identified and in what way changes form services to service. But when you are identified it is because selling or giving you all those service usually depends on three things:

  1. Identification.
    A service provider has to recognise you and maybe know something about who and what you are.
  2. Continuity.
    A service provider needs to remember you from last time; remember what happened, what you want and are entitled to, and where your stuff is.
  3. Assurance.
    A service provider needs to be assured that they can trust you.

We should also remember that these things work both ways. You also need ways of identifying, remembering and trusting service providers.

It is especially important that you can trust service providers will identify you only as far as they need to in order to provide their services. This is why many governments have enacted privacy legislation that controls just how much of your identifying information others can collect, use and share.

But you will understand the issues surrounding identity in the online world better if you understand that your digital identity, or identities, exist because most of the online services we use today could not be delivered without some way to provide identification, continuity and trust.

It is also worth noting that in every way that counts the way identity works the same way in today’s as it did before the internet.

In the next post in this series I will use some examples form the offline world to show how the three basic functions of identity – identification, continuity and trust – have been a part of our lives for thousands of years.


(1) I realise that most of the people who read this blog have a professional interest or connection to digital identity. Quite a few would wear the epithet ‘identity geek’ with pride. That cohort may find this series simplistic and uninformative. Still, I would offer the following comments for your consideration.

I am a firm believer that a hallmark of mastering a complex subject is being able to explain it to others in terms they can understand. So, in the first instance, I am writing this series as a kind of test for myself. Digital identity is a complex subject. Do I know it well enough to explain it clearly, without needing my readers to be proficient in the esoteric jargon of “IAM”? More importantly can I explain digital identity meaningfully without relying on a knowledge of computer science, and information technology? (Which, I may add, is different to an experience of information technology, which I do assume my readers have.)

The second reason I ask the identity experts to consider this series is that the “IAM space” is riddled with esoteric, ill-defined and contested jargon. Which, I hasten to add, is as should be expected for such a new field, and one in which there are so many interested and talented parties. There will eventually be, as there has been in all long lived disciplines, the codification of a body of shared knowledge and terminology. Some concepts we took to be foundational and essential will turn out to have been contingent and transitory. In these posts I have quite intentionally moved some common assumptions to the side in the hope of adding some original and useful thinking to the field.

IDaaS 2: Whom the God’s would destroy, they first send shopping.

Because IDaaS can bleed your organisation dry of knowledge and experience, the risk is you will go from being a smart customer of bad platforms to a dumb customer of even worse ones.

Right now IDaaS is a really good idea and a really nasty trap. A big-metal-teeth and pointy-sticks-in-the-pit trap.

The whole idea of identity in the cloud invites organisations to take a wrong turn at Albuquerque and become shoppers instead of producers.

There are advantages and opportunities to outsourcing some of the technology and some discrete services.  But digital identity services aren’t a single thing that you can just hand over to someone else.

Identity services are platform services. Which means a few very important things,

  1. Other service will depend on them. They are legacy generators of the first order.
  2. Identity services have not commodified. The stuff out there does not have what economists call cross elasticity of demand. One thing is most definitely not like the other and the costs of switching brands is high.
  3. Vendors will use platform lock-ins to protect themselves from competitive innovations while sucking all the $$$ they can from you. You will find yourself paying them every time you want to use your own data.
  4. Everything you do to enhance the value of the platform – mostly business integration and user experience – will make you more dependent on your platform vendor.

There are a few simple things to keep in mind when acquiring platforms (or platform services):

  • Platforms are not consumer goods. You use them to make things.
  • Bad (insanely profitable) platforms use IP law to make sure you pay rent on everything you build on them. They are cost multipliers.
  • Good platforms are built on commodified tools that keeps the market competitive and discourages rent-seeking multipliers.

Unless you are really and truly an SME then you will be an identity service producer. The bulk of your spend will not be on end-user services (self-service password resets for example), but on platform services that other systems will use. The bulk of your benefit will come from producing back-end services well and utilising them to enable organisational objectives.

Now on-site big-suite IAM vendors have been plaguing as with bad platforms for, well, ever. The real problem is that most IDaaS vendors are looking to compete with the traditional players by stealing their end-to-end we-do-it-all product philosophy. That is, by selling platforms.

In many cases they are worse. Because now they can put a meter on everything. And because they will bleed your organisation dry of knowledge and experience the risk is that you will go from being a smart customer of bad platforms to a dumb customer of even worse ones.

My point – use services to build your platform. Select commodified services where ever possible.

If you acquire IDaaS like you shop for a fridge….



(1)   Wile E. Coyote by InfinityandBeyond2 on deviantART

Hands in the air for the IDaaS ride

When I get to the bottom I go back to the top of the slide
Where I stop and I turn and I go for a ride
Till I get to the bottom and I see you again
Yeah yeah yeah hey

– Helter Skelter, Lennon–McCartney, 1968

IDaaS (1) is a next-big-thing for anyone producing digital identity services. Like most next-big-things IDaaS is,

  • a sub-species of an even bigger thing – the cloud (2), and
  • not really a single thing.

Gartner (3), for example, describes IDaaS as,

SaaS delivery and dedicated hosted instances of identity and access management (IAM) that require minimal or no enterprise on-premises presence of hardware or software.

Which is a pretty rushed definition both conceptually and stylistically.

Let’s just put it this way: I am happy to call something IDaaS if it provides functionality  at the end of a URI, and you can use it (in some way) to produce digital identity services. (3)

However, the important questions about IDaaS aren’t categorical – they are practical. How useful is it? What is it good for? How can we use it? Gartner’s summary of the current market is:

  • Benefit Rating: Moderate
  • Market Penetration: 5% to 20% of target audience
  • Maturity: Adolescent
  • Time to Plateau: 5 to 10 years

And just for good measure IDaaS is poised at the top of the whoooooooo-hoooo-hands-above-your-head sudden-death plummet into the ‘trough-of-disillusionment’ on Gartner’s proprietary hype-cycle curve (4).

At the same time there is a lot of market “impetus” behind IDaaS and a number of vendor’s (6) are aggressively developing IDaaS offerings.

Gartner’s predictions are remarkably measured. They say that,

By the end of 2017, 20% of IAM purchases will use the IDaaS delivery model, up from less than 10% in 2014. (7)

I think Gartner are being a tad conservative, and things will move faster than they predict. Still, the good news is that we have probably have enough time to get IDaaS right.

However, I for one do not want to twiddle my thumbs waiting for the vendors to sort it all out. Let’s get those practical questions asked and answered?

Next in this series: Consumer and organisational IDaaS – What’s the difference? Does it matter?

(1) IDaaS: Identity as a service. (On the highly unlikely chance anyone with enough interest in identity to read this doesn’t know what that mangled acronym stands for.)

(2) Personally I think we are almost at the point where the figurative “cloud” has replaced the more prosaic “internet”. But really the term cloud, as far as I am concerned just means the internet.

(3) Gregg Kreizman, Hype Cycle for Identity and Access Management Technologies, 2014, Gartner, 15 July 2014, G00263810, p. 17.

(4) Ibid.

(5) The conceptually tidy among us will note that there is a lot of fuzziness around resource-provider-consumer categorisation of cloud services. Often today’s services are a mishmash of IaaS (private and or public), SaaS, PaaS, on-site and every other flavour of production you can think of.

(6) There are IDaaS focused IAM vendors such as Ping Identity, Okta, Sailpoint or OneLogin. But it is worth noting that vendors of more traditional on-site IAM suites are making significant moves into IDaaS – Microsoft’s roadmap for Azure AD being a good case in point. Finally there are vendors in other software classes that see opportunities in IDaaS such as Salesforce.

(7) Gregg Kreizman, Magic Quadrant for Identity and Access Management as a Service, Gartner, 2 June 2014, G00260221

Square instances and round categories

In May 2014, Ian Glazer posted a draft of his Laws of Relationships (for Identity Management). In June he presented these at the IRM Summit. Ian is a member of the Kantara working group on Identity Relationship Management and he has ‘donated’ his Laws to that initiative. It is to Ian’s credit that he actually asked his audiences to turn on their ‘BS detectors’ and to challenge his thinking at will.

This post is the fifth in a series I am writing on the Laws.

According to Ian Glazer’s Laws of Relationships, relationships come in three types:

  • Immutable
  • Contextual
  • Transferable

Taxonomies make me nervous. They are inherently arguable. They generate monsters at the edges. When people don’t understand the rule, taxonomists usually respond with more complicated stipulations. Often the cognitive overheads those rules impose outweigh the utility they provide. (1)

I don’t see why we need a taxonomy of relationships. These assertions can be made without requiring them to be categorical. Relationships may be immutable contextual or transferable. So far, so good.

So let’s forget the categorical perspective for a second. To observe that relationships have mutability, context and transferability is to imply an important principle.

A relationship can have its own characteristics. (2)

This principle follows from the types Ian has listed. But it also implies a lack of coherence that has to be resolved if relationships are going to be modelled meaningfully. Please bear with me…

1: Immutability

“Obviously, there are some relationships that do not change.  A specific widget can only be manufactured once and immutability of the relationship between the widget and the manufacture provides useful contextual data.”

But…. is it better to say,

a) some relationships don’t change, or

b) some characteristics of relationships don’t change

The idea of mutability seems fairly simple in the case of a manufactured product. But what about a slightly more complex example.

Say I started a business with my sister. My familial relationship with her is immutable. My business relationship with her can change and is mutable.

To apply mutability coherently to relationships we must atomise them. We can’t talk about a relationship between two parties inclusively. That is, we can’t treat relationships as  collections of facts about the connection between two parties. We have to limit relationships to the point where each distinct fact is a “relationship”.

On that view, I probably have hundreds of ‘relationships’ with my partner, and almost as many with my employer.

2: Contextual

Some relationships aren’t active and usable until conditions are met. For example, my Canadian SIM card only works when I am physically in Canada.

This describes conditional relationships, not context.

But if we keep context in mind for a minute we should remember that context is so general as to include  mutability and transferability. It invites confusion to list context alongside things that are instances of context.

3: Transferrable

Some relationships can be delegated to others on a temporary basis and, in some cases, one party in a relationship can be replaced with another.


Let me ask this: What is being transferred?

If I give you my credentials and permission to use them on my behalf, then from inside any identity system, nothing has been transferred. (Outside – in the meta-system that includes our personal relationship I have transferred my identity to another, and only my relationships as a corollary.)

If I use the normal function of an identity dependent service to delegate entitlements to another, have I transferred rights or the relationship?

The point I am getting at here is we can transfer rights and entitlements. We can’t transfer identity. We can allow others to act as our proxy – an old concept that predates digital identity services by centuries.

I wonder what additional information or function do we get by talking about the transfer of relationships.

When we look at how we can apply these characteristics, coherently, consistently and meaningfully to a range of relationships, we start coming across ontological and epistemological questions that need to be sorted out. In particular…

  • What are the intrinsic (definitive) characteristics of any relationship, and what are the extrinsic characteristics?
  • What can be encoded explicitly into to data about relationships, and what is implicit, or derived, information?

So, no. I am going to reach for Occam’s razor and cut this one out. I can see no meaning for the transferability-of-relationships entity that is not redundant…. unless….

I am catching a whiff of the engineer here.

We shouldn’t forget the informing project – Identity Relationship Management.

That project implies that relationships should not be informational ghosts in the identity management machinery. We should model relationships explicitly and build machinery – protocols, data stores, formats, algorithms, that incorporates relationships as a real thing into digital identity services. (Remember the Actionable Axiom.)

If you are seeking to make something. It is appropriate to consider what that thing should contain, how to describe it and how it will function. When I look at mutability and transferability as design parameters I have less issues with them.

If however, mutability and transferability are design parameters of relationships, then relationships have become something very concrete, very limited and very formal for digital identity services.

For example, from this perspective a right or entitlement is simply a type of relationship. (Ah, we are back to taxonomy.)

If that’s the road we are going to take then there will be a whole host of general characteristics that we may want to consider – not just mutability and transferability. For example duration is going to be just as relevant. And there will likely be more.

In the meantime I will close by suggesting that;

  • we should define the intrinsic characteristics of relationships functionally not categorically,
  • enumerating definitive characteristics for relationships is an act of formal reification,
  • there will be more candidates than mutability and transferability,
  • context is an important factor in the design of digital identity services but it is not a characteristic of anything – ever,
  • change contextual to conditional and my objections go away, and
  • these are very good things to consider and should not be overlooked.

(1) Classes are cognitive models. We talk and write about them in formal object-predicate terms. But we think about them as prototype generators and assign membership based on decidedly fuzzy logic. And not the fuzzy logic of probability either. We use the unquantifiably vague fuzzy logic of intentionality and value. (I recommend Women, Fire and Dangerous Things, What Categories Reveal about the Mindby George Lakoff) Formal object-attribute categories only work in formal state machines where intentional indeterminacy can be removed. That works best for atomised, one-to-one relationships. We cannot assume from the simplest case that formal categories can be constructed for a complex and constantly changing network of relationships.

(2) Given that this post is  discussing a set of “Laws of Relationships”, I could argue that that this is a ‘missing’ law. It is a common thread of my multi-post critique that laws and axioms work best when they are clearly generalised and complete. As much as possible they should be highly generalised first principles upon which others may build.

Unfinished Business – Scaling Relationships Part 2

In May 2014, Ian Glazer posted a draft of his Laws of Relationships (for Identity Management). In June he presented these at the IRM Summit. Ian is a member of the Kantara working group on Identity Relationship Management and he has ‘donated’ his Laws to that initiative. It is to Ian’s credit that he actually asked his audiences to turn on their ‘BS detectors’ and to challenge his thinking at will.

This post is the fourth in a series I am writing on the Laws.


This is post is an addendum to my last post which discussed Ian Glazer’s first Axiom from his Laws of Relationships.

That axiom states,


Clearly the future holds more of everything for identity management. Relationship management much be scalable in terms of the number of actors, relationships, and attributes. But those three axes are insufficient, we must also keep in mind scalability of administration.

In my previous discussion I stuck to the actors-and-relationships part of this proposition.

But Ian also lists attributes and administration as factors of relationship management that must scale.

I don’t think they are axiomatic per se as I don’t see them as definitive, or as foundations principles from which other functions or concepts are derived.

I do think they matter and are worth considering.


The administration of digital identity – and all that is entailed – is a discipline in its own right. And depending on the scale of your organisation, or the scope of the technology you are developing it can present a very complex set of challenges.

It is also a game in which I have quite a bit of skin. (1)

So allow me to cut straight to the chase.

Scaling administration is not a technical problem. It won’t be solved with new protocols, languages, standards, or software systems (though such things won’t hurt).

Scaling administration is first and foremost a business problem and requires a better management approach. You have to structure organisations to manage identity as you would any other capability.

If you are big enough to be an identity provider then you are too big to keep the management of digital identity in a single-function box. (2) Digital identity services are too complex in many organisations to be regarded as a simple back-office end-to-end system function. If you do that, your ‘administration’ will never ‘scale’.

Digital identity services need to be based on platform systems and services that are decomposed into discrete functions with effective operational independence.

In a factored functional business architecture for digital identity services each function,

  • is responsible for a defined business object or activity,
  • produces and maintains a set of data objects,
  • provides a set of defined services to the other capabilities,
  • collaborates with the other functions to produce cross-functional identity services.

Factoring identity services to reduces complexity, increase flexibility and scalability, and allows us to better organise the management of technology, processes, skills, responsibilities and budgeting.

Functional modularity allows the production of services that can be composed and tailored in different ways to meet different business requirements.

Services that have been too complex to manage effectively, such as entitlement provisioning, can be composed of more simple services and delivered through the orchestration and coordination of well defined sub-processes.

Such an approach clarifies governance and security requirements. It identifies the business objects, data and services for which each production cycle is responsible. It makes compliance with separation of duties, privacy, and repudiation easier by reducing the data access required to meet production needs.

Following Gartner, the Cloud Security Alliance, NIST, and a bunch of peer-reviewed authors (3) I advocate a four-capability production model:

Identity Information Management

Identity information management is responsible for the production of identity as a business asset.

It ensures that identity data is accurate, safe, controlled and appropriately available through technical and business services.

It defines the digital identity lifecycle and ensures that digital identity data reliably reflects the currents state of each identity holder’s relationship with the organisation.

Entitlement Management

Entitlement management is responsible for the production of access entitlements as a business services.

It discovers and analyses data about identities, identity domains, business roles, organisational affiliations, and application and service roles and privileges. It creates and maintains entitlement packages and access control models that define how identity holders may access resources.

Access Management

Access management develops and maintains the infrastructure that provides authentication and authorisation services in access transactions.

It is also responsible for planning and implementing access control models, security policies, that are inputs for entitlement management.

It implements specialised services such as adaptive access control and versatile authentication services, mobile access services and token translation services.

Identity Analytics

Identity analytics monitors, analyses and reports on the use of identity across the University. It has two distinct areas of responsibility.

It provides business intelligence on the use of identity to ensure the operation of identity services is aligned to business requirements and inform planning.

It provides forensic analysis of improper uses of identity and ensures compliance with important governance objectives such as separation of duties, privacy, and repudiation.

The premise here, and I think it is sound, is that digital identity services are no different from any other in that once you have identified your business objects, you have to organise resources to produce them.

You need a production model that defines,

  • services
  • activities
  • processes
  • business objects
  • collaborations

When you consider the skills, information, processes, tools, methods and so on required to effectively execute – at scale – the capabilities I defined above, I hope you will agree you are unlikely to find them all rolled up and competently applied by one team, using one product funded out of one cost center in your ERP.

Producing and managing digital identity services – especially at scale – requires a cross-functional coordination of a range of professional capabilities – master data management, enterprise integration services, access management and security services, business intelligence and process management, and so on.

Anyway, the end of my vaguely ranty brain dump on administration end in this plea:

Please don’t think of administration in terms of some system jockey sitting in front of a management consoles choosing settings while a software engine automagically ‘onboards’ and ‘provisions’ and banishes production complexity to a set of cleverly crafted algorithms.

Scaling the management of digital identity is business problem, it will be for some time to come.


When asking about how attributes need to scale we need to be careful. There are actually a number of discussions in the offing. We can discuss what facts need to be collected. And we can start thinking about how they should be structured. And clearly the Laws of Relationships, which provide the foil for this post, is make the claim that attributes should describe relationships as well as agents. (Which in most implementations is already the case to some extent.)

At the outset I have to declare I don’t think scale is the most pressing issue. I think like administration most organisations will get more out of managing the production of attributes and often, as a result, reducing them. (Thanks to a friend of mine (4) who first showed me the boston-ish box I am about to share with you.)

All use-cases for identity rely on the existence of digital identity data. Some of which is encoded in attributes.

Reducing the cost and complexity of producing those data is a priority for the delivery of high quality identity services.

Ideally an identity information management capability will apply master data management principles identity data to ensure identity is maintained as a valued business asset. A master data approach to identity requires the establishment of a system of record that can provide a canonical, authoritative representation of every identity holder in the University.

However, the existence of a system of record for identity data does not automatically address the factors that drive the cost and complexity of maintaining identity data as a master data asset.

There are two factors that directly affect the complexity of managing identity within a system of record:

The number of attributes required to canonically represent an identity in the University, and to adequately support entitlement management activities.

The effort, and with it the cost, of using identity increases with the number of managed attributes.

The number of systems of entry where identities may be created. (5)

The cost and complexity of managing identity data increases with the number of systems of entry. Multiple systems of entry also increases the costs and complexity of managing identity attributes.

The product of these factors may be used to classify four basic approaches to managing identity data within an organisation:

Light Mastering
Few managed attributes and only one system of entry.

Heavy Mastering
Many managed attributes and only one system of entry.

Light Reconciliation
Few managed attributes and more than one system of entry.

Heavy Reconciliation
Many managed attributes and more than one system of entry.

Identity StylesThe thing is, identity is not just about identification and assurance (access, authentication, authorisation, etc). It is equally about continuity and integration. Identity gives system a memory, and memory allows a relationship.

So it doesn’t matter how cleverly the information that oils an access request is produced. We may get some automagical big-data web-ontological wonder-protocol that can reliably bind, verify, and assure on the fly by simultaneously juggling shards from seven different social networks. We still have to collect and map our constituents, as identity providers and as service provides – and equally as communities.

I have seen first hand how how attributes grow when directories – and as a corollary identity records – are the ungoverned chew-toy of every system engineer and business process designer in the joint.

For most organisations the real problem is not how to scale attributes – but rather how to get rid of the buggers.


There, I’ve said it. The proverbial elephant.

Generally the more attributes, the less privacy – or at a minimum, the greater the risk to privacy. And incidentally, the greater the regulatory constraints in most jurisdictions.

On privacy grounds alone I am not convinced highly scalable identity attributes are a good thing.

Rather I would advocate for better governance, smarter use, and constraints on the growth of attributes.

I think we need to file this one under ‘user-centric’ identity management and opt for the kind of approach the Open Group’s Jericho Project advocated.

What we need are flexible and governable attributes.

Or to rephrase this in terms friendlier to Ian’s initial vision, scaling identity attributes in a ‘big-data’ world of relationship networks needs mechanisms that can intelligently filter facts about identities – and Ian covers this in his laws with the principle of ‘consent’.

We just haven’t got up to that one quite yet.


(1) I am currently leading an initiative to define a management framework for digital identity service in higher education. Higher education institutions, arguably, have the most complex identity management profiles there are. (So long as one does not confuse size with complexity. For size, government identity services win hands down – but surprisingly the management of civil identity and attendant services is relatively clear cut). A number of Universities in my region are collaborating on the framework and I hope we can publish it soon. Part one of this post is an extended summary of three teaser posts I have published on this blog.

(2) Size is an important caveat for my ‘argument’. Single service providers (relying parties or simple account providers), SMEs and other small scale entities are often in the identity game by virtue of poor systems. Personally I would recommend that below a certain size, you would be best talking to a good IDaaS provider.

(3) There are some IAM software tools and services out there that are well factored – and aren’t just adding features to directories – but my lips are sealed. (If, dear reader, we ever find ourselves sharing a beverage sometime I shall be happy to share.)

(4) jeff kennedy (LinkedIn) A enterprise architect, identity specialist and firm friend. (Blog. Twitter.)

(5) I include in this ‘systems of entry’ that are external to traditional WAN-based identity domains, and which may be providing identity over federated identity domains, or directly from SaaS based IdPs over protocols such as OpenAuth.

Oh What a Tangled Web…

In May 2014, Ian Glazer posted a draft of his Laws of Relationships (for Identity Management). In June he presented these at the IRM Summit. Ian is a member of the Kantara working group on Identity Relationship Management and he has ‘donated’ his Laws to that initiative. It is to Ian’s credit that he actually asked his audiences to turn on their ‘BS detectors’ and to challenge his thinking at will.

This post is the third in a series I am writing on the Laws.


Ian Glazer’s Laws of Relationships contain two axioms about relationships. The first is, in Ian’s words;


Clearly the future holds more of everything for identity management. Relationship management much be scalable in terms of the number of actors, relationships, and attributes. But those three axes are insufficient, we must also keep in mind scalability of administration.

This axiom clearly reflects a point from the Kantara Pillars of Identity Relationship Management. (1) Which include the following ‘technical pillar’:

INTERNET SCALE over enterprise scale

Today’s users access secure systems not just on premises, but in the cloud and via the Internet, any time, day or night. Today’s users are not just employees logging on at work but also partners, customers, and devices signing in from anywhere. As the number of users grows exponentially, modern IRM systems must be able to accommodate hundreds, thousands, or even millions of additional identities instantaneously, achieving a scalable volume that was neither possible nor needed for the enterprise, but is essential in an Internet-connected, consumer-facing world.

These are compelling assertions. They chime with the expanding role of the internet in daily life that we see all around us. It is unproblematic to posit that scalability is an essential or definitive characteristic of contemporary digital identity. The real discussion starts with what scalability means to identity, and how it might work.

One of my axioms for digital identity is more basic,

Digital identity exists to allow relationships to be mediated by machines.

The reason I come back to this axiom so often is that it reminds us that relationships precede access control. Access control is just a use case. Digital identity doesn’t need to exist at all if there is no relationship to manage.

Ian is correct to equate identity and relationship management. A corollary of that equality is that scaling digital identity means scaling relationships.

So, to understand how identity scales we need to understand how relationships scale. And because relationships always involve at least two parties that means thinking about networks.

When we access a service, we are establishing or enjoying a relationship with the provider of that service. So let’s say have an account with a bank….

 isolated identity

Of course that relationship is likely to be relevant to another relationship. Your employer, with whom you have a different relationship is going to need to understand your relationship with the bank so that it can fulfill its obligation to pay you…


See where we are going?

We exist in a vast web of different relationships, which may be connected to each other in different ways. Relationships can take all kinds of forms. If we think about it, each of them is a section of a network.

relationship network

Which by the way, brings me to my second “axiom” of identity.

Identity is a function of networks.

Even when the relationship is a simple isolated two-party affair, it is still a network. It’s just a very simple one.

isolated identity

What the internet has done is make it very difficult to ignore the network. (2)

Keeping the network in mind it should be easy to see that for identity, scaling is not a matter of quantity. Networks can grow in different ways.

We could look at scale as the growth of different kinds of relationships between the same parties…

Relational Scale

Or are we trying to scale the identity or service domains….

Relational Scale 2

Or everything at once….

Relational Scale 3

As I said above, the scale problem has been around since we started connecting systems together. Historically we have become very dependent on X.500 directory technology to solve the scale problem.

What isn’t often considered is that directories are a topological solution. They take the chaotic problem of scaling networks of relationships and attempt to reduce everything to a single, star, topology (3)

center of all

I think we don’t think about the topological position of directories themselves, because we tend to focus on the internal topology of each directories containers. But at the architectural level, the star topology is pretty much the X.500 stock-standard answer to scaling digital identity. What we need to remember in passing is that the directory-at-the-center topology however didn’t remove, so much as mask the topological complexities of digital identity. (4)

And in the end it didn’t matter when the next solution to scale came around – federation…

Fedaeration Scale

Because we are back to fluid merging topologies on a meta-scale – and everything old becomes new again.

Let’s recap…

  • Digital identity allows machine mediated relationships.
  • Relationships, and therefore identity, are a function of networks.
  • Networks don’t just grow in size, they also change shape (topology).

And let’s reconsider the nub of Ian’s axiom…

Relationship management much be scalable in terms of the number of actors, relationships, and attributes. But those three axes are insufficient, we must also keep in mind scalability of administration.

There are four factors Ian lists as subject to scale…

  1. Actors
  2. Relationships
  3. Attributes
  4. Administration

I think I have done enough spade -work in this post to jump directly to a couple of observations…

From a network point-of-view actors and relationships are indivisible. You can’t have one without the other. The quantitative growth of more actors of the same kind, or of more relationships of the same kind…

Relational Scale 2

…is a trivial case. What matters is the ability to model and manage meaningful changes in the topology of networks of relationships…

Relational Scale 3

In the realm of identity relationship management (if we are going to make that a thing), it is this second ‘graph’ we should keep in mind when we talk about scaling digital identity.

Finally it is worth asking how our legacy of directories-everywhere constrains the design of topologically sophisticated services.

Constraining the topology of the identity domain is actually a smart choice. Star topologies are powerful simplifiers.

Unfortunately X.500 actually applied a star topology to the communications and security network and not the relationship network (roles, entitlements, cohorts, authorisations). The freely unfolding network of relationships is still there in all its polymorphic glory, it is just occluded (and ossified) inside our directories. (5)

In summary, the consequences of Ian’s first axiom are that digital identity needs to move into the realm of ‘big data’ and MapReduce-like production capabilities. Because making digital identity work at internet scale is that kind of problem – and even more so the task of making digital identity relationship services technical feasible.


But, you ask through this lame rhetorical device, what about attributes and administration?

Well there’s this…

Ian’s axiom is a little untidy, ontologically speaking. The questions about what it means to scale attributes and administration are of a different order. But they are interesting, and this post is already longer than I expect most people to read. So I am going to leave them for an Axiom 1b discussion.



(1) Well worth a read if you are interested in the future of identity. However, I want to disclaim a strong allegiance. The capitalist weltanschauung  exerts too strong a hold on the author’s mind for my taste. The bit about ‘top line revenue’ and ‘operating expenses’ is a sour, small-minded note in what could have been a visionary document. We are talking about how the world works here.

(2) It isn’t the internet per se. It’s simply networks. The first big transformation in identity, from isolated to centralised architecture was a response to the first organisational LANS.

In fact the evolution of digital identity architecture from isolated, to centralised, to federated to domainless / user-centric exactly mirrors the growth of networks.

If you understand that, then you will understand that digital identity has been scaling from the start. Production systems for digital identity services have been shaped by the need to scale.

(3) Centrum omnium sum – I am the center of all things.

(4) How directories became the carpets-under-which-awkward-topologies were swept is an interesting history – but there really isn’t room here for what would be a massive digression.

(5) Another – more nuts and bolts – perspective on the problem of legacy and directories is provided by Michael Prompt (Radiant Logic) in a series of posts – also in response to Ian Glazer – that starts with Why Kill Identity Management When You Can Virtualise IT? Michael here is focused on a particular technology strategy – virtual directories – but he casts some useful light on problems I have touched on here. I highly recommend the series – with no implication I recommend Radiant Logic’s product,  about which I know little.

All your identity are belong to us…

“Integration will drive service providers back to centralised identity.”

I was reading a post on the IDnext site (about platform wars in online education) when I came upon a deeply troubling passage (1).

It’s the pot-of-gold at the end of the efficiency rainbow that bothers me the most:

…the Holy Grail is to have a persistent digital student identity.


In no particular order this makes me wonder the following…

My domain is bigger than your domain…

Digital identity is inexorably bound up with the problem of cohorts.

As far as digital identity is concerned identification is simply unique selection from a group. (Including the more nuanced case where the group itself also needs to be identified).

The terrible, broken thing about digital identity, is that most identity producing and consuming organisations use groups to classify and define identities and entitlements. After which endless process of slicing, dicing, and recombining rumbles on until there are thousands and thousands of different cohorts that no one really understands.

The ‘painful’ issues Dias d’Ullois all flow from yet another cohort design problem. In this case it is a mismatch between the service and identity domains. To create a ‘persistent student identity’ in this case means to redefine the identity domain so that an identifier can select from a broader cohort.

It also means the rule that establishes the group changes from having a relationship to the same school, to being a student (in any school).

The persistent student identity appears to be a bet on identity classification – by which I mean ‘student’ is a type of identity, not a role or relationship that an identity can be in at one time and not at another.(2)

The corollary of this is that the persistent student identity is likely also a bet on extended centralisation over federation. (User-centric is nowhere is sight.)

Federalists are not centralists…

In the world of technology, especially in the sub-disciplines of network engineering and security, access control is the ‘holy grail’ of identity management. Access is the paradigmatic use case for digital identity services, and all problems tend to be viewed from that perspective.

Dias d’Ullois’ ‘holy grail’ brings to the for the ‘other’ use-case for digital identity services: Integration.

Business integration (Dias d’Ullois’ focus), service integration, data integration – it doesn’t really matter. Identifying data is more often than not an essential requirement of functional integration.

Which leads us to the unfinished business of identity federation. To date it has been pretty effective at overcoming the domain problem for access use-cases.

It has proved particularly weak for integration use-cases.

What we see from the integration camp is a continual push back to centralised architecture. And this usually means staking an ontological claim on an identity class, backed up with a new more global identifier.(3)

Identity = Identifier = Credentials = Account = Roles = Groups = Entitlements…. Not!

Another thing that bedevils and complicates digital identity management is that things that are actually different have overlapping functionality. And as a result many of these mechanisms are often thought of as roughly synonymous.

To me calls to reclassify identities and create ever more exclusive domains are both and effect and a cause of these confusions.

Boy, Boy, Crazy Boy….

There is an unacknowledged gang-war going on between the Access-Sharks and the Integration-Jets.

Identity is being innovated into two directions at once.

Personally I think the closest thing I have seen to rapprochement (though it comes out of the access camp) is the work the Open Group’s Jericho project undertook.

Mainly because it set off after a technically viable distinction between the identity domain and the service domain, without trying too hard to shore up an evermore complex set of federation technologies.

The end-game is domainless identity.

Which I hope entails no longer dealing with cohorts by creating more and more identity domains, as if they were…




(1) The article is by Martin Dias d’Ullois. The section I am responding to here reads as follows (the italicised underlines are my emphasis),

The issues around digital identity remain painful. When a school changes its electronic learning platform, all users get new digital identities. As a result, all the history and profiles that have been gathered are lost. This is a nuisance, especially in the domain of digital licensing; students purchase a licence, switch schools and get new digital identities. Once given new identities, they lose their access to their previous licence. How hard can it be to address this issue? Ever since schools have been in “business”, they have identified, registered and administered students and teachers, haven’t they?

This issue is being debated even within the circles of government that are designing the new national digital identity for all Dutch citizens. The people who are designing this new digital identity claim that schools do not identify and register students well enough to deserve high levels of confidence in the associated digital accounts. To me, this sounds contradictory. After all, the government spends billions of euros on issuing diplomas based on the administration done by these very same schools.

Since there is no persistence as yet, many efforts in the digital educational domain are devoted to tackling the resulting problems. A lot of personal information is shared in the form of attributes, frustrating many people as the exchange of such vast personal datasets entails a vast number of legal implications and paperwork. The pending European privacy laws are making matters even worse for the market players, as they have to take huge responsibility and potentially face heavy penalties issued by the watchdogs.

Holy Grail

At the moment, the Holy Grail is to have a persistent digital student identity. In 2013, a project was started to address this issue. Hopefully, this project will generate much interest among the parties involved, as the timeline is already showing. One of the most challenging issues in this project appears to be teamwork, while good governance would help to speed things up. Unfortunately, our legislators do not have a deep understanding of the importance of these issues, so they are not designing any policies, thereby fuelling the struggle. However, I am convinced that somewhere in the near future, persistence will be implemented.

(2) It is important to note in passing, that a characteristic of defining cohorts by identity types is that it is exclusive. Once defined as a student, other types of relationships that might exist – even between that same school and student, are excluded from the ‘student’ identity domain. To integrate other relationships now requires another layer- be it federated authorisation, identity ‘brokering’, or yet another meta-identifier.

(3) Under rigorous legal protection to limit it to a verification function, this is entirely appropriate for the civil identity domain, and well implemented is very useful. New Zealand’s RealMe is an interesting example.


Ain’t Nobody Here But Us Students

Lately I have been helping some people negotiate a novel use-case for digital identity: Online invigilation. This has turned into an interesting case-study in horseless-carriage (1) thinking.

The Scene.

University’s are being challenged by the internet, online learning and the rise of new providers like Udacity. Online courses can attract student numbers that traditional labour intensive teaching can’t handle. It’s too expensive to mark 100,000 assignments by hand. You need automated assessment. It is cheap and scales well. It can also be relatively easy to cheat.

That presents a real problem for universities. The reputation of the qualifications they provide depends on the rigour of their assessment processes. If it’s too easy to cheat, and too hard to catch the cheats, the results become meaningless – even if those results carry the imprimatur of Oxford or MIT. To compete in internet-scale education markets, universities need to use automated assessment. To retain the value of the qualifications they issue, universities need to prevent cheating. In many universities this has problem has been interpreted as a need for automated invigilation.

Place the eyeball in the hopper…

To those trying to stop online cheating (where it involves fraudulent identity), biometrics might seem like a no-brainer. We have all seen the palmprint and retina scanners on TV and in films. iPhones now come with built in fingerprint scanners. Surely this is now a useable technology with the potential to solve the online cheating problem? (2)

Unfortunately no. Online cheating has two characteristics that completely alter the nature of the problem,

  1. The exam environment (and by inclusion the sensor environment) is uncontrolled.
  2. The fake candidate is an accomplice. They have the full cooperation of the genuine candidate.

The environment matters because the information environment extends beyond the security environment. The security environment stops with the hardware – the keyboard, mouse, screen, etc. But information from the assessment can be seen and heard by anyone in the room. It is possible to get the information without interacting with the system.

The complicity between the legitimate candidate and their accomplice means the accomplice has access to everything the candidates has, including their body.

Failing to understand these points leads to silly measures.

It is common for online assessment to use software that locks other applications on the candidate’s computer. This is to prevent them from keeping a search page or a PDF open during an assessment.

I have actually heard it suggested that a candidate could be required to periodically film the rest of the room to show no one was assisting off camera – tricky if you are using a 27inch iMac.

Of course continuous verification techniques, such as repeated sampling of the candidates face or analysis of their typing patterns during a session are reasonably commonplace in commercial offerings.

Complicity and an uncontrolled environment make it pretty easy to get around such measures…

Biometric Exam Circumvent

Even if you figure out how to prevent direct-cable or over-the-network mirroring, for every possible end-point device, it doesn’t take a lot of imagination to hack the physical environment without touching the system at all…

Environment Hack

These are just simple schemas. But the principle is sound.

The candidate can provide all the data, the requisite face, fingerprint, and typing kinesthetics. Every assessment can be filmed and keylogged in its entirety for reactive or statistical auditing. The system can work perfectly because the system itself was never subverted and was allowed to function as intended.

It doesn’t matter if you use physical or behavioural biometric identifiers, or some hybrid of normal multi-factor authentication and biometric verification.

Stereotypes are not just a race-thing

People don’t just stereotype other people. We stereotype everything – pets, furniture, TV shows, food. Patterns exert a huge influence over our minds because they are so incredibly useful.

We stereotype digital identity too.

The paradigmatic use-case for digital identity services is access control and theft prevention. In normal security, when identity theft (deception) occurs it is usually as a means to access to a resource. The function identity services perform to prevent fraudulent access is authentication.

Cheating on a test is not a case of fraudulent access, it is a case of deception. The function we need an identity service to perform to prevent deception is verification. (4)

I know of no current technology that can reliably verify where the knowledge is coming from in an online assessment – when the assessment environment is uncontrolled.

The idea that there must be a way to use technology to prevent online cheating persists – and some vendors stake their livelihoods on it. (3)  And I have seen how easily people confuse  verification and authentication. People who shouldn’t; highly tech-literate people with years of systems development experience.

This suggests to me that access control is the paradigmatic use-case for digital identity.

Access control has so stereotyped our thinking, and exerts a strong horseless-carriage effect, that it degrades our ability to think clearly through other use-cases for digital identity.



(1) Horseless-carriage thinking is when our understanding of something new is coloured and limited by the thing it is replacing. When people first started to make automobiles they were understood in terms of the horses and carriages they were replacing. It took a while for them to becomes ‘cars’. I discuss the consequences of horseless carriage thinking in Moon Towers and Radiated Libraries.

(2) I am not going to go into the ins and outs of subverting biometric sensors – and the often gruesome measure depicted in film. In reality biometrics are not vulnerable to literal ‘hacking’ measure. Moreover, as this post discusses, the cheating use-case doesn’t require violent measures at all.

(3) There are of course other alternatives. One can rethink assessment methods. Multiple choice examinations and short answer assessments are simple to cheat. There may be different ways of reliably establishing a student’s competency that lend themselves to more reliable automation. Much the way the plagiarism detection software has amplified the ability of human examiners to detect that kind of cheating. We may need to use a resampling technique to discourage rather than prevent cheating. These questions, while interesting are an aside. My interest is in how such basic limitations on online assessment go unrecognised, and why a faith in the viability of automated solutions persist.

(4) In the hollywood movie scenarios of secret facilities protected by retinal scanners these use-cases overlap somewhat. But the imposter, like the password hacker, is still deceiving to gain access. The exam cheat is not deceiving to gain access. They have access. Access is the least of their problems. And as they are an accomplice to the legitimate candidate, anything we do to block the deceiver’s access would also restrict the candidate’s access.

To Bind or Not to Bind

In May 2014, Ian Glazer posted a draft of his Laws of Relationships (for Identity Management). In June he presented these at the IRM Summit. Ian is a member of the Kantara working group on Identity Relationship Management and he has ‘donated’ his Laws to that initiative. It is to Ian’s credit that he actually asked his audiences to turn on their ‘BS detectors’ and to challenge his thinking at will.

This post is the second in a series I am writing on the Laws.

To bind or not to bind, that is the question:
Whether ’tis nobler for a transaction to suffer
The slings and arrows of outrageous incompatibility,
Or to take up RFCs against a sea of standards,
And by opposing end them? To assure, to trust;
Once more; and by a token to say we end
The heart-ache, and the thousand fraudulent assertions
That authentication is heir to, ’tis a protocol
Devoutly to be wished.

Ian Glazer’s Laws of Relationships contain two axioms about relationships. The second is, in Ian’s words;


Relationships must be able to carry authorization data. This can enable a “thing” to act without having to go back to its back-end server to determine the context in which it can operate.

What it means

The way I read this axiom is this;

Information about relationships, must be available in an access transaction, and must be sufficient to decide the requesting party’s entitlements.

I have the made following assumptions here – but I think with reason.

1: Relationships are a thing.

Normally I would say all identity information, by definition, encodes something about relationships, even if only implicitly. And all identity information should be ‘actionable’. Yet this isn’t just covering the basics. Ian adds a very specific stipulation. I’ll call it ‘first pass authorisation’.

In this axiom, relationships does not just mean the state of affairs that pertains to an association between two parties – information about which might be encoded in various ways on either sided of a connection.

Rather the axiom, appears to be predicated on the separation of relationship and identity as distinct objects for identity systems.

2: It’s about the transaction.

The primary intention in the axiom is the access transaction. And it is not simply stating that an access transaction should be able to authorise. The description at once explains and proscribes an alternative means to reach that state.

This axiom mandates that relationships are defined, and presumably built, to allow an authorisation heuristic that is more sophisticated than equivalence matching on a set of attributes. And, presumably, more versatile.

3: It’s probably also about the domain

I am guessing now, but the only reason I can think of to stipulate such a strong constraint is to achieve domain independent authorisation.

That allows for the possibility authorisation without pre-existing trust relationships. Because, relationship information, and as a corollary entitlement information, is usually ‘encoded’ in domain memberships. And that is usually done asynchronously to the access transaction. Those very low latency short-loop registration and provisioning process of the kind we see in consumer cloud services are still a separate action.

Even most common federation implementations still do quite a bit of back-end ETL batch-file user-pumping. And when everything needed for authorisation is actually packed into the assertion, federation still equivocates between identities and relationships… somewhat. Usually it involves no more than adding affiliation states. In the end federated access is still domain dependent. If the axiom was simply restating a principle of federated access it would be a (redundant) prescription for federated role-based access control. And I don’t think it is.

We can’t infer any implementation imperatives from this. For example it may or may not follow that we need a new “semantic identity” architecture with standards for discoverable relationship meta-data. Likewise it does not necessarily prescribe whether a relationship is presented, compiled or calculated in the transaction.

And one last question that interests me greatly. Does this axiom imply we need to stop pushing data to a relying party, and instead allow the relying party to pull in the data it needs? It seems to me that a requesting party couldn’t possible know what data to push to achieve a ‘one pass authorisiation’.

Bob Blakely has an interesting paper on pull-based architectures,(3)

The Merging Architecture of Identity Management (PDF)

In 2012 Thomas, Ivonne, and Christoph Meinel  published a paper, on domain-dependent Identity:(4)

From Domain-Based Identity Management Systems to Open Identity Management Models.

Well worth a read, and in my opinion it makes a lot of observations quite relevant to the problem of creating ‘information sufficient’ transactions.

Comments on the formulation.

1: If we keep “Actionable” it should be one of the Laws

This principle (along with axiom 1) is not of a different order to the four laws. Strictly speaking axioms should be obvious, self-evident propositions from which arguments proceed. I allow that Ian is using axiom a little loosely, but I really don’t think the proposition is significantly more obvious than any of the other principles he outlines.

If there are to be axioms for relationships I think they should directly address what a relationship is.

 2: The object is confused.

To say that relationships carry authorisation data is not quite right.  It appears to assert that relationships must be actionable when what is actually meant is that information about relationships should be actionable.

This may seem pedantic to software engineers and programmers naturalised to the reification of information as objects, and who are comfortable with using these kinds of metonymies. But these Laws are better served if they are intuitively accessible to a range of audiences, and some thought needs to be given to weeding out unnecessary engineering and computer science idioms.

3: The main idea is described and implied, not stated.

As I indicated above, the axiom is asserts a specific requisite of ‘actionability’ and a specific action: That there is sufficient information to authorise a requesting party.

The statement should include the word ‘sufficient’ and clearly state the action.

Do we have it covered already?

Out there, in the built world, there is already a lot of information being produced and pushed around to represent relationships between all kinds of identities. For example the Internet2 OrgIdentity Schema includes an Affiliation attribute.

<!ELEMENT Affiliation (Faculty|Student|Staff|Alum|Member|Affiliate|Employee|Library Walk-In)>

Many digital identity records already include these kinds of relationship attributes. Most directories have something like a customer and employee attribute – or an affiliation attribute that can take the values customer and employee. It is safe to assume those attributes are there allow a relying system to make authorisation decisions. That is, they are meant to be actionable.

Is “Actionable” actionable?

There is of course, one last question about the axiom – is it practical? What would it take to actually design systems that complied with it? I think there is a prima face case for ‘way more than we have’.

But that is question I can only do justice to by taking a much more inclusive measure of the Laws as a whole. Which I will do, when and if, I finish my one-by-one considerations.


1: And that now includes more than simple providing a channel for communications. It includes acting as our proxies, and more and more, as delegates that can undertakes some actions on our behalf.

It also includes relationships between machines as well, and even the use of machines to mediate relationships between other machines. That is however a long and nuanced discussion for another post.

2: Yes, there are lots and lots of other ‘things’ but I would contend that they are all production factors, used to arrive at useable digital identities and operable access transactions.

3:  Blakley, B., The Emerging Architecture of Identity Management, The Burton Group, Utah, 2010

4: Thomas, Ivonne, and Christoph Meinel. “From Domain-Based Identity Management Systems to Open Identity Management Models.” Digital Identity and Access Management: Technologies and Frameworks (2012): 19.