Based on the discussion this afternoon at iiw#7, here is my initial thoughts on the “policy/principle” and “criteria” that a VRM compliant service should fulfill. They actually are the underling abstract model of the proposed OpenID TX extension (now renamed to be something like CX, contract exchange), OpenID CX being a profile of it onto the OpenID framework.
- User owns his own data – he has full authority and control over them.
- User offers his own data to the vendors for a particular purpose on consent to meet his/her needs.
- Vender/Service must present a very specific data usage purpose clearly and must abide to it.
- Duration for the data usage and storage must be defined.
- User must be able to cancel the contract with an appropriate wind down time.
- User must be able to download all his data in a standard format from the vendor/service.
- User is able to delete his data at the vendor/service anytime he wishes except for the data the vendor is required to keep for legal compliance.
- Notification method should the violation to the contract term arise for each party must be defined.
- Restitution measures must be defined for the cases of inappropriate data usage and data leakage.
- All the above must be included in the relationship contract and mutually digitally signed with date.
- For long-term contracts, third party time stamping (digital signature with newer algorithms and date) must be done regularly to cope with algorithm compromise risk.
- All the data transfer/exchange must occur based on this contract.
In OpenID CX (formally TX), there will be a mutually digitally signed contract format defined with request-response protocol for creating it. All the subsequent data exchange will occur based on this contract. It would appear to me that the r-button state with joined sideway Us are nothing but the state that the above contract is in effect.
Note: An extremely long thread has started off from this message of mine to the ProjectVRM list. You may want to see them as well.
*1 I have modified the original message a bit by separating out the Tools from the Criteria. Paul Madsen pointed out that it would be better not conflate Criteria with Tools and I fully agree. Thanks Paul!