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.
- Did Occam forget the bins? (Preamble to the series)
- To bind or not to bind? (The second axiom: Actionable)
- Oh what a tangled web. (The first axiom: Scalable)
- Unfinished business: Scaling relationships Part 2 (More on the first axiom)
- Square instances and round categories (The Types: Immutable, Contextual, Transferable)
According to Ian Glazer’s Laws of Relationships, relationships come in three types:
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…
“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.
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.
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 Mind, by 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.