The Laws of Relationships

Overview#

The Laws of Relationships is about Subject Relationships and specifically about Technology-Enabled Relationship Management

Ian Glazer[1]#

Taking a page from the work that Kim did with "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[2] 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[3]#

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:

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:

2.3. MUTABLE#

Relationships, like most things in the Digital Identity world, change over time. Different parties enter and exit a relationship. Attributes of those parties change over time. And at the same time the properties of the relationship itself can change as well. Thus designs for systems that handle relationships must account for mutability.

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:

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:

2.5. DELEGABLE#

Relationships change. Relationships end. The actors in relationships can be replaced as well, so in some cases there is an actual transfer of the relationship. In order to represent and handle situations in which the actors in a relationship change, either permanently or temporarily, relationship-based systems need to accommodate the design principle of delegation.

There are three areas of consideration for delegation and relationships:

Notice the use of MAY in above list. The IRM WG found it difficult to assert that actors in relationships would always have the ability to delegate their participation in a relationship. Furthermore, if a party can delegate their participation it is unclear that the party can always delegate the entire relationship for an indefinite amount of time without constraints. Depending on the context (including the legal context in which the relationship exists) actors can delegate differently. In some cases, the Reader can foresee that 289 the other parties in a relationship may have a say in whether an actor can delegate their participation. Sorting out who can delegate, how much, and for how long is likely the job of a context-aware relationship manager.

2.6. SCALABLE #

Scalability is a must for Identity Relationship Management. Originally, the IRM WG identified four axes of scalability: and these four variables of scalability still need to be solved for in order to have relationship management. But there is another crucial consideration for this design principle - every party in a relationship may be legion. IRM is not only meant for simply just single party to single party relationships, but also groups of actors in relationships with other groups of actors. As one member of the IRM WG stated, “this world is many to many on all sides of the equation.”!! More Information There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!