The Laws of Relationships (A Work In Progress)

Here it is… week 10 of my new job at salesforce.com. Needless to say it has been a bit of a blur. Part of my gig here is to hit the speaking circuit. I was at the European Identity Conference a few weeks ago talking about killing off IAM and how it should be reborn, and next week I am off to the Identity Relationship Management Summit. I have to say, I am little nervous about speaking at IRM this year… not one, but two of my ex-bosses will be speaking there, not to mention my current one.

I have to admit when I first heard the noise surrounding Identity Relationship Management, I cringed, especially when people started referring to it as IRM. IRM sounds way too much like DRM to me and that just leads to bad things. Furthermore, my concerns with what Kantara and ForgeRock laid out was that it didn’t necessarily address relationship management; they presented the needs of modern IAM well but didn’t present the needs of relationship well. However, after many conversations and email threads, I still loathe the IRM name but have come around to the larger mission that Kantara has in mind. Simply put, relationship management is the future of identity and access management.

The Laws of Relationships (A Work In Progress)

Taking a page from the work that Kim did with “The Laws of Identity,” I wanted to provide the starting point for the community to build a similar set of design constraints and considerations for relationships and relationship management technologies. Our current IAM methods will be insufficient in a near future in which we are dealing with an unreasonable number of people and things and the relationships between them. At the IRM Summit, I’ll be presenting a strawman set of laws for relationships to help us think about this coming future. To that end, here is a preview of the laws (and axioms and attributes) of relationships.

 

Axioms of Relationships

Scalable

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.

Actionable

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.

Types of Relationships

Immutable

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.

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.

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.

Laws of Relationships

Provable

There must a way for different combinations of parties to prove that a relationship exists. In some cases, a single party is all that is required. In other cases, a 3rd party separate from the relationship will be needed to prove a relationship exists.

Acknowledgable

I believe that all parties must be able to acknowledge they are in a relationship. This is a form of consent management. I’m guessing this will be one of the more contentious parts of my presentation.

Revocable

There needs to be a way for a relationship to be revoked. This naturally raises the question of what happens to data that was shared within the context of the relationship. We, as identity professionals, need to get ahead of this narrative before Right to be Forgotten/Deleted becomes solely the domain of lawyers.

Constrainable

Participants in a relationship need a way to constrain the relationships and connected parties. This is needed so that parties can describe what is acceptable behavior within the relationship.

So now what?

I want all of you to test these laws. Take your use case and do a gap analysis on these. Hopefully, you’ll come to Phoenix and the IRM Summit next week and help all of us strengthen these laws. Bring your critique. Bring your uses cases. Bring your angst. We (the IAM industry) needs you.

Finally, I will write up a longer form of my presentation and get it up here after next week as a way of kicking off a longer-form dialogue.

See you it the IRM Summit!