2016-03-08 Meeting Notes

Date

March 8, 2016

Attendees

• Salvatore D'Agostino

• Former user (Deleted)

• Former user (Deleted)
• Thorsten Niebuhr (Unlicensed)
• Former user (Deleted)
• Ken Dagg (Unlicensed)

Goals

• IRM in the Wild Discussion & Examples - Working Through the Principles

Discussion Items

Action Items

• Former user (Deleted) to provide IoT ecosystem diagram/information to the group to support SDID example

Submitted Links

• https://www.globalsign.com/en/internet-of-things/ - As mentioned here is our current simple diagram of the IoT Ecosystem and the related areas where trust will be required. It may be a possibility to discuss each area of trust or areas where a relationship exists and how it applies to the principles. Just a thought for the next meeting. Here is the image: 
  

High-level Topics Covered

• IRM in the Wild
  
  • Discussed Thorsten's Ontology example
  • Discussed Kim's SDID example

Detailed Meeting Notes

• Roll call
• Meeting minutes - Ian added IoT links to Submitted Links section
• Discussion - topic?
• Use Case of IRM in the Wild:
• Don? - gone from meetings for a while
• Sal - brief description of what we have been covering - Thorsten use case - let's discuss?
• Kim - also happy to discuss SDID
• Sal - let's go through Thorsten's use case - then if time go through SDID
• Thorsten - basic idea - all rules and definitions inside IDM system, or even more systems, into Ontology, semantically describe what is going on with the system - entities in graph databases - what they started with - going through the principles - it is all in there:
• Scalable - simplified the A box and T box areas here - where they have the instances in ontology - provide the rules and linkages between those events - don't need the scalability on the rule set - won't grow into billions
• Not doing Identity Relationship Management but more Entity Relationship Management
• Anybody else in this space?
• Ian - has played with it at some time - useful to have out there
• Sal - a little more about ABOX and TBOX then? Help follow along
• Thorsten - ontology - W3 C-course on ontology handling - family structure (e.g., father, child, mother, etc.) - semantical approach to describing relationships - it's a "thing" not a "string" - if you are able to describe the string thing then it is something you can do in ontology and referred to as TBOX (rules for that) - e.g., Spain is "ABOX", description around Spain that it is a country, etc. is then TBOX

• Reference: https://en.wikipedia.org/wiki/Ontology_(information_science)

