2015-11-30 Meeting Notes

Date

November 17th, 2015

Attendees

• Former user (Deleted)

• Salvatore D'Agostino

• Ken Dagg (Unlicensed)
• Adrian

Goals

• Kantara IPR Feedback, Review and Agreement
• IRM in the Wild Discussion

Discussion Items

Action Items

• Members should review the IRP from other workgroups including UMA, IoT & Consent and Information Sharing to determine if this is acceptable wording to which the IRM workgroup IRP should change to

• All members look for examples of “IRM in the Wild” 

Privacy Links Provided

From Ken Dagg (Unlicensed): As requested during today's meeting, here is a link that provides general information about privacy legislation in Canada https://www.priv.gc.ca/resource/fs-fi/02_05_d_15_e.asp. It includes links to specific privacy legislation.

From Salvatore D'Agostino: 

• http://www.un.org/ga/search/view_doc.asp?symbol=A/HRC/28/L.27  something from the UN on the topic,

• http://csrc.nist.gov/projects/privacy_engineering/  the link to privacy engineering at NIST

• https://iapp.org/resources IAPP resources

• http://oecdprivacy.org/ OECD privacy principles

• https://www.idesg.org/The-ID-Ecosystem/Identity-Ecosystem-Framework/IDEF-Core-Documents IDESG baseline requirements which contains privacy requirements

• https://www.oaic.gov.au/privacy-law/privacy-act/australian-privacy-principles Australia has a pretty good set

• http://www.autoalliance.org/?objectid=865F3AC0-68FD-11E4-866D000C296BA163 A set from the automotive industry

• probably many others…

High-level Topics Covered

• Role call
• IRP Update
• Principles Update on Hold
• IRM in the Wild – matrix? Examples?
• Privacy as a Key Point – Privacy Engineering (Click to See Relevant Links)
• Reference Architecture Development
• IoT Use Case – Scalability

Detailed Meeting Notes

IPR:  Sal - discuss IRM WG  IPR - current IPR policy does not align with other groups with which we would likely collaborate e.g.  UMA, Consent & Info Sharing, Identities of Things DG – which is a likely outcome after our effort at looking at IRM in the wild.– The other WG  IPR is  slightly more commercial/patent friendly - https://kantarainitiative.org/confluence/download/attachments/2293776/Kantara%20Initiative%20IPR%20Policies%20_V1.1_.pdf?version=1&modificationDate=1244488630000&api=v2  - Put forward the idea would be to align with UMA and CIS IRP.

 Comments:

• Any  worries one way or the other
• Key ask - everyone take a look at the other policies - first thing on other Wiki pages - any objections let Sal know - others to take a look - require some resigning of a membership agreement (potentially for each group)
• IPR issue is being taken up at the board level
• Easy fix - most likely to operate under same IPR - IoT, Consent & Infor Sharing, UMA workgroups & IRM

No new intros or other announcements

Ian Glazer is out for the next 30 days – full update to the principles will have to wait until his return

Next steps - update principles - look to see where IRM exists out in the wild.  Since most of us involved in the process of updating principles then it is still ok that without actual written document we have reasonable understanding of IRM and the input to principles from the recent effort.

So- today begin to talk about where IRM exists in the wild – so let’s try to identify things - take what currently exists - come up with some examples and try to get to a reasonable template to start mapping the characteristics of IRM

Talked about idea of putting together matrix with principles and "tick off" whether use case meets them

Kim - question about needing to meet all principles in matrix? Can some not be met if other conditions exist?

Sal - didn't come to a conclusion that all IRM principles need to be met - this exercise is to determine that - find things that exhibit the principles - the "push & pull" - discussion points about whether it is IRM or not

Kim - could be interesting if find a use case that is all principles but isn't IRM

Sal – yes, but guess that the example would fall somewhere under the IRM bell curve

Sal - given what's gone on in the news - idea of finding terrorists and being proactive - screening migrants - somehow IRM is in the middle of all of that – so this is an attempt to begin putting things on the wall - something is definitely a relationship management problem & identity related - other thoughts?

