Tokenization with DID’s?
Tokenization with DIDs?
Tuesday 2L
Convener: Trent Larson
Notes-taker(s): Trent Larson
Tags for the session - technology discussed/ideas considered:
Blockchain, DIDs, property
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Link to PPR Information Governance Label Doc: bit.ly/PPR-IGL
Formed from work on Patient Privacy Rights (PPR)
- Shift risk to consumer or service provider (supplier)
- Facebook/Cambridge analytics
- Nutrition information on food
- Variation on Privacy by Default (e.g., HIPAA)
Service App ranks 0-5 √
- 1. No sharing: The data is never shared with any external entities. It is not even shared in de-identified form.
- 2. No aggregation: The data is never aggregated with other types of input or data from external sources. This includes mixing the data gathered via The Device with other data, such as patient-reported outcomes.
- 3. Always voluntary self-identification: The user of The Service is able to choose their own identity, the user does not need to have their identity verified unless required by law.
- 4. Digital Agent Support: The user is able to specify a digital agent, trustee, or equivalent information manager, and this specified agent will not be subject to certification or censorship.
- 5. No vendor lock-in: This service is easily and conveniently substitutable, so the user can easily move their data to another vendor providing a similar services. This prevents vendor lock-in and is often accomplished using Open Standards.
- [6. Differential Privacy] removed because it could be gamed.
Indications for Use: The five separately self-asserted statements on the PPR information Governance Label are subject to legal enforcement as would the privacy policy associated with The Service
Objections:
A. Could decrease sharing which could be damaging to community benefit (e.g., science)
B. Aggregation may restrict functionality
++C. Does not state how data will be used (stated positive purpose of use)
D. Not useful if no choice
E. Too “strong” or “rigid”
F. Privacy by default is [could be] antisocial
G. Needs ordinal checkboxes (red-yellow-green)
H. 5. No vendor lock-in is too loose to be useful
H2. Bundling of service is discouraged
Vendor lock-in has to be “loose”
I. Too philosophical