Date

March 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	Kantara IPR http://kantarainitiative.org/confluence/download/attachments/2293776/Kantara+Initiative+IPR+Policies+_V1.1_.pdf?version=1
2 mins	Roll Call	Sal	Roll, new intros, announcements
4 mins	Minutes/Notes Update	Sal	Minutes, Notes, 2016-01-05 Meeting Notes
45 mins	IRM in the Wild	All	Discussion of IRM in the wild - Consolidating the Use Cases
1 min	Other Admin	All	Other Administrative, Action Item Review (not covered above)
1 min	AoB	All	AoB TBD...

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?