Tokenization with DID’s?

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

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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:

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


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