• Sal - could we map this to the table and is it consistent with this? - potential is this becomes a tool to look at IRM - good framework - symantecs may be different than the Identity Relationship Manager might apply - tool which is very interesting
• Ian - describes a different model for IRM - get to Thorsten - how are you applying this? Application or example of application which you are applying it to
• Thorsten - fact that you can write rules that are machine readable and human interpretable or vice versa - it can become a language which can be applied throughout - not technical anymore - if user walks in and has role and group, etc. then you can fire an action/allow it/deny it - with ontology you can describe that in a semantical way - working with the institute which has system built few years ago
• Sal - Is there a targeted use case you are looking to target?
• Thorsten - control a set of micro services - push policies and rules - near the connector - to one set of rules in one place to describe what should be done - not in different rules
• Ian - incredibly helpful - something we should keep coming back to - anything else to add?
• Thorsten - covered it.
• Ian - try to go through SDID examples and see how it maps out
• Kim - explained the project which GlobalSign is working on - SDID on Raspberry PI vs. dummy devices - happy to work through it
• Ian - scalable? Has to be - certificates targeted at that - potential is unknown
• Kim - scalability is what we are targeting
• Sal - can't be highly scalable then it fails
• Kim - has to be scalable to be realized
• Ian - will get into the difference between use case (billions of certificates) vs. tens or hundreds of certificates - interesting to look at use case and technology
• Ian - actionable
• Kim - struggle with part of the relationship being defined - lightbulb to hub or hub to cloud?
• Sal - look at Thorsten's example - thing to its controller - depend on connectivity - how extensible is the rule set - on/off or bright/dark, etc. - sophistication of the rules expands with the sophistication of the thing - if fully digital then can do with bits/bytes - analog settings - then there is electronics in the loop as well
• Ken - relationships which exist - lightbulb to Philips - lightbulb to control which is proxy to user - explored through principle - go beyond - what relationships are and explore the relationships - stay out of the tech
• Ian - approach how they took the IoT pattern - pattern of how things interact - apply at the framework - specific implementation - natural constraints of the devices - framework does - overall structure
• Kim - apply as a framework - IoT framework instead of looking at SF and SDID as use cases?
• Ian - too high-level - e.g., certificates aren't a gateway - neither solution are talking about messaging and backend processing - IoT - similar patterns - goal of providing some key material and key patterns - too high - loosing nuances and detail - looking at things in the wild - very similar - good to see the differences - if nothing else go back to engineers and say in comparison - this is what they're doing - partnership/principle approach/etc.
• Sal - do lightbulb - locomotive
• Kim - we have IoT ecosystem diagram - need grouping - like SDID is a grouping and devices, such as lightbulb and locomotives are under it
• Sal - some are groupings - things that we can look at - strongly identified lightbulb - good to have these conversations
• Kim - different areas of the ecosystem - e.g., we aren't going to work on Big Data - just focused on devices
• Ian - only do so much - people who are building access control engines - not in authN business, etc. - strong personal identity - as we get into different levels things identify themselves - keep playing with this
• Kim - look at it as just a SDID for device - Scalable has to be - Actionable - proving devices is who it says it is
• Ian - what you are producing and deploying - device has key material - what you're providing doesn't make the system actionable itself - what your system is actually processing it - some cases not applicable
• Kim - stagnant or not
• Ian - action can be explained through your framework - have to do so in a different context - not actionable
• Kim - actionable - partial is okay
• Kim - immutable - often times the use case is that the device identity is embedded at time of manufacturing and shouldn't change
• Ian - if service finds vulnerabilities - need to update firmware - moves along with some sort of identity with the device - when you find a bug in the thing - new identity? - strong identity use case - does need to be revoked and issued again - mutability and revocation
• Kim - sometimes there is a vulnerability and they just revoke and sometimes they just reissue
• Sal - is that enough identity - or is it the user of the device - multiple areas - rears its head - can turn them on or off
• Kim - other areas of the ecosystem definitely come into play - other identities come into play
• Ian - definitely where other principles fill in the gaps - interesting how - class of device - code that runs on it then it is more mutable - if it doesn't then immutable - class of things
• Kim - Partial with caveat of "dependent upon computing power of device"
• Ian - more an actor has capacity to do something - how does that change the relationship? - something with low computing capacity - no ability to act - how does that impact relationship model? - do we need to pursue that? - impact notion of relationship manager? - not answerable - bunch of actors in relationship model - large capacity to act - will that change the responsibility of relationship manager - or things which are dumb - relationship manager is much more needy - implications for relationship manager
• Sal - thoughts around that - master vs. slave - flow of control - degree of autonomy - Thorsten's points - are there bi-directional rules - thing tell you something that's going on - okay it's a robot vs. a lightbulb
• Ian - ask Thorsten - relationship model and system you've been working with - system has enforcement engine? How are rules enforced?
• Thorsten - they have the enforcement tool in place - shown or proved way they think it should work does (POC) - able to provide rules to offline - gives rules to MS then disconnects and knows what to do
• Ian - micro service has capacity to do that - interesting rat hole - extent of how distributed authorization really is - how many PXPs exist at the note - see certain scenarios where it can all be out there - some cases they are as dumb as a brick - only information flowing upstream
• Sal - send some spreadsheet notes to Kim - bring something back or pick up again
• Kim - happy to bring in IoT ecosystem diagram
• Sal - add link to the minutes
• Thorsten - anyone in Amsterdam in two weeks?