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.
- 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)
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)
In 2012 Thomas, Ivonne, and Christoph Meinel published a paper, on domain-dependent Identity:(4)
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.