Purpose

The purpose of this page is to gather general notes created on the principles discussed during the IRM Workgroup meetings and discussions.

Transferable

Submitted by Ian Glazer

Can we separate full from partial delegation?

Scope of delegation

* is scope something that really only applies to temporary transferance?

Does permanent transference creates a new relationship connection or replace an existing?

* some resonance with blockchain

Ken D's example of vehicle recall for notion of "prior"

Should we rename this to "delegation"?

System that respects the design prinicple of transferable:

* allows one party to hand its connection to a relationship to another party

* this hand off can be all or some of the original party's permissions

* this hand off can be for a period of time or permanent

Constrainable

Should there be "must" in the first sentence?

Applying a scope vs restrict a relationship going forward

persistence of constraints going forward

* may not always be possible

anti-pattern for "must"

* IoT - i might want to constrain what data it trasmits, but the device might no be able to not transmit a part of its data

* in this case device cannot respect constrainability

* is this the place for the "manager" to enforce constrainability

Constrainability may not have to be enforce by the actors but instead by the thing brokering the relationship

* in IoT the cloud backend constrains things for the actor

there is a strong implication that the thing involved can constrain itself.

"All behaviors and allowable actions associated with a relationship must be able to be constrained based on the desires, preferences, abilities, and even business models of the parties involved."

Revocable

Applies to the entire relationship.

Some questions include;

If there are 4 parties and one of them revokes the relationship what does that mean?

Leaving a relationship (group) i.e. no longer a member is different than dissolving the group.

Is there an investigation needed between resource owner and relationship owner. “Resourceness” of relationship.

Can we characterize things by relationship type? E.g. Mutual, Managed (loosely, tightly). Can you get out of it, is it voidable? Involvement, participation and other words may describe this.

Back to mutable in considering mutability of the member attribute perhaps.

Some of the principles may over lap under certain conditions. There is a subtlety that needs to be maintained or considered. Maybe a potential to reduce # of principles but need to be careful of losing nuance

Is this re-invention, or covered ground? Is this contractual?

Can be related to normalization in architecture work (simple makes it all a single shade of grey).

Mutability

System respecting mutability allows for ways to indicating attributes and actors are mutable (or immutable)

A relationship is the connection that is established between two actors. A Relationship has attributes including a list of actor identifiers. (To be clear, the list of actor identifiers is a list of pointers to complex things - collections of attributes - and not the attributes that comprise the complex thing themselves.) in essence, the end points of the relationship. These attributes can be mutable or immutable. The system needs a clear way of indicating which attributes are mutable and which immutable.

A system that respects mutability:

allows for the changing of relationship attributes
allows for attributes to be “marked” as immutable which prevents further changes
identifies which attributes are mutable and which are immutable

A system that respects mutability allows for the appropriate change to relationship attributes over time and thus prevents the inappropriate change to attributes as well. (What is appropriate and inappropriate changes are left to the system to decide.)

A system that doesn’t respect mutability:

allows for any attribute to be changed
allows for no attributes to changed
doesn’t indicate which attributes can be changed or not

A system that doesn’t respect mutability could lock the relationship amber and freezes the relationship in time. Or it could also make everything fluid which has potential legal, business, and audit ramifications. Depending on a fully-fluid thing makes things challenging.

There are expectations of mutability when a relationship is formed. That expectation must be maintained. How is this expectation presented and agreed upon? Is mutability applied en masse to all attributes of a relationship? This might be part of the relationship “contract” between the actors.

Feedback Thread on the Above Notes:

Hi again -

I may be warping the whole concept here, unintentionally, but think a lot of online relationships are directional, in the sense that they are asymmetric...

"Is a customer of", "Is an IDP for", "Is the manufacturer of", etc., all express relationships which are likely to be true in one direction but not the other. I.e. Alice is a customer of Bob, but not vice versa.

Then there's the question of whether a relationship has only two endpoints. I think we briefly raised this on the list months ago, but I'm not sure the discussion went any further. To my mind, we ought at least to consider a range of options:

- one-to-one (peer relationship)

- one-to-many (e.g. IDP to its customers)

- many-to-one (e.g. sensors to a domestic thermostat)

- many-to-many (e.g. mesh network?)

- transitive (e.g. delegated authority... Alice delegates Bob to collect her prescription from Charles)

Again, I may be trying to make the concept do things it wasn't meant to, but those all seem to me to be valid cases. That said, they *could* all be broken down into one-to-one templates, where (for instance) a one-to-many is simply a one-to-one with many instances, in which the first entity is always the same but the second differs... as I say, it may be that I'm stretching the concept.

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 3 Jun 2015, at 02:09, "Ken Dagg" <kendaggtbs@gmail.com> wrote:

Paul,

