Overview#The Laws of Relationships is about Subject Relationships and specifically about Technology-Enabled Relationship Management The Seven 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.
Ian Glazer's point is that we are approaching a point where we can no longer manage individual digital Identity's as with the Internet Of Things we will need "to know how to deal with an unreasonable large number of things." and the relationships between those things is going to get "really messy". Ian goes on saying that "laws" are really design constraints they can help us inform our designs that we are on the right path.
Kantara Initiative's Design Principles IRM Report#Released in June 2017 (We only provide a summary)
Relationships are not new but their representation has rarely been first class citizen in the realm of Digital Identity. In the past, relationships have been represented as attributes such as memberOf or implied in identifiers such as distinguished Name. IRM addresses the current state of Identity Management and the need to promote relationships, in both representations and awareness, in order to provide identity management practitioners with more accurate, more manageable, and more deployable means of managing digital identities in our hyper-connected world. To that end, the IRM WG offers the following design principles of relationships.
It is important to note that in application these principles are not discrete. One cannot design a system that provides one principle without at least considering the other principles as well. That is not to say that each principle will be of equal important to a system that you design to meet your specific use case, but that as a designer you will at a minimum have to examine 116 each principle in order to deliver a system that handles relationships well.
Furthermore, the systems you design, the principle you consider do not act in a vacuum. The context in which principles are applied has great sway over their practical application. In the previous version of the Design Principles of Relationships, Context was a 1st order Principle. However, upon further consideration, the IRM WG recognized the pervasive nature of context and attempted to reflect it in all of the following principles.
2.1. PROVABLE#The existence of a relationship between entities (be those individuals, groups, organizations, non-human entities, or any combination of these) carries meaning and provides large context. As such, systems handling relationships need a way to state authoritatively that a given relationship exists. There are several implications of the Provable design principle:
- Proof of Relationship information can be sensitive (e.g. the very fact a relationship exists between parties carries meaning) and thus care must be taken to not inadvertently distribute this information to the wrong or inappropriate parties.
- In the digital realm, a Proof of Relationship token may be needed. Consumers of such a token would require standard ways to validate that the relationship was still valid
- Generating Proof of Relationship information might require all parties in the relationship to interact in concert. For example, each member of the relationship has taken an action in order to allow the release of Proof of Relationship information.
- Concepts such as User-Managed Access Control and Consent Receipt may be a portion of what is needed to implement a Proof of Relationship service
2.2. CONSTRAINABLE#Although a relationship exists, parties involved may 157 want to impose constraints on the relationship. These constraints may describe acceptable behaviors of the actors in the relationship, approved use of data by the parties, and the terms under which the relationship is terminated. And in this way, the “Constrainable” design principle feels familiar to our everyday lives in the analogue world. But in that familiar is a bit of a trap. One cannot assume that all of the actors in a relationship are capable of:
- Asserting their desired constraints
- Acknowledging constraints
- Enforcing constraints
- Being held accountable for failure to uphold a constraint
Mutability introduces change and dynamic considerations for actors and attributes. Although not every relationship will change in the same way and although not every attribute for every actor will change, designers must at least explore what things can change, how often they will change, and what would be the impact if they did change. Furthermore, designers should consider mutability at three levels:
- The relationship as a whole including all of the actors, constraints, attributes and properties.
- The connections between parties and the associated attributes and properties of those connections
- The actors and their associated attributes
2.4. REVOCABLE#Relationships end. This is true in the digital world as it is in the analog one. To "I am no longer in this relationship" may have a clear and distinct meaning to one party but not the other parties in the relationship.
When discussing this design principle, the IRM Working Group thought of it as equivalent to terminating a relationship and it quickly realized implementing relationship revocation was not as simple as just disconnecting the parties in the relationship. Questions arose about who can revoke a relationship, how is that revocation enforced, how is the historical information about the relationship preserved, and what is the interplay of mutability and revocability.
Revocation of relationships includes:
- Consider legal and business requirements on the termination and revocation of a relationship.
- Coordinate data retention requirements with relationship revocation. For legal reasons, an organization may need to retain, long after the relationship end, proof of relationship as well as materials used to form the relationship and data produced from the relationship.
- Design a process for a party to request to revoke a relationship. (Design a process for reinstating the relationship too.)
- Clarify how revoking a relationship is different from changing attributes or properties of the relationship or the parties in the relationship.
- Consider whether in the reader’s use case revocation is actually adding a broad constraint to the relationship.
- Given jurisdictional or business requirements, design the system such that revoking a relationship does not impede providing proof a revoked relationship existed in the past and to allow third parties to validate that a revocation happened.
There are three areas of consideration for delegation and relationships:
- Scope: A party MAY choose to give another party all of its original capabilities and rights with regards to a relationship; in this case the scope of delegation is “full.”
- Permanence: The original party MAY be able to put a time limit on the delegation, stating that the new party has delegated participation in the relationship for 60 days, 100 hundred years, or it may be a permanent delegation.
- Constraint: The original party MAY choose to impose no new constraints on the relationship meaning that the new party can do as they please in the relationship.
2.6. SCALABLE #Scalability is a must for Identity Relationship Management. Originally, the IRM WG identified four axes of scalability:
More Information#There might be more information for this subject on one of the following:
- Digital Subject
- Internet of Things
- Technology-Enabled Relationship Management
- Web Blog_blogentry_071115_1
- [#1] - The Laws of Relationships (A Work In Progress) - based on information obtained 2014-05-29
- [#2] - The Law of Relationship: A Work in Progress, Ian Glazer, salesforce.com - based on information obtained 2014-06-19
- [#2] - Kantara Initiative Unveils Design Principles IRM Report - based on information obtained 2017-06-20