2016-02-23 Meeting Notes

Date

February 23rd, 2016

Attendees

• Former user (Deleted)

• Salvatore D'Agostino

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

Goals

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

Discussion Items

Action Items

• Former user (Deleted) - Provide supporting materials for the SalesForce IoT Implementation discussed on the call (e.g., architecture, demo environment, etc.) 

Submitted Links

Salesforce Identity for IoT documentation

High-level Topics Covered

• Role call
• IRP Update
• Principles Update - v.1.1
• IRM in the Wild
  • Walked through Ian's (SalesForce) IoT Example & Implementation

Detailed Meeting Notes

• Everyone is familiar with IPR
• No new intros or particular announcements
• People going to be at RSA - whole bunch of events
• Notes are available from the 5th of January
• Need to update Wiki - way too many voting members
• Any questions about meeting minutes - send message to Sal or Kim
• Principles in Wiki
• Going through use cases and things people have been throwing out there
• Rerun of principles
• Role for relationship manager
• Catching architecture notions
• Asking Ian - thoughts on pursuing this task?
• Ian - likes it
• Mixed bag of examples
• Ian - DNS is refreshing - question - 9 principles - we did down select - should we reflect current state of principles?
• Sal- yes we absolutely should reflect this
• Ian - we did down select from original 9 - how have we been soliciting for real world examples?
• Sal - anybody who put their hand up with an idea - we ran with it - basic vetting of whether approach is helpful - real world use cases - vary from specific technical DNS to refugee problem
• Ian - whoever has the next reasonable idea? - pattern deployment on IoT - people to connected things
• Ian - IoT/Salesforce - something that is new in latest release - send overview description
• Kim - brings up Strong Device ID use case as well
• Sal - definitely good to look at the gamut - Ian is going to start
• Steve - question - "on behalf of" was mentioned - concern - people talking about agency - transferable/delegation - same thing? - or agency is something different which should be called out
• Ian - as document stands today - transferable/delegation - permanent transfer of control - by we don't talk about "on behalf of" - probably a glaring omission - need to revisit in principles- as well as start to look at in these patterns
• Steve - "T word" who do you trust to be your agent and accurately reflect your desires - how do you determine that trust? - worthy of trust
• Ian - with IoT scenario - some chaining going on - may have gaps in the chain - not unique to only their pattern of department
• Adrian - very interested in what Salesforce is thinking about in IoT space - appreciate in parallels to also bring up what they'll do in healthcare - these are the two use cases he bounces back and forth in
• Ian - crash course in CRM 101 & data model - working with customers on IoT patterns for 5 years - different forms - pre-IoT hype - bunch of life science scenarios - basic data model = account (organization - e.g., company you do business with), associated with accounts are contacts (people - simple entries into rolodex), object call Asset - extensible representation of one of your products (e.g., washing machine not working and want warranty info = washing machine is an asset) - parent relationship between contact & assets;
• Often done - customers will do just that - assets - associate with contacts - sales can see they own X product
• Over 5 years - OAuth brokered API governance - more robust connected devices can grab OAuth token to connect to Salesforce - send back details to Salesforce
• Customers using this in conjunction with another aggregation tier - they didn't have great place to billions/trillions message for business processes
• Other vendor aggregation sources
• Example is trigger service technician to asset
• Now offering "asset tokens"
• Smart lightbulbs with app on mobile phone to pair with lightbulbs, control lightbulbs etc. and lightbulbs are also sending messages to aggregation platform
• After pairing process - pair lightbulbs to mobile app
• Now can issue asset tokens -
• substantiate a new asset - ID, metadata, also gave certificate which was minted on it
• New asset to record lightbulb
• Asset token for that
• Assign token with key material
• Associated with you as you signed on to create the process
• Can identify the asset token - ID of device in it, metadata, etc. - present back to lightbulb
• Token which has "proof of possession"
• Can present asset token to back end to do things on your behalf
• Salesforce has "IoT Cloud Backend"- cryptographically confirm it was issued by us, contextual information on individual, etc. enough context for backend to do "stuff" or "orchestration"
• Sal - "issued by us" means Salesforce? Or account owner?
• Ian - Salesforce mints the token - key material and context from "you" as a tenant
• Adrian - is Salesforce acting as an UMA authorization server?
• Ian - no - we have not implemented UMA - issuing jobs and connecting device to contact - token which has been minted as a "marker of agency" for that person - maps to some things which are UMA like
• Sal - describing things we did for early implementations of physical access years ago - ability to do distributed relationship management - overlap with UMA - a lot lighter
• Ian - behind every connected device is a customer - serving person entity and they server their entities - corporate alignment - platform for connected devices - view it as "bought hot tube from you - not working - send someone to fix it" - want hot tub to put out "state data" about current health - all about connection between individual, and connected devices, and relationship to you our customers
• Token helps bind individuals to connected devices - connected device can present themselves to backend - I have more information about device and context - use that to action or end desired
• Ian - give some examples of how asset tokens will be used:
• Medical - want to release connected asthma inhaler - dream - if it hasn't been used in amount of time - trigger phone call from RN - "noticed that you haven't been using it - lost? Difficulty using? Instructions? Etc." - improve quality of care - associate "you" with inhaler - process message stream in context of patient, with consent information, to improve outcome of inhaler
• Ian - overview of asset tokens and practical implication
• Ken - minutes - provide an architectural diagram?
• Ian - yes - point to documentation on this - they have stood up "playground" on this - not very meaningful without developer instance - he'll provide reference links
• Sal - approach - registered everything - one of the tricky parts - how do you register everything/players? - Nature of Salesforce that's where you start - really helpful in getting this done
• Ian - some regards punted on discovery process - you're the device manufacturer who has the devices - you'll manage pairing and association - doing through website or app for individual to do this to - Salesforce handles association between the thing and the person - logical places to interact - not whole problem for multi device protocol discovery
• Sal - way to do it - makes sense - position with Salesforce to take that approach - what Salesforce was put in place to do - interesting - rather than popping up "you haven't called this client in 6 weeks" now you can say "your inhaler hasn't been used" - preventative maintenance has huge returns
• Ian - older cases - customers using in OAuth brokered API - manually creating linkage - customers - motorcycle company has connected motorcycle - case deflection by 20% - information off of bike gives maintenance information - giving CRM to do that - extended to get signal from connected bike - some is core notion of CRM platform does - adding "Asset Token" notion or other pieces to further orchestrate business processes
• Steve - customers problem to solve is establishing owner of device and actual device - identity stuff - left in customers hands to solve - always been the Bermuda triangle - too many ways to do it - companies don't want to outsource identity assurance - tackle token authentication part alone - bitable chunk that they can do
• Ian - interesting parsing - device discovery part is a morass - know how to relate different objects in the platform - whether individual is actively signing in to an app or the master of these connected devices or not - or inert contact record - record created because of surgery for "connected knee" - enrollment in a program - someone is manually asserting your identity - haven't mandated that the individual hasn't provided a credential - optional part of the flow - customers with business processes which only requires a sale person entering in a contact, vs. customer logging in with Facebook because they want to control lightbulbs - right sizing the assurance part of the relationship for the individual is up to the customer based on user perspective - strong opinions over assurance part of the identity
• Steve - referring to asset token and asset authentication  - versus individual associated with that asset
• Ian - doing at least IdP chaining - connected asthma inhaler - customer is building ID hub - registering their consent and privacy preferences - going to serve as nucleus for when they roll out connected devices
• Steve - they are controlling identity preferences - versus asset and backend - which is something Salesforce can control - approach which Government of Canada used - took care of token authentication part to allow clients to access backend services
• Ian - not this call - but we should walk that scenario as it has similarities - similar to FICAM - see relationship-ness of these type of national ID schemes - if interesting patterns would be good to comment on
• Steve - FICAM and Gov. of Canada has been related - Secure Key and post office solution in the states is very similar
• Sal - do we want to try going through the principles with this scenario?
• Scalable:
• Ian - would say so but with caveat - go across axis- raw device data stream = insanely large = reason for IoT cloud - vs. identity (asset tokens) goes to millions - time is going to tell how scalable - distributed across all customers - some have tens of millions or tens of thousands
• Sal - reality of IoT - you address scalability across all IoT use cases is marketing - partial is the reality of IoT
• Actionable:
• Ian - substantiation of an asset token - nature of the token - can write triggers on object creation, etc.
• Mutable/Immutable:
• Ian - tokens rely on any data that connected device hands it such as device ID - can control mutability on all fields - good amount of control over mutability
• Sal - option to do it and control it
• Ian - we are relationship manager and can control rules
• Steve - how they are enforced and followed
• Ian - how they are delegated as well - traditional delegated admin - we are the relationship manager
• Contextual:
• Ian - can be - provides context of who individual associated with "thing" is - enough to clear hurdle - does have relationship context with objects existence
• Token in relationship? - don't think so as we don't stamp the individuals ID to token - maybe they do - GUID which does get stamped back into token - almost certain they do have context of individual
• Sal - account has context
• Ian - one "hop" away from lookup - depends on constraints on device - how much is on the wire…
• Transferrable (Delegation):
• Ian - interesting one - can re-assign assets to other people - but in order to do that have to re-mint asset tokens - relationship or link is reassigned - but you have to inform new "edge" or "link" - relationship manager representation - however backend is seeing it as a representation of "agency"
• Would like to do - be able to dynamically scope permissions based on context - e.g., logged into app on mobile device - app should only be able to use subset of permissions - extend to asset token only has subset of permissions - authorization enforcement model
• Sal - you can set user privileges as well?
• Ian - yes - this is more like individual user has a pie chart, "whole pie" but in this context only get "X slice" of that pie
• Provable:
• Ian - optionally you can sign the material from the device - can have HoK (signed JWT via JOSE)
• Acknowledgeable:
• Ian - assert tokens to the contact or person - person knows about assets or devices - as they want control over them - may not be entirely aware - may be able to assert to individual or someone acting on their behalf
• Revocable:
• Ian - yes - functionality is being released as a pilot - tokens exist until you delete them currently -
• Constrainable:
• Ian - new endpoint for asset tokens - push attributes of claims to asset tokens which is pushed to backend - instead of bloating token - can look at contextual information from Salesforce - no formalized pattern for that yet - do have robust model for data access - this is from device perspective

