Archived Groups
Child pages
  • Drafts
Skip to end of metadata
Go to start of metadata

 

  File Modified
Microsoft Word Document Refining Design Principles v1.docx Sep 05, 2016 by Ian Glazer
Microsoft Word Document LoR-DRAFT-Report-v0.2.docx Oct 24, 2014 by Kantara Initiative Staff
Microsoft Word Document Refining Design Principles v1 after 10th Oct 16 call.docx Added to Acknowledgeable Oct 04, 2016 by Colin Wallis
Microsoft Word 97 Document LoR-DRAFT-Report-v0.1.doc Oct 02, 2014 by Kantara Initiative Staff
Microsoft Word Document LoR-DRAFT-Report-v0.3.doc.docx Dec 29, 2014 by Ian Glazer
Microsoft Word Document LoR v4.docx Jan 26, 2015 by Ian Glazer
Microsoft Word Document LoR v5.docx Jan 29, 2015 by Ian Glazer
PDF File Refining the Design Principles of Identity Relationship Management v2.0f.pdf May 31, 2017 by Megan Cannon
Microsoft Word 97 Document Kantara IRM Design Principles of Relationship Final Report v1.doc Jun 23, 2015 by Kantara Initiative Staff

TIP: Click the arrow next to each task to view and edit the task attributes.

100%

LoR Draft Tasks

  1. handler

    IRM WG to determine their desired editing process

    Priority HIGH
    iglazer
    Oct 03, 2014
  2. handler

    Assign access to core editors

    Priority MEDIUM
    iglazer
    Oct 07, 2014
  3. handler

    Notify WG of this task list

    Priority MEDIUM
    ricphillips
    Oct 07, 2014

4 Comments

  1. Ric Phillips

    I understand this will move to a Google Doc for collaborative editing and comment. Until I receive that, here are some comments and suggestions I would like to put in front of the working group.

    1. Let's aim to generalise the principles of IRM sufficient to all use cases.
      Specific use cases - eg managing relationships across federations - should be 
      1. used to prove (test) the principles as they are being developed
      2. be handled in more specific guidance documentation
      This will help up us not get lost in the details of every contemporary issues with IAM - and there are very many. It would also allow those with an interest in a particular area of application to break off and work on those applications more effectively.

    2. I would like to propose for discussion and inclusion (somewhere) the following;
      • Collective identities are not groups. (This implies they have agents - not members.)
      • A relationship is not an identity and cannot function in any way as an agent, including the function of having and participating in relationships.

    3. The document is over-structured. Use of axiom and type headings are not required. If the document is intended to be a design platform, everything can be stated as a series of 'relationships are / should / can / must'. What reason is there for the additional cognitive load of meta-categories.
       
    4. Transferability requires unpacking. I am assuming this was directed to the function of 'roles'. Which indicates the distinctions between identities and relationships may need to be made more explicitly. Do we want to admit relationships functioning as if they were identities? Personally I would vote no - and consider one might get to a better (more predictable) design by taking the opposite position that relationships, (and identities) are by definition non-transferable. This question is intimately bound up with the notion of agency. Agents may have proxies and delegates. But a) proxies and delegates are kinds of identity and b) the relationship A has to X as a proxy/delegate of B is not the relationship B has to X. Identities and relationships while generative are preserved, changed or destroyed. Which also leads to the question of binding.... whether and how well a personal, collective or machine identity is bound to some factor of assurance - civil jurisdiction in the case of a personal identity for example. And finally we need to be clear about the domain in which the act of transfer occurs. If Bob gives Tom his credentials has he transferred his identity or the relationships that pertain to it. However, from the perspective of any system that knows Bob's credentials nothing has been transferred. I suspect Ian's perspective was entirely 'in-system' and would welcome his comments.

      As I said it requires unpacking. 


     

     

     

     

  2. Wilmar Lay

    I work in the identity and access management for a bank in their wholesale banking division. One of the challenges that we face is the complexity between individual (who you are) and the organisation (which is our customer). We need this relationship defined to establish the individual entitlements. 

    An example of our use case is: An individual say 'Bob' may work for organisation A and has username called 'Bobuser'. Bob may also work for organisation B (which is a subsidiary of organisation A) and use the same username called 'Bobuser' to access Internet Banking portal. Internet Banking portal need to determine which screen that Bob entitles to see based on the his relationship. Both organisation A and B are XYZ Bank customers.

    I feel that the document is going straight to the 'relationship law' without having a proper scope / definition.

    Can I suggest to start with:

    What is Identity relationship management? How it is different to Customer Relationship Management? I often get confused when people say 'identity' what does it mean? Does it mean individual identity? organisation identity? or simple user credential i.e. username. Legal implication can also be very complex if one individual has 1 user credential to access data from multiple organisations. 

    I feel the above scenario is not covered in the identity and access management mainstream product because they focus heavily on internal users rather than external users. I often see the external users problem as CRM (customer relationship management) + IAM (identity and access management). 

    Perhaps IRM = CRM + IAM?

     

     

    1. Thorsten Niebuhr

      These 'problems' are one of the reasons I joined this WG. We have implemented systems coping with that on a relational manner starting 2008 and are calling this approach 'Entity Management', simply because we do not only manage 'identities' (read: entity.user), but also any other type of entity that has a relation to the 'identities'.

      For example, an entity of type 'user' has a relation to entity.department, that department has a relation to entity.organization and entity.location. The location has a relation to entity.country etc pp.

      The IDM System we have implemented (better: the E(entity)M(anagement)S(system) - EMS) is designed to activly manage these entities and also their relations. So we could call this Entity Relation Management System, ERM.

      Changes on one entity could led to changes on the related entities, which subsequently might change other entities as well (somewhat in a transitive manner), making the whole system highly dynamic. This allows us to assign entitlments to departments, organizations and locations (and many others more), effectivly enabling inheritance via defined relationships. Among the already mentioned entity types we also manage relations to devices and external organizations (partner, vendors and co).

      However, this is all 'inside enterprise', where all the entities and their relations are managed by the 'owner' of the ERM /or old style IDM. It is not build with the scaling and 'unreasonably large numbers of people and things' in mind. For that, we need more; and the idea to define this via Ian's approach of 'laws' is (in my opinion) a good idea to get the general idea and requirements.

      I am right now checking if and how the currently defined 'laws' fit to what we are doing for more than 6 years now, and what might be missing compared to our experience.

  3. Mark Lizar

    In Reference to both the comments above:

     

    From Ric: 

     

    "This question is intimately bound up with the notion of agency. Agents may have proxies and delegates. But a) proxies and delegates are kinds of identity and b) the relationship A has to X as a proxy/delegate of B is not the relationship B has to X. Identities and relationships while generative are preserved, changed or destroyed. Which also leads to the question of binding.... whether and how well a personal, collective or machine identity is bound to some factor of assurance - civil jurisdiction in the case of a personal identity for example." 


    And in terms of :

    "get(ting) confused when people say 'identity' what does it mean? Does it mean individual identity? organisation identity? or simple user credential i.e. username. Legal implication can also be very complex if one individual has 1 user credential to access data from multiple organisations." 

    I think there is an in elephant in the room

    When it comes to the owner/issuer of the identity and who controls/administrates the identity. The relationship between these are very prescriptive in law. This is what we have been working on in CIS-WG with the consent transaction record format with the intention of providing the transparency with the legal aspects of this relationship via legally prescribed requirements between the individual and  issuing entity (via the identity) that consents.  Our work has very much focused on the compliance spectrum of the relationship.     With the aim to make this common - minimum viable consent transaction record format - based on legal requirements across jurisdictions, extensible for different types of relationships.