Centre for Digital Public Infrastructure
english
english
  • THE DPI WIKI
    • 🎉About the DPI Wiki
    • 🔆What is DPI?
    • ✨DPI Overview
    • 📝DPI Tech Architecture Principles
      • 🔗Interoperability
      • 🧱Minimalist & Reusable Building Blocks
      • 💡Diverse, Inclusive Innovation
      • 💠Federated & Decentralised by Design
      • 🔐Security & Privacy By Design
    • 🎯DPI Implementation & Execution Guidance
    • 🆚DPG and DPI
    • ❓What DPI can I build?
    • 🥇First use case for DPI
    • 📘Inputs for designing a DPI informed digital transformation strategy
    • 💰How much does it cost to build DPI?
    • 📢Is my system a DPI?
      • TL; DR - Is my system a DPI?
  • Mythbusters and FAQs
    • 🔯DPI and Mandating Adoption
    • 🔯DPI and Private Competition
    • 🔯DPI and Privacy / Security
    • 🔯DPI and the Digital Divide
  • Technical Notes
    • 🆔Identifiers & Registries
      • Digital ID
        • Capabilities on ID system
        • ID-Auth
        • Face Authentication
        • eKYC/ Identity profile sharing
        • Single Sign On (SSO)
        • QR Code for Offline ID
    • 📂Data Sharing, Credentials and Models
      • A primer to personal data sharing
      • Data standards
      • Verifiable Credentials
      • Building Data Analytics Pipelines
      • eLockers
      • Non-personal Anonymised Datasets
    • 🔏Trust Infra
      • Digital Signatures and PKI
      • eConsent
      • eSign
    • 🛒Discovery & Fulfilment
      • Platforms to Protocols
    • 💸Payments
      • Financial Address
      • Interoperable QR Code
      • Interoperable Authentication
      • Interoperable Bill Payments
      • Cash in Cash Out (CICO)
      • Financial Address Mapper (G2P Connect)
      • G2P Payments
  • Initiatives
    • 🌐DPI advisory
    • 🚀DPI as a Packaged Solution (DaaS)
      • 💡Why do we need DaaS?
      • 🎯DaaS in a nutshell
      • 📦Pre-packaged DaaS kits
      • ♻️Reusable DaaS Artefacts
      • 3️⃣A 3-step process from idea to implementation!
      • 📈Funded DaaS Program overview
      • 👩‍💻Cohort 1: DaaS Offerings
        • Digital authentication
        • Digital credentials
        • ID Account Mapper
      • 🖥️Co-create with us!
      • 💬Upcoming DaaS cohorts
        • Functional Registries
        • AI Assistant
      • ❓FAQs on DaaS
        • Country x DPG MOU /LoI FAQs
        • Ecosystem Participation Terms FAQs
    • 📑DPI Residents Program
    • ⚖️DPI-CPA
    • 💸G2P Connect
    • 📨User Centric Credentialing & Personal Data Sharing
    • ⚕️DPI for Health
    • 🌍Agri Connect (forthcoming)
  • References
    • Glossary
    • Curated Specifications
  • Additional Info
    • 🤝Licensing
    • ✍️Contact Us
Powered by GitBook
On this page
Export as PDF
  1. Technical Notes
  2. Data Sharing, Credentials and Models

A primer to personal data sharing

PreviousData Sharing, Credentials and ModelsNextData standards

Last updated 9 months ago

Any interactions in a digital economy create huge swathes of data that if shared with the right stakeholder, can empower the owner to access a wide range of services. Globally, a lot of emphasis is placed on “data protection” which is ensuring that the individual’s data is protected from unauthorised access. It’s useful to think of data as a modern day currency that can be used to unlock services. This framing brings about a shift from the model of data protection to data protection & empowerment where the user is in control of their data (both privately & publicity held) and can freely share it. Opening up access to personal data, reference data sets (data used to define and classify other data), anonymised and aggregated data sets, training data and models also falls under the bucket of data empowerment.

Personal data sharing can take the form of verifiable credentials sharing or sharing of granular data with the requestor.

Broadly, we can identify three types of consented data sharing:

  1. Verifiable credentials using e-wallets

  2. System-to-system data sharing

  3. Consent-led data sharing using a network


  1. Verifiable credentials: A verifiable credential is a robust instrument of trust which is digitally signed, machine-readable and intended to serve as proof to presenters. Any certificate/ credential can be turned into and presented as a verifiable credential (for eg; Vaccination certificate, professional license, education records etc.) Sharing the verifiable credentials to any of the requesters through a digital wallet or any other means is a form of data sharing. It is also recommended that data principal’s consent be captured in this process. Common examples in healthcare are; sharing vaccination certificates, sharing of doctors’ professional certifications, etc.

  2. System-to-system data sharing: In many cases, there’s a need to share per-collected/ existing data internally (within departments that come under a single umbrella like the government) or within a group of trusted entities. In this case, a system-to-system data-sharing process can be put in place without involving the data principal. Data sharing open APIs and an authorization mechanism to verify the requestor’s permission will power this. This architecture should only be used in a high-trust environment. Common examples are the sharing of patients' data between two govt. programs etc. (It is strongly recommended to procure the data principal’s consent before the data sharing and to notify the data principal after the transfer.)

  3. Consent-led data sharing in a network: In this model, a network facilitates the exchange of data from the data providers to data users via the data principal (user). There's no centralised store of data and data flows real-time based on a request that carries the user's consent as well. The user is wholly in control in this framework. Three powerful technical building blocks can drive user centric, consented, real time data sharing, namely data sharing APIs, sector specific data schema and consent standard.

Cross-border data sharing

Cross border flows are simplest with user-led methods such as credentials, which don’t require issuing parties to have bilateral or multilateral agreements in place with every possible international verifier of a credential. Instead, any potential verifying entity of the credential who wishes to access the data can locally verify the digital signature to access the personal data presented by the user. The verifying entity should ensure to have access to (and cache with ttl - time to live settings) trust registries namely - global issuer list, corresponding verification keys & revocation list and credential data schema to accept credentials with higher trust and convenience to the presenter.

System-to-system data sharing in cross border use cases can require a slightly higher level of coordination between government departments, the establishment of international consent managers, supporting legal or regulatory frameworks, security clearances (for opening up of API ports) as well as interoperability of technical systems in order to be successful.

Federated anonymised data sets can be utilised for cross-border research and developmental initiatives as well through proper contextualisation of the data. Please refer for additional design choices to enable and access federated anonymised data sets.

📂
here