Date
February 23rdMarch 8, 2016
Attendees
Goals
- IRM in the Wild Discussion & Examples - Working Through the Principles
Discussion Items
| Time | Item | Who | Notes |
|---|---|---|---|
| 2 mins | Kantara IPR | Sal | |
| 2 mins | Roll Call | Sal |
|
| 4 mins | Minutes/Notes Update | Sal |
|
45 mins | IRM in the Wild | All |
|
| 1 min | Other Admin | All |
|
| 1 min | AoB | All |
|
Action Items
-
Former user (Deleted) to provide IoT ecosystem diagram/information to the group to support SDID example
| Anchor | ||||
|---|---|---|---|---|
|
- 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?