I agree that the direction is probably an attribute. That being said, in thinking more about it, I am not sure if there is a direction to a relationship - this probably needs some more thought. I tried to think of an omni-directional relationship and could not. It could be the case that the value of specific relationship attributes may differ based on the direction of the relationship.

This topic will most likely form part of the next call in two weeks. Thanks for engaging in the conversation.

Ken

On Tuesday, June 2, 2015, Paul Madsen <pmadsen@pingidentity.com> wrote:

Hi all, long time listener, first time caller ...

what does it mean for a relationship to be 'directional'?

does it denote which party established it? administers it? 'owns' it?

could not all those aspects be 'merely' attributes of the relationship?

paul

On 6/2/15 6:48 PM, Ken Dagg wrote:

Thanks for the picture Robin!

Robin: I agree with you that the relationship is directional (probably another attribute? - A2B, B2A, or bidirectional).

Ian: Am I incorrect in thinking that there are only 2 end points (actors)?

Ian: I also believe that there are other attributes besides the list of actors (e.g, type)

Robin: I am still not sure what the ComplexThings is trying to depict.

Ken

On Tuesday, June 2, 2015, Ian Glazer <iglazer@salesforce.com> wrote:

You got it. Alice and Bob are ComplexThings. The rel has attrs including listOfActorIdentifiers which point to Alice and Bob

On Tue, Jun 2, 2015 at 5:11 PM, Robin Wilton <wilton@isoc.org> wrote:

The arrowhead is there because I assume the relationship might be directional (in other words, the characteristics of A2B might differ from the characteristics of B2A..);

As far as ComplexThing#1 is concerned... I was just transcribing what's in the text; is ComplexThing#1 actually Alice or Bob's attribute list?

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 2 Jun 2015, at 20:06, "Ian Glazer" <iglazer@salesforce.com> wrote:

The pic looks correct other than I wouldn't put an arrowhead on the edge connecting Alice and Bob.

Not entirely sure what the ComplexThing1 is meant to do

On Tue, Jun 2, 2015 at 2:01 PM, Robin Wilton <wilton@isoc.org> wrote:

Hi all,

Apologies, first, for missing today’s call… sounds like I missed a good one.

That said, I am struggling a bit with jet-lag, so I probably would not have contributed anything sensible.

Along the same lines, I’ve read the paragraphs on mutability below, and in my brain-fuddled state I’m having trouble parsing them.

In particular, I have embiggened* a chunk of text below, which I need to understand more clearly.

I’ve drawn a picture of what I think that text says (attached, in OpenOffice and Msft proprietary formats)… and the picture suggests to me that there are implicit assumptions in the text that could usefully be made explicit. Can someone confirm/deny/help, please?

Thx.,

R

*A perfectly cromulent word, as far as I’m concerned.

On 2 Jun 2015, at 09:20, Ken Dagg <kendaggtbs@gmail.com> wrote:

Ian,

Thank you for facilitating an excellent discussion. See inline in italics for some suggestions that I think clarify the notes you made of the meeting.

Thanks again,

Ken

Hi all,

I totally agree to the second part regarding the system the 'doesnt respect

mutability'

For a system that respects mutabilty, the relationship 'weight' is

important. I cant simply ignore the fact that I got a immutable relationship

information. therefore

A system that respects mutability:

*allows for the changing of relationship attributes _/if it is not

marked as immutable/_

*allows for attributes to be "marked" as immutable which prevents

further changes

* identifies which attributes are mutable and which are immutable

The important point here is the relationship chain:

* Attribute A.1 forms a relationship to B.1 (no defined mutability)

* B.1 is declared by B as immutable

* Attribute B.1 forms a relationship to C.1

* C 'should/could/must' handle C1 (and any subsequent relation) as

immutable

In other words

A system that respects mutability:

* MUST respect the mutability information from the relation he is

'using' and MUST include that information on further relations

Back to Ian's Question: a mutability should only be applied on a 'per

(relationship) attribute), not on the whole relationship

just my 2 cents

<http://www.wedacon.net>

Thorsten H. Niebuhr

tniebuhr@wedacon.net / tniebuhr@wedacon.de <mailto:tniebuhr@wedacon.net>

WedaCon Informationstechnologien GmbH

On 03.06.2015 17:21, Ken Dagg wrote:

> Ian,

> Thanks for bringing the original question back to the foreground. I

> agree that the discussion around relationship is a separate, but still

> important, discussion.

> I like the mutable text. My only question / concern is around the word

> "appropriate". Given we are putting the discussion in the context of a

> system would the word "controlled" be more appropriate? I believe that

> Mutability controls the conditions under which a relationship

> attribute can be changed.

> Additionally, should every use of "attribute" be "relationship

> attribute"? Given my confusion on yesterday's call I think it would

> contribute to clarity.

> Ken

Browser not supported