2016-02-23 Meeting Notes

Date

February 23rd, 2016

Attendees

Goals

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

Discussion Items

TimeItemWhoNotes
2 minsKantara IPRSal
2 minsRoll CallSal
  • Roll, new intros, announcements
4 minsMinutes/Notes UpdateSal

45 mins

IRM in the WildAll
  • Discussion of IRM in the wild - Consolidating the Use Cases
1 minOther AdminAll
  • Other Administrative, Action Item Review (not covered above) 
1 minAoBAll
  • AoB TBD...

Action Items

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

 

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