Tokenization with DID’s?

From IIW
Revision as of 03:03, 29 May 2019 by Iiwnotes (talk | contribs)

Jump to: navigation, search

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


IIW28 TU 2L Tokenization with DIDs.jpg