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. Initiatives
  2. DPI as a Packaged Solution (DaaS)
  3. FAQs on DaaS

Ecosystem Participation Terms FAQs

PreviousCountry x DPG MOU /LoI FAQsNextDPI Residents Program

Last updated 5 months ago

Please see the DaaS legal framework

Q. What’s the overall legal framework of DaaS?

A. There are 4 parties involved in DaaS:

  1. DaaS Country Partner - the Country department which is executing the DaaS package

  2. DaaS DPG Partner - the DPG which is providing the DaaS product to be deployed in the country

  3. Service Provider(s) - the entity(ies) that will deploy, maintain and provide the technical support during the pilot of DaaS

  4. Advisor - the partner covering all advisory ( managerial, technical, legal etc)related to DaaS. For the first cohort, this will be the Centre for DPI.

These parties interact with each other in the following ways:

  1. LoI or MOU between DaaS Country Partner and DaaS DPG Partner

  2. Ecosystem Participation Terms signed by all SPs and DPGs part of the DaaS ecosystem

  3. MOU or LoI between the DaaS Country Partner and the Advisor (optional)

Q. Why have ecosystem participation terms instead of bilateral contracts between the DPG and SP?

A. Bilateral contracts usually undergo lengthy negotiation processes before each signing and due to this, the terms agreed to by different DPGs and SPs would differ. Due to this, the countries would have no common bar on how to assess the offerings by the DPGs and the SP selection committee would have no common bar on how to judge the SPs bidding for a project. The goal of the EPT is to align all parties into basic foundational clauses such as cyber security, data portability, open source code etc. to adhere to the 'rapid deployment' and 'standardisation' goals of DaaS.

Q. Will SPs still need an additional bilateral contract to close on compensation and other details of implementation that cannot be standardised?

A. The 'contract' in this case is a multi-party contract termed as Ecosystem Participation Terms that lay out the general contracting clauses of any DaaS implementation. The country-specific implementation details are governed by the 'Country Scope Document' which is signed off on by the Country and DPG, and signed by the implementing SP - this also indicates the compensation amount, deliverables, payment schedules etc. which would typically be covered under a special contracting clause.

Q. When do EPT terms kick in?

A. The EPT comes into force only for the DPG and SP chosen for a particular implementation post the signing of the country scope document.

Q. Why does the MOU restrict Service Providers from using code under their own IP that is not available through open source?

A. The principle behind DaaS is standardisation and productization. This means that all the products available through the DaaS program must be exactly replicable and rapidly executable for multiple countries, hence it involves standard legal frameworks, product kits, funding amounts etc. If a service provider brings in their own proprietary code or IP into the execution cycle, multiple scenarios separate from the best practices of DaaS may play out:

  1. The country may get locked-in to that particular service provider since a new vendor will not have access to that code or IP

  2. It will prevent the country or DPG from switching service providers mid-way in case of any contingency

  3. The same DaaS product if deployed in another country with another service provider will see a different execution with different features since the code will not be replicable and it will defeat the purpose of DaaS

Q. So can I as a Service Provider take the base-line open source product and pitch it to countries myself without DaaS?

A. Of course! In the initial cohorts of DaaS, the DPGs provide training and capacity building for service providers on their products. Once a service provider feels sufficiently empowered, they are free to approach countries directly and deploy the open source code on their own, enhanced by their own IP as they see fit.

Q. Why aren't cloud providers included in the EPT?

A. Cloud providers typically have back-to-back contractual agreements with the SP to support on country deployment. From a DaaS implementation perspective, we did not want to distribute the accountability among various participating entities so we restricted it to SPs who receive the compensation from the DPGs for implementation and are thus, responsible for its timely execution. Cloud providers would operate as an entity under the SPs.

However, similar to SPs, cloud providers are also empowered to individually utilise DaaS artefacts and open source DPG code to implement independently in countries.

πŸš€
❓
here