• Comments on that -
• Ken - appropriate - agree that it is IRM scenario - hole group of them - throw out any IAM scenario could be looked at in an IRM lens - might work well using  that kind (IRM) of glasses - could improve those situations immensely - likes it because it is timely - also thinking about online payment world
• Sal - IAM today is more often than not IRM - has to evolve in order to handle the challenges of today
• Adrian - understand UMA and politics around it as relationship management perspective - understands attribute release around identity from relationship perspective - doesn't understand IRM, or what gap in industry makes IRM different than the other two - not saying that we are not a valuable thing - issues with attribute management - certain problems with UMA as it stands - may well be that IRM is the thing that organizes the other two things - also relates to relationships - principles don't do it for him - seems to be another framework (IDESG, Patient Privacy Rights, etc.) - frameworks galore
• Ken - question back - what's missing from them? Frameworks in general - what's missing from them to solve which problem?
• Adrian - problem is easy - align with NIST - problem is that we don't have tools for privacy engineering - NIST trying to do this - EU trying to do this from slightly different perspective - difference in approach - zero actual industry involvement to do Privacy Engineering - as part of our charter
• Ken - Look at IRM - respecting privacy is one aspect - but it is not the only one is it?
• Adrian - gap in the marketplace, in the world, is that we don't have things we can point to that we can say here's something that helps scale connectivity and relationships because it gives people the tools for privacy
• Ken - privacy engineering - principles around for 40 years - privacy legislation in Canada - are you saying one of the use cases we should be examining privacy and how it can help respect individuals privacy?
• Adrian - privacy engineering in the NIST sense of the word - basically says set business goals - engineer systems to meet business goals with as little privacy leakage or privacy damage as possible - privacy engineering part is new - NIST trying to literally put process into privacy - as opposed to principles
• Kim - needs the technology and reference architecture - make it a tangible solution for the industry - gave example of NCCOE
• Adrian - agrees but why hasn't UMA developed one?
• Kim - they need to - all workgroups have needed them
• Sal - reference architecture is the third step in the process - after we develop scenarios - UMA for example is an authorization tool - any access control system really depends on how good the designer is - could go old school by managing the access to a folder – but even this done badly could also be turned into a complete mess – consider the maturity cycle and that UMA hasn't fully worked through it - sense that different authorization paradigm hasn't been exercised sufficiently to say it solves "these problems"
• Adrian - what he wants to talk to Sal about this - point is that UMA is at a crossroads - agree with Kim & Sal - ready to work on a reference implementation - UMA as it can be worked on in IRM role - work on reference architecture - UMA is out there now (101) - that doesn't mean we have to take our "marbles" elsewhere to do this work - UMA can be the embodiment of the principles
• Sal - agrees - old paradigm - IAM - access was traditional access control way of doing things - Identity was flat directory with roles to resources - reason we are all here is that has a lot of challenges in the connected world today - Identity piece has changed - Access management piece has changed – relationship management will and will most likely become the "tool" - scalability is key  - scalable requires distributed architecture - look at the world of what tools are  available then view UMA is one of them - all this is fresh in the market – from experience Sal had homegrown solutions - saw UMA as the standard that matched to need of distributed authorization - instead of coming up with distributed access control token - wants one based on standards
• Kim - thinks this is very needed - however need "scenarios" and this is the step we are working on now - start there then map an architecture to it
• Sal - the principles are characteristics of privacy engineering - privacy by design would be interesting to see what that framework would be - not sure how well defined the ones out there already are - but use as prototypes
• Adrian - privacy by design is opposite of privacy engineering - first is principles - engineering is specific methods which result in a particular outcome
• Ken - fully agrees that privacy engineering is an example of IRM in the wild and should be explored - also agrees that all the principles are characteristic of privacy - hypothesize that definitions of privacy don't apply to respecting it - principles need to add several words around respecting privacy (in intro or some point) - respecting privacy is important to respecting IRM
• Sal - everybody accepts that you need some notion of security and be respective of it - raising awareness for privacy as well would be great for the group
• Ken - privacy and security - two different ways to look at IRM would be valuable to the industry - previous experience submit development to privacy commissioner - need to respect privacy - related Canadian privacy links:

"As requested during today's meeting, here is a link that provides general information about privacy legislation in Canada https://www.priv.gc.ca/resource/fs-fi/02_05_d_15_e.asp . It includes links to specific privacy legislation."

• Sal - how do we get to an architecture Kim?
• Kim - brought up NCCoE and guidelines - familiar? Sal - wonder if NCCoE truly took a survey of participants, created a workflow and given persona, and then mapped it to the needed vendor solutions; - Syrian refugee example - how would you identify an ISIS member against any other refugee?
• Sal - maybe even the premise may be wrong - in investigative phase asking questions about what we are trying to accomplish is a good one; - likely could get 10 personas that show up when you go through the workflow;
• Kim - IoT architecture is also a focus and good example - we should also be focused on this - not just people but also devices;
• Sal – for what it is worth the IRM WG was  mentioned directly in Cloud Security Alliance IoT and Identity Management whitepaper https://cloudsecurityalliance.org/download/identity-and-access-management-for-the-iot/  
• Adrian - has recent experience & story - asking Kim or anybody -  talking about relationships with 50 billion things and privacy concerns - make assumption that scalability is going to create relationship specific technology - trying to introduce and understand and bring to UMA - question - in these groups - have you come across concept of not presuming any particular limit of technology (Open tech) for a single individual person would bring to the market? - ad blockers is a (bad) example - publishing industry - fact that Apple and other industries have given them ad blocking technology - conversation has shifted to how centralized is the technology - elephant in the room is to recognize whether the technology is under control of the individual, potential teacher, patient, etc. - growing very rapidly - only way to scale what's going to happen with IoT
• Kim - brought up that the scalability is a problem and an elephant in the room; think individuals will have ten things in the market; Look at driving the management from the individual - Life Management Platforms is an example of that;
• Adrian - even certificates are too centralized is an argument as well
• Sal - in terms of what is being done in his day job – a first step that needs to take place - make the complexity manageable - initial target for the IDmachines’ product  is person who is installing security systems - from a physical perspective especially - putting tools in their hands to manage the complexity - IoT is interesting use case - e.g., John Doe electrician installs smart meter, doesn't know anything about certificates, and how does he know that they are appropriate or not; Not opening a browser on an IoT device - need to create tools that can be used to accomplish some of these things; - happens to be where this solution is focused - same thing holds true for the individual – complexity is one reason identity relationship management is difficult – e.g. understanding an SLA, or configuring machines, or the cloaking people's ability to do that - complexity continues to outrun user or technician capabilities to really make IoT usable - may not be an ability to get to an end game but simply to claw but some ownership or control;
• Kim - we have only seen basic use cases;
• Sal - certificates are a basic component - getting all things that need to be done right in a certificate can be complex- looking at how this is done is useful – as a forward step determine what you can use to measure in a way that has good and bad outcomes
• Kim - key IRM in the Wild is the IoT use case example
• Ken - asked about Let's Encrypt
• Kim - we are watching it but they have a long way to go and to address IoT would be a stretch
• Sal - infrastructure moves slowly- unless you find some very large scale adopter - agree with Kim