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. Trust Infra

eConsent

PreviousDigital Signatures and PKINexteSign

Last updated 1 year ago

In any sector, the stream of personal data generated during every transaction enables better decision-making and service delivery. It’s imperative to empower users by enabling consented sharing of granular personal data in a secure, privacy-protected manner. In any user-driven data-sharing framework, the data consumer needs to request the user for their personal data by specifying the quantum of data required, the purpose it’s going to be used for, the duration the data is needed for, the frequency of data pull etc. This step is a precursor to the actual sharing of data by the data provider. Maintaining logs of the agreed-upon data-sharing transaction in a non-repudiable, auditable fashion is a key check.

Electronic consent is an artefact/ data structure that records and stores the consent for that data-sharing agreement. Technically, it is a machine-readable electronic document that specifies the parameters and scope of data share that a user consents to in any data sharing transaction.

The consent artefact in general consists of the following sections:

  1. Identifier section: Identifies and lists all the entities involved in a data-sharing transaction; the data provider, the data consumer, the individual, and any other intermediary

  2. Data section: This section describes the type of data & permissions of the data being accessed including the data fields, date range of data, duration of access, frequency of access, etc. The purpose for which the data is to be accessed should be clearly defined as well.

  3. Signatures: Each consent artefact should include a signature block with signatures of one or more entities as defined in the framework

The electronic consent framework should be programmable, i.e should allow for condition based consent approval with required checks. (eg: Automatic consent approval for access to blood group, allergies, etc, in an emergency)

Reference :

πŸ”
MeitY-Consent-Tech-Framework