BYOI (Bring Your Own Identity) : Actionable Relationships – an approach

2 Flares Twitter 0 Facebook 0 LinkedIn 0 Buffer 2 Email -- Filament.io 2 Flares ×

 

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

Ian Glazer “The Laws of Relationships (A Work In Progress)” – https://www.tuesdaynight.org/2014/05/28/the-laws-of-relationships-a-work-in-progress.html

This post has been written with solely purpose of catch my always disconnected thoughts over the things I read and, in this case, related to IRM and Ian’s “Law’s”

ac·tion·a·ble (ˈakSHənəbəl/)

1. giving sufficient reason to take legal action.

2.able to be done or acted on; having practical value.

re·la·tion·ship(riˈlāSHənˌSHip/)

  1. the way in which two or more concepts, objects, or people are connected, or the state of being connected.

A relation is quite an interesting concept.

A relation between two sets is a collection of ordered pairs containing one object from each set. If the object x is from the first set and the object y is from the second set, then the objects are said to be related if the ordered pair (x,y) is in the relation.

A function is a type of relation. But, a relation is allowed to have the object x in the first set to be related to more than one object in the second set. So a relation may not be represented by a function machine, because, given the object x to the input of the machine, the machine couldn’t spit out a unique output object that is paired to x

From: http://mathinsight.org/relation_definition

So a relationship to exist need at least two parties or at least this is what I was thinking reading  the blog of @ricphillips ( http://haecceitydotorg.wordpress.com/) and more specifically: “To Bind or Not to Bind” and “Oh What a Tangled Web…”.

But then I start to thinking back at the mathematical concept of a relation and start to wonder if the “initial” assumption (of mine) that two parties are necessarily part of two different identities was correct.

Let’s define an identity as a  certain number of objects (attributes). Those objects could be aggregated into sets . A set  may contain objects  who are part of another set creating a collection of sets if an only if  (as per mathematical definition):

If the object x is from the first set and the object y is from the second set, then the objects are said to be related if the ordered pair (x,y) is in the relation.

This also means (to me) that a relationship may (also) exist within the same identity . I’ll call this inner relationship

At the same time the same object,set, collection or identity may be related to an external equivalent creating an outer relationship.

If I assume that an  inner  and an  outer  relationship exist than I may assume that could also  exist a middle layer  who has knowledge of one and access to the other in order to pull/push the authorization actions related to one or the other.

1

Fig.1 Model of layer of relationships

Outer Identity: All the attributes related to the identity who are defined by the provider of the identity itself. Those attributes are not actionable since they do not carry any information that may directly trigger action to the identity but may be pushed in order to contextualize the identity into the ecosystem where it will “live”.

Middle Identity: All the attributes related to the identity who may create a relationship between the identity and it’s two sets (inner and outer) of attributes. Those attributes pull information from the outer and from the inner. The attributes are actionable only if the action has been instantiated by the inner set of attributes.

Inner Identity: All the attributes related to the identity who may create an exclusive relationship with another inner attribute. These attributes are actionable by nature and could not have any relation with an outer attribute. The attribute itself is pulled from a  Middle attribute who is “self defined” at the moment of provisioning.

The model should than follow a schema similar to this:

At the moment of the creation of the first identity the provider is responsible to inject a unique set of attributes (outer) who represent the identity toward all the other identities in terms of public uniqueness and identification (authorization and authentication attributes).

While the outer  attributes are created an action need to be instantiated in order to generate a unique set of attribute called inner attributes. Those attributes are uniquely defined within the identity itself.

When a second identity is provisioned we will follow the same procedure. The  inner  attributes anyway will be produced using a collection of sets exposed by the initial identity (middle attributes) who link permanently the second identity  inner attributes to the first identity.

An  inner relationship will be consequently created between the two identities. Any other identity that has not a relationship within this inner circle will not be in a position to join directly since its  inner attributes  were not generated by the original parent.

An  outer relationship may anyway be stipulated (i.e.: IDP authentication transaction) in order to push further attributes to the identities.

These further attributes represent a new provisioning process who may fall in a new process of relationship generation who conclude itself generating a new inner relationship who may permit now the two identities to interact ( middle relationship).

Since the  inner relationships carry a common factor of identification do not need to call back the IDP to obtain access and authorization within their “network” still at the same time the single identity to join/un-join the various relationship need at least to pull/push attributes from the “outer”  (IDP) actors.

A model that represent this is the concept of “my Identity” as personal domain for the identity of things . Let’s assume that a user (parent identity) is filling his/her home of devices. All these devices are part of the “my Identity Domain (mID)” of this user. The user has a “main identity” that is based on the first service/product/thing will add to mID.

mID is composed by the vendor attribute (outer identity): oID, by the user identity (middle identity):ID and by the unique set of attributes generated by the addition of the very first other “thing” (inner identity atrributes):iID.

Based on this for every new “thing” added to mID we will have at least:

oID: public attribute known by every other object at IDP level (vendor/producer), reachable from public network

ID:  is “uniquely” generated by mID  but is still public reachable and pull authorization information’s from IDP and from iID

iID: is uniquely generate from the sum of attributes who compose the  inner relationship circle. The attribute is actionable from any identity inside the relationship and do not accept any interference from outside identities if not only through the communication with an ID (i.e.: I cannot manipulate the access since the attributes related to the authorization process are not known in the outside world). This attributes are not public but stay private within the identities joined to that specific  inner relationship.

…continue

Topics

Archives