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!
@iglazer Relationships and Laws? Can’t we just talk about things first? #WhySoSerious
RT @iglazer: Blog Post: The Laws of Relationships (A Work In Progress) http://t.co/rgZpeBOZzi #iam #irm
We must avoid one pattern that works for people and a different one that works for things. We need a single model going forward.
Looking forward to the #IRM Summit next week! // The Laws of Relationships (A Work In Progress) via @iglazer http://t.co/7xVWoPntvY
Check out “The Laws of Relationships (A Work in Progress)” blog post from @iglazer of @Salesforce: http://t.co/C0FRAV9lIn #IRM
“The Laws of Relationships (A Work in Progress)” blog post from @iglazer of @Salesforce: is out…check it out: http://t.co/rpRwoewi0x #IRM
I also saw the use of IRM and thought we were back to the days of DRM where IRM meant information rights management. Anyway on the subject of relationships, it’s good that you’ve brought this up, it’s about time we had some coherent discourse on what this whole IDM/IAM/IDaaS/IRM (whatever the next abbreviation is) is actually about and not just talk about the plumbing. I’ve always been an advocate of using reductionism sparingly and to try and capture the whole of a subject – I believe this view allows you to design better systems. Adding this new layer into identity allows you to bring together the plumbing, aka the things that the pillars of IRM address, with the context and meaning of identity and what we do with it, aka build and manage and evolve relationships. In fact evolution of relationships is perhaps another area that could be added to your list. Relationships can be made stronger and weaker depending on the behaviour of the involved parties. An intelligent system can recognise both good and bad behaviour and have models to handle this – the capture and use of reputation systems spring to mind as well as behavioural analytics being used within an identity platform to adjust authentication requirements, for example.
On a slight aside: Do you remember ‘relationship cards’ within the information card system? We could perhaps look back at those and see if there is any relevance and use within our current ID systems…
The Laws of Relationships (A Work In Progress): https://t.co/qUs7QisYxN via @@iglazer #identity #IDM
IRM pillars are a good start. But Relationships and Consent are a key pillar that is missing from IRM. I think you have come up with a better way of dealing with this under laws of relationships. As we need to define these in more depth. Uni and Bidirectional trust is not enough. We need to move to a model of multi directional trust. This when combined with consent reflects my real world relationships. They are also dynamic and change with context and time. My digital relationships need to do the same. Perhaps a new IRM pillar should be dynamic laws of relationships incorporating user consent vs statically implement relationships.
Roles, Attributes, Rules, relationships… Do you want to talk about the moon or about the finger that shows the moon ?
As you know Ian, I`m working on conceptual patterns rather than formal rules to avoid what I discovered in an hospital among 8: 1200 relationships/rule sets to manage !
With roles, we talk about basic relationships.
With sets of attributes we talk about average complexity of relationships between individuals.
With rules we go to a higher level of complexity because we formalize relationships and rule sets.
I consider that there is a risk of explosion of roles, sets of attributes and rules/laws when one wants to apply the obvious approach.
There is something that relies the dots of relationships between data and that is pure logic. This something is ”patterns”.
There are changing contexts in which patterns can apply or no longer.
In contexts in which something can be applied, there are some that are aligned with enterprise policies, some that correspond to epiphenomenons and some that correspond to trends.
Few patterns describing the relationships rather than exposing relationships and data can be used, once combined with Advanced analytics.