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:
  • 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

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:

  • 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.

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:

  • 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.
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:
  • actors
  • attributes/properties
  • relationships
  • administration
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:
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop