Date
February 23rd, 2016
Attendees
- 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
| 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) - Provide supporting materials for the SalesForce IoT Implementation discussed on the call (e.g., architecture, demo environment, etc.)
Submitted Links
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