Defining an Architecture and Lexicon for VRM and Volunteered Personal Information
Conference Notes_iiw8 Room/Time: 1/E
Convener: Iain Henderson
Notes-taker:
Attendees:
Technology Discussed/Considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
25 yrs experience of building consumer db’s - around 10 yrs ago, concluded that the model won’t work. In CRM the promise of vendors building a DB, each building their own view of the consumer, ends up with a silo. So how would it be if you build the data structure on the side of the individual.
The legacy is that organizations hold the data, individuals end up having to run back and forth trying to maintain that data, largely out of their control
Displayed MyDex slide showing all of the silos with similar data architecture and similar issues trying to maintain the accuracy of the data. A well designed customer database has around 400 core attributes.
As an individual, you would need around 3,500 variables that would contain all the attributes that would require you to deal with all of the vendors you would have.
Around 9 years ago, a data architect was given the exercise of “If your house burned down, what data would you need to rebuild your life”. Came back with a model containing around 3,500 attributes.
How many of those were dependent vs. independent variables – e.g. how many depend on your physical address. The 3500 items is a normalized number. When you look closely at this, an individual has a number of personas that cover various firewalled aspect of their lives
Showed MyDex architectural slide containing planning systems and doing systems. A CRM ‘single view of customer’ is not really that.
When looking at this from an individual perspective, (see green and red slide) an individual contains many layer in their system, some of them manual (paper), some thought based (brain), some of them held by vendors (e.g. bank, insurer), some of them online (google, wesabe) etc.
See current slide – who has what data
An architecture for all of this data looks like a database, so will need C/R/U/D plus lock (permissions infrastructure). “lock” is a DB lock to prevent contention (transactional locking), but also a “lock” where permissions are enforced as to who can see / update / delete. So locking in the ACL sense. (Not worried about transactional locking)
Need a framework so you can do something. Then you can issue a card so that you can do stuff against this data. Diamond Frameword -6 different protocols that used different names.
Four actors As you can see at the left there are four actors. We introduce them now:
- U - A local User agent. It may be as little as a browser. It may include an OpenID, WS-*, password or SAML IdP, selector client. It may *include a local personal data store. It works on behalf of the user.
- R - A Relying or Receiving site or application
- P - A service or data Providing site
Medical Service conversations are coming upon the same set of discussions and conclusions
Raising the BS card – authentication vs. authorization. OpenID and SAML are authentication mechanisms
This diagram is authorizational concepts. There are policy asserters, decision points, assertion points and reponsitories. The problem is that there should be multiple entities for P, looking at P as a single entity will create confusion This is a useful diagram as it brings together the concepts, but you do need 3 entities, P1, P2 and P3. By the same token, each of the entities may need multiple instances. The asserting party in this case was the data authority. United airlines may be requester.
Proposal that VRM does live in the policy later, but we need to understand that policy needs to be under user control rather than vendor control. At the VRM workshop, there was a session on the Personal Datastore, this is the hingepoint of VRM. We may have multiple of those. Vendors all have the CRM side of the system, if two or more vendors want to collaborate to serve the individual, then they will have to exchange data. If you had a persona at in each of the CRM systems, then your cental datastore would be able to talk to your personas inside each of the CRM system. One of the key requirements there would be to look at all of the taxonomies and schemas sitting at the vendor side – your schema needs to be able to talk to all of these. (imagine the integration required simply within each of the systems). First you need to create a system whereby the user can manage their personal data store. The challenge is that there a known mappings – for example credit card and banking systems. There is a distinction between known mapping that the systems understand it and the user having some transparency into this system and the relationships.
Are we suggesting that the user should be involved in rationalizing their data. If there is a financial incentive, then it will happen. E.g. Visa and the bank. If the user had enough financial incentive, then they will do this.
Can users do the mapping? There is a new class of service provider (4th party) who are the custodians of the data. CRM systems are based on some data and the vendor guessing the rest of the way about what you want. A user should be able to make a request of the vendor and rely on that vendor not to upsell, cros-sell, etc. – a pure service. The person at the center of the system, in reality, the attributes of that user are not really owned by the user. The control is the person that controls access to the data. The individual will appoint a party to manage their data on their behalf. In many cases, what entities need are not values of the attribute itself, but confidence that the data is true and accurate. Amazon doesn’t need to have my CC number, but only the authorization from Visa that the bill will be paid.