• Adrian - consumer perspective instead of SF customer - if I have connected inhaler or lightbulb - want technology to aggregate "X" about these things - proxy that he controls between things and systems like Salesforce - where in our list of principles do we consider that?
• Ian - adding in agent for another purpose
• Sal - access control proxy - taking advantage of granularity of what you have in your system
• Ken - proxy so relationship needs to exist between device and proxy and proxy and outside role - two parts to put through relationship analysis
• Sal - proxies are everywhere - Salesforce probably wants to go down path of providing proxy
• Ian - APIs to leverage everywhere - relationships have to be mapped and managed in similar fashion - capability of relationship manager to accommodate or facilitate - points towards other responsibilities in this mess
• Ken - relationship manager in this proxy to manage devices it associates with and then other manager who handles proxy
• Adrian - only two kinds of devices in this world - whatever API or System we come up with - where "I" can have agency independent of system or vendor is used - and those where I can't - struggling with this in the UMA group - example of door lock - when purchasing door lock - two possibilities - I have absolute agency or I don't - not meaning I can do everything - but I have visibility on what the door lock is doing to my proxy
• Sal - we can do physical access use case
• Ian - has to jump off call
• Sal - went over time but excellent call - no admin actions beyond - going to try to draft response for SC Magazine - anyone has examples or points they'd like to provide - add quote and name in the article would be great - he'll share with group once something is put together - in 48 hours