This document provides specifications for APIs that issuers can use to push documents to and pull documents from the Digital Locker repository. It describes the document codification scheme including assigning a unique document URI composed of the issuer ID, document type, and document ID. It also outlines the on-boarding flow for issuers which involves generating document URIs, uploading metadata to map URIs to documents, and creating APIs for pushing documents and pulling document metadata. The revision history shows recent updates to the specifications.
Activate Data Governance Using the Data CatalogDATAVERSITY
Data Governance programs depend on the activation of data stewards that are held formally accountable for how they manage data. The data catalog is a critical tool to enable your stewards to contribute and interact with an inventory of metadata about the data definition, production, and usage. This interaction is active Data Governance in the truest sense of the word.
In this RWDG webinar, Bob Seiner will share tips and techniques focused on activating your data stewards through a data catalog. Data Governance programs that involve stewards in daily activities are more likely to demonstrate value from their data-intensive investments.
Bob will address the following in this webinar:
- A comparison of active and passive Data Governance
- What it means to have an active Data Governance program
- How a data catalog tool can be used to activate data stewards
- The role a data catalog plays in Data Governance
- The metadata in the data catalog will not govern itself
A Reference Process Model for Master Data ManagementBoris Otto
The management of master data (MDM) plays an important role for companies in responding to a number of business drivers such as regulatory compliance and efficient reporting. With the understanding of MDM’s impact on the business drivers companies are today in the process of organizing MDM on corporate level. While managing master data is an organizational task that cannot be encountered by simply implementing a software system, business processes are necessary to meet the challenges efficiently. This paper describes the design process of a reference process model for MDM. The model design process spanned several iterations comprising multiple design and evaluation cycles, including the model’s application in three participative case studies. Practitioners may use the reference model as an instrument for the analysis and design of MDM processes. From a scientific perspective, the reference model is a design artifact that represents an abstraction of processes in the field of MDM.
Activate Data Governance Using the Data CatalogDATAVERSITY
Data Governance programs depend on the activation of data stewards that are held formally accountable for how they manage data. The data catalog is a critical tool to enable your stewards to contribute and interact with an inventory of metadata about the data definition, production, and usage. This interaction is active Data Governance in the truest sense of the word.
In this RWDG webinar, Bob Seiner will share tips and techniques focused on activating your data stewards through a data catalog. Data Governance programs that involve stewards in daily activities are more likely to demonstrate value from their data-intensive investments.
Bob will address the following in this webinar:
- A comparison of active and passive Data Governance
- What it means to have an active Data Governance program
- How a data catalog tool can be used to activate data stewards
- The role a data catalog plays in Data Governance
- The metadata in the data catalog will not govern itself
A Reference Process Model for Master Data ManagementBoris Otto
The management of master data (MDM) plays an important role for companies in responding to a number of business drivers such as regulatory compliance and efficient reporting. With the understanding of MDM’s impact on the business drivers companies are today in the process of organizing MDM on corporate level. While managing master data is an organizational task that cannot be encountered by simply implementing a software system, business processes are necessary to meet the challenges efficiently. This paper describes the design process of a reference process model for MDM. The model design process spanned several iterations comprising multiple design and evaluation cycles, including the model’s application in three participative case studies. Practitioners may use the reference model as an instrument for the analysis and design of MDM processes. From a scientific perspective, the reference model is a design artifact that represents an abstraction of processes in the field of MDM.
Strategic Approach To Data Migration Project PlanSlideTeam
Presenting this set of slides with name Strategic Approach To Data Migration Project Plan. This is a six stage process. The stages in this process are Plan, Develop, Validate, Migrate Stage, Test. This is a completely editable PowerPoint presentation and is available for immediate download. Download now and impress your audience. https://bit.ly/3CTswep
Self-issued OpenID Provider_OpenID Foundation Virtual Workshop Kristina Yasuda
Presentation I gave on Self-Issued OpenID Provider during the second OpenID Foundation Virtual Workshop covering:
1. What is Self-Issued OpenID Provider (SIOP) ?
2. SIOP Requirements (draft)
3. Initial discussion points deep-dive
Self-Issued OpenID Providers are personal OpenID Providers that issue self-signed ID Tokens, enabling portability of the identities among providers
The first step towards understanding data assets’ impact on your organization is understanding what those assets mean for each other. Metadata — literally, data about data — is a practice area required by good systems development, and yet is also perhaps the most mislabeled and misunderstood Data Management practice. Understanding metadata and its associated technologies as more than just straightforward technological tools can provide powerful insight into the efficiency of organizational practices, and enable you to combine practices into sophisticated techniques, supporting larger and more complex business initiatives. Program learning objectives include:
* Understanding how to leverage metadata practices in support of business strategy
* Discuss foundational metadata concepts
* Guiding principles for and lessons previously learned from metadata and its practical uses applied strategy
* Understanding how to leverage metadata practices in support of business strategy
* Metadata strategies, including:
* Metadata is a gerund so don’t try to treat it as a noun
* Metadata is the language of Data Governance
* Treat glossaries/repositories as capabilities, not technology
This webinar we will focus on products of Tableau, it’s data preparation and analytics capabilities and evaluate its features with that of other leading BI tools.
Introduction to QuerySurge Webinar
Wednesday, April 29th 2020 @11am ET
Eric Smyth, Director of Alliances
Bill Hayduk, CEO
Matt Moss, Product Manager
This is the slide deck for our webinar. Learn how QuerySurge automates the data validation and testing of Big Data, Data Warehouses, Business Intelligence Reports and Enterprise Applications with full DevOps functionality for continuous testing.
---------------------------------------------------------------------------------
Objective
During this webinar, we demonstrate how QuerySurge solves the following challenges:
- Your need for data quality at speed
- How to automate your ETL testing process
- Your ability to test across your different data platforms
- How to integrate ETL testing into your DataOps pipeline
- How to analyze your data and pinpoint anomalies quickly
-------------------------------------------------------------------------------------
Who should view this?
- ETL Developers /Testers
- Data Architects / Analysts
- DBAs
- BI Developers / Analysts
- IT Architects
- Managers of Data, BI & Analytics groups: CTOs, Directors, Vice Presidents, Project Leads
And anyone else with an interest in the Data & Analytics space who is interested in an automation solution for data validation & testing while improving data quality.
Architect’s Open-Source Guide for a Data Mesh ArchitectureDatabricks
Data Mesh is an innovative concept addressing many data challenges from an architectural, cultural, and organizational perspective. But is the world ready to implement Data Mesh?
In this session, we will review the importance of core Data Mesh principles, what they can offer, and when it is a good idea to try a Data Mesh architecture. We will discuss common challenges with implementation of Data Mesh systems and focus on the role of open-source projects for it. Projects like Apache Spark can play a key part in standardized infrastructure platform implementation of Data Mesh. We will examine the landscape of useful data engineering open-source projects to utilize in several areas of a Data Mesh system in practice, along with an architectural example. We will touch on what work (culture, tools, mindset) needs to be done to ensure Data Mesh is more accessible for engineers in the industry.
The audience will leave with a good understanding of the benefits of Data Mesh architecture, common challenges, and the role of Apache Spark and other open-source projects for its implementation in real systems.
This session is targeted for architects, decision-makers, data-engineers, and system designers.
Informatica Cloud Services deliver purpose-built data integration cloud applications to allow business users to integrate data across cloud-based applications and on-premise systems and databases. Informatica Cloud Services address specific business processes (customer/product master synchronization, opportunity to order, etc.) and point-to-point data integration (e.g. Salesforce.com to on premise end-points).
Why an AI-Powered Data Catalog Tool is Critical to Business SuccessInformatica
Imagine a fast, more efficient business thriving on trusted data-driven decisions. An intelligent data catalog can help your organization discover, organize, and inventory all data assets across the org and democratize data with the right balance of governance and flexibility. Informatica's data catalog tools are powered by AI and can automate tedious data management tasks and offer immediate recommendations based on derived business intelligence. We offer data catalog workshops globally. Visit Informatica.com to attend one near you.
Decentralized identity uses standards to create an interoperable language for new identity products and services to be build. Using Verifiable Credentials and Decentralized Identifiers.
https://gcomsolutions.co.uk/power-bi-proof-of-concept -
G Com Solutions’ one-week Power BI Proof of Concept helps IT departments and data analysts to demonstrate Power BI’s features and benefits to key stakeholders, enabling them to gauge how well Power BI addresses their business needs.
Strategic Approach To Data Migration Project PlanSlideTeam
Presenting this set of slides with name Strategic Approach To Data Migration Project Plan. This is a six stage process. The stages in this process are Plan, Develop, Validate, Migrate Stage, Test. This is a completely editable PowerPoint presentation and is available for immediate download. Download now and impress your audience. https://bit.ly/3CTswep
Self-issued OpenID Provider_OpenID Foundation Virtual Workshop Kristina Yasuda
Presentation I gave on Self-Issued OpenID Provider during the second OpenID Foundation Virtual Workshop covering:
1. What is Self-Issued OpenID Provider (SIOP) ?
2. SIOP Requirements (draft)
3. Initial discussion points deep-dive
Self-Issued OpenID Providers are personal OpenID Providers that issue self-signed ID Tokens, enabling portability of the identities among providers
The first step towards understanding data assets’ impact on your organization is understanding what those assets mean for each other. Metadata — literally, data about data — is a practice area required by good systems development, and yet is also perhaps the most mislabeled and misunderstood Data Management practice. Understanding metadata and its associated technologies as more than just straightforward technological tools can provide powerful insight into the efficiency of organizational practices, and enable you to combine practices into sophisticated techniques, supporting larger and more complex business initiatives. Program learning objectives include:
* Understanding how to leverage metadata practices in support of business strategy
* Discuss foundational metadata concepts
* Guiding principles for and lessons previously learned from metadata and its practical uses applied strategy
* Understanding how to leverage metadata practices in support of business strategy
* Metadata strategies, including:
* Metadata is a gerund so don’t try to treat it as a noun
* Metadata is the language of Data Governance
* Treat glossaries/repositories as capabilities, not technology
This webinar we will focus on products of Tableau, it’s data preparation and analytics capabilities and evaluate its features with that of other leading BI tools.
Introduction to QuerySurge Webinar
Wednesday, April 29th 2020 @11am ET
Eric Smyth, Director of Alliances
Bill Hayduk, CEO
Matt Moss, Product Manager
This is the slide deck for our webinar. Learn how QuerySurge automates the data validation and testing of Big Data, Data Warehouses, Business Intelligence Reports and Enterprise Applications with full DevOps functionality for continuous testing.
---------------------------------------------------------------------------------
Objective
During this webinar, we demonstrate how QuerySurge solves the following challenges:
- Your need for data quality at speed
- How to automate your ETL testing process
- Your ability to test across your different data platforms
- How to integrate ETL testing into your DataOps pipeline
- How to analyze your data and pinpoint anomalies quickly
-------------------------------------------------------------------------------------
Who should view this?
- ETL Developers /Testers
- Data Architects / Analysts
- DBAs
- BI Developers / Analysts
- IT Architects
- Managers of Data, BI & Analytics groups: CTOs, Directors, Vice Presidents, Project Leads
And anyone else with an interest in the Data & Analytics space who is interested in an automation solution for data validation & testing while improving data quality.
Architect’s Open-Source Guide for a Data Mesh ArchitectureDatabricks
Data Mesh is an innovative concept addressing many data challenges from an architectural, cultural, and organizational perspective. But is the world ready to implement Data Mesh?
In this session, we will review the importance of core Data Mesh principles, what they can offer, and when it is a good idea to try a Data Mesh architecture. We will discuss common challenges with implementation of Data Mesh systems and focus on the role of open-source projects for it. Projects like Apache Spark can play a key part in standardized infrastructure platform implementation of Data Mesh. We will examine the landscape of useful data engineering open-source projects to utilize in several areas of a Data Mesh system in practice, along with an architectural example. We will touch on what work (culture, tools, mindset) needs to be done to ensure Data Mesh is more accessible for engineers in the industry.
The audience will leave with a good understanding of the benefits of Data Mesh architecture, common challenges, and the role of Apache Spark and other open-source projects for its implementation in real systems.
This session is targeted for architects, decision-makers, data-engineers, and system designers.
Informatica Cloud Services deliver purpose-built data integration cloud applications to allow business users to integrate data across cloud-based applications and on-premise systems and databases. Informatica Cloud Services address specific business processes (customer/product master synchronization, opportunity to order, etc.) and point-to-point data integration (e.g. Salesforce.com to on premise end-points).
Why an AI-Powered Data Catalog Tool is Critical to Business SuccessInformatica
Imagine a fast, more efficient business thriving on trusted data-driven decisions. An intelligent data catalog can help your organization discover, organize, and inventory all data assets across the org and democratize data with the right balance of governance and flexibility. Informatica's data catalog tools are powered by AI and can automate tedious data management tasks and offer immediate recommendations based on derived business intelligence. We offer data catalog workshops globally. Visit Informatica.com to attend one near you.
Decentralized identity uses standards to create an interoperable language for new identity products and services to be build. Using Verifiable Credentials and Decentralized Identifiers.
https://gcomsolutions.co.uk/power-bi-proof-of-concept -
G Com Solutions’ one-week Power BI Proof of Concept helps IT departments and data analysts to demonstrate Power BI’s features and benefits to key stakeholders, enabling them to gauge how well Power BI addresses their business needs.
This presentation gives an overview on the work that is going on at OpenID Foundation in Liaison with Decentralized Identity Foundation to enable SSI applications based on OpenID Connect.
OpenID for Verifiable Credentials is a family of protocols supporting implementation of applications with Verifiable Credentials, i.e. verifiable credential issuance, credential presentation, and pseudonyms authentication.
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...Torsten Lodderstedt
This deck gives an overview of OpenID 4 Verifiable Credentials and shows how the specs can be tailored to the needs of a certain category of projects/ecosystems.
Enterprise & Web based Federated Identity Management & Data Access Controls Kingsley Uyi Idehen
This presentation breaks down issues associated with federated identity management and protected resource access controls (policies). Specifically, it uses Virtuoso and RDF to demonstrate how this longstanding issue has been addressed using the combination of RDF based entity relationship semantics and Linked Open Data.
OpenID Connect 4 SSI aims at specifying a set of protocols based on OpenID Connect to enable SSI applications. The initiative is conducted at OpenID Foundation in liaison with the Decentralized Identity Foundation (DIF). One of the specifications is built up on DID-SIOP in DIDAuth WG in DIF and SIOP v1 in OIDC Core.
Scalable Data Management: Automation and the Modern Research Data PortalGlobus
Globus is an established service from the University of Chicago that is widely used for managing research data in national laboratories, campus computing centers, and HPC facilities. While its interactive web browser interface addresses simple file transfer and sharing scenarios, large scale automation typically requires integration of the research data management platform it provides into bespoke applications.
We will describe one such example, the Petrel data portal (https://petreldata.net), used by researchers to manage data in diverse fields including materials science, cosmology, machine learning, and serial crystallography. The portal facilitates automated ingest of data, extraction and addition of metadata for creating search indexes, assignment of persistent identifiers faceted search for rapid data discovery, and point-and-click downloading of datasets by authorized users. As security and privacy are often critical requirements, the portal employs fine-grained permissions that control both visibility of metadata and access to the datasets themselves. It is based on the Modern Research Data Portal design pattern, jointly developed by the ESnet and Globus teams, and leverages capabilities such as the Science DMZ for enhanced performance and to streamline the user experience.
Identity for IoT: An Authentication Framework for the IoTAllSeen Alliance
John Bradley, Ping Identity, gave this presentation at the AllSeen Alliance's Partner Programme at Mobile World Congress 2015.
About Ping Identity: Ping Identity provides next-generation identity security solutions. With more than 1,200 enterprise customers worldwide, including half of the Fortune 100, Ping Identity delivers professional-grade identity security solutions that meet the needs of organizations managing workforce, customer, and partner identities. Identity at Internet scale is a concept that will be required as the industry builds services that encompass billions of connected devices and identities.
The Federation for Identity and Cross-Credentialing Systems (FiXs) is a coalition of commercial companies, government contractors, and not-for-profit organizations who have established and maintain a worldwide, interoperable identity and cross-credentialing network built on security, privacy, trust, standard operating rules, policies, and technical standards. Founded and incorporated as a not for profit in 2004 and based in Fairfax, Virginia, FiXs was formed to pilot a federated identity transaction model.
FiXs provides a trusted mechanism for federated identity infrastructure within and between public and private sector organizations with accuracy and trust through the application of a Federated Trust Model. The FiXs network capabilities can be accessed worldwide, in remote or fixed environments, wired or wirelessly, and in real-time.
Modeled after the financial industry’s highly-secure and widely-accepted ATM (Automated Teller Machine) approach, the FiXs network is a secure, scalable system that provides trusted, interoperable identity verification and credential authentication for network users accessing a range of government and commercial facilities. The FiXs network meets federally-mandated requirements, supports physical and logical access applications and integrates with an organization’s existing personnel system, while leveraging the network’s economies of scale.
The Federation includes more than 20 members, including systems integrators, financial institutions, and organizations focused on promoting improved workforce protection and systems security for critical infrastructure. The U.S. Department of Defense (DoD) and the General Services Administration (GSA) are participating government organizations. FiXs members contribute ideas, technologies, and best practices for implementing a secure identity cross-credentialing network based on open standards, sound business processes, and proven technologies and security.
The FiXs network uses available identity credential technology in conjunction with biometric identification. FiXs can be used within and between public and private sector organizations and promotes a trusted mechanism for federated identity infrastructures. It is important to note that FiXs does not grant or deny physical or logical access for any credential bearer. Rather, it delivers a trusted infrastructure that provides participating members with an assured means to authenticate the actual identity of individuals presenting FiXs-certified credentials for access to facilities and systems.
FiXs is an open membership organization. Members join to contribute to and influence the evolution and development of the FiXs network, its capabilities, and certified applications, to learn the latest technologies and strategies for robust identity management programs, and to meet and engage in dialogue with compatible business interests.
Similar to Digital Locker Dedicated Repository Api Specification v1 4 (20)
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDigiLocker
You can get a digital copy of your Aadhaar (eAadhaar issued by UIDAI, Unique Identification Authority of India) directly in your DigiLocker account. All you have to do is to sign up for a DigiLocker account and sync it with Aadhaar - the digital Aadhaar automatically shows up in your issued documents section.
How Educational Institutions Can Provide Digital Mark Sheets To Students Us...DigiLocker
Digital Locker is Govt of India's cloud based platform to issue digital copies of documents & certificates directly to Indian residents (based on Aadhaar) and make these sharable with various agencies. Citizens can also upload their documents online using Digital Locker, digitally sign them using eSign and use the system to electronically submit these documents for various Government services.
With reference to State Education Institutions/ Boards, DigiLocker can be used to push various education certificates and examination mark sheets in digital format. The State Education Board can also facilitate its online users to submit supporting documents from Digital Locker in various online application and admission forms.
Benefits for State Education Institution/ Board:
- Issuing digital marks sheets and certificates
- Forgery proof verification of mark sheets/certificates
Benefit to Students:
- Anytime, anywhere access to mark sheet & certificate
A process server is a authorized person for delivering legal documents, such as summons, complaints, subpoenas, and other court papers, to peoples involved in legal proceedings.
Jennifer Schaus and Associates hosts a complimentary webinar series on The FAR in 2024. Join the webinars on Wednesdays and Fridays at noon, eastern.
Recordings are on YouTube and the company website.
https://www.youtube.com/@jenniferschaus/videos
Jennifer Schaus and Associates hosts a complimentary webinar series on The FAR in 2024. Join the webinars on Wednesdays and Fridays at noon, eastern.
Recordings are on YouTube and the company website.
https://www.youtube.com/@jenniferschaus/videos
ZGB - The Role of Generative AI in Government transformation.pdfSaeed Al Dhaheri
This keynote was presented during the the 7th edition of the UAE Hackathon 2024. It highlights the role of AI and Generative AI in addressing government transformation to achieve zero government bureaucracy
Donate to charity during this holiday seasonSERUDS INDIA
For people who have money and are philanthropic, there are infinite opportunities to gift a needy person or child a Merry Christmas. Even if you are living on a shoestring budget, you will be surprised at how much you can do.
Donate Us
https://serudsindia.org/how-to-donate-to-charity-during-this-holiday-season/
#charityforchildren, #donateforchildren, #donateclothesforchildren, #donatebooksforchildren, #donatetoysforchildren, #sponsorforchildren, #sponsorclothesforchildren, #sponsorbooksforchildren, #sponsortoysforchildren, #seruds, #kurnool
This session provides a comprehensive overview of the latest updates to the Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards (commonly known as the Uniform Guidance) outlined in the 2 CFR 200.
With a focus on the 2024 revisions issued by the Office of Management and Budget (OMB), participants will gain insight into the key changes affecting federal grant recipients. The session will delve into critical regulatory updates, providing attendees with the knowledge and tools necessary to navigate and comply with the evolving landscape of federal grant management.
Learning Objectives:
- Understand the rationale behind the 2024 updates to the Uniform Guidance outlined in 2 CFR 200, and their implications for federal grant recipients.
- Identify the key changes and revisions introduced by the Office of Management and Budget (OMB) in the 2024 edition of 2 CFR 200.
- Gain proficiency in applying the updated regulations to ensure compliance with federal grant requirements and avoid potential audit findings.
- Develop strategies for effectively implementing the new guidelines within the grant management processes of their respective organizations, fostering efficiency and accountability in federal grant administration.
Jennifer Schaus and Associates hosts a complimentary webinar series on The FAR in 2024. Join the webinars on Wednesdays and Fridays at noon, eastern.
Recordings are on YouTube and the company website.
https://www.youtube.com/@jenniferschaus/videos
Russian anarchist and anti-war movement in the third year of full-scale warAntti Rautiainen
Anarchist group ANA Regensburg hosted my online-presentation on 16th of May 2024, in which I discussed tactics of anti-war activism in Russia, and reasons why the anti-war movement has not been able to make an impact to change the course of events yet. Cases of anarchists repressed for anti-war activities are presented, as well as strategies of support for political prisoners, and modest successes in supporting their struggles.
Thumbnail picture is by MediaZona, you may read their report on anti-war arson attacks in Russia here: https://en.zona.media/article/2022/10/13/burn-map
Links:
Autonomous Action
http://Avtonom.org
Anarchist Black Cross Moscow
http://Avtonom.org/abc
Solidarity Zone
https://t.me/solidarity_zone
Memorial
https://memopzk.org/, https://t.me/pzk_memorial
OVD-Info
https://en.ovdinfo.org/antiwar-ovd-info-guide
RosUznik
https://rosuznik.org/
Uznik Online
http://uznikonline.tilda.ws/
Russian Reader
https://therussianreader.com/
ABC Irkutsk
https://abc38.noblogs.org/
Send mail to prisoners from abroad:
http://Prisonmail.online
YouTube: https://youtu.be/c5nSOdU48O8
Spotify: https://podcasters.spotify.com/pod/show/libertarianlifecoach/episodes/Russian-anarchist-and-anti-war-movement-in-the-third-year-of-full-scale-war-e2k8ai4
2. Dedicated Repository API Specification
1
Revision History
Version Date Author Comments
1.2 15/07/2015 Amit Jain (NeGD) New release of Digital Locker. Added
CSV support for uploading URIs.
1.3 30/07/2015 Amit Savant (NeGD) Removed two attributes from Pull
URI API Response - file_name,
Aadhaar name.
1.4 08/08/2015 Amit Savant (NeGD) Specified the date format for CSV
data.
3. Dedicated Repository API Specification
2
Table of Contents
Revision History.......................................................................................................................................................1
Introduction...............................................................................................................................................................3
Digital Locker System Overview .......................................................................................................................3
Key Terminology .....................................................................................................................................................3
On-Boarding Flow...................................................................................................................................................5
Document Codification Scheme.........................................................................................................................5
Unique Document URI ......................................................................................................................................5
Issuer ID (mandatory)......................................................................................................................................6
Document Type (mandatory)........................................................................................................................6
Document ID (mandatory)..............................................................................................................................6
Document Issuance Flow .....................................................................................................................................7
E-Document Specifications..................................................................................................................................7
Document URI......................................................................................................................................................7
Document Owner................................................................................................................................................8
Document Format...............................................................................................................................................8
Issuer Interfaces ......................................................................................................................................................8
PUSH URI to Digital Locker.............................................................................................................................9
Pull URI Request API......................................................................................................................................10
Pull URI Request API elements..............................................................................................................10
Pull URI API Response...............................................................................................................................11
Pull URI API Response elements...........................................................................................................12
Pull Doc Request API......................................................................................................................................13
Pull Doc Request API elements..............................................................................................................13
Pull Doc API Response ..............................................................................................................................13
Pull Doc API Response elements...........................................................................................................14
4. Dedicated Repository API Specification
3
Digital Locker API Specification
Introduction
This document provides detailed specification of the Digital Locker APIs. These APIs will be
used by various issuer departments to push their documents to the Digital Locker
repository. This document assumes that the reader is aware of the Digital Locker
application functionality and has read the Digital Locker Technical Specification (DLTS).
Digital Locker System Overview
The proposed architecture of the Digital Locker system is described in “Digital Locker
Technical Specifications (DLTS)” document. Digital Locker system consists of e-Documents
repositories and access gateways for providing an online mechanism for issuers to store
and requesters to access a Digital Document in a uniform way in real-time.
Key Terminology
1. Electronic Document or E-Document – A digitally signed electronic document in
XML format issued to one or more individuals (Aadhaar holders) in appropriate
format compliant to DLTS specifications. Examples:
• Degree certificate issued to a student by a university.
• Caste certificate issued to an individual by a state government department.
• Marriage certificate issued to two individuals by a state government
department.
5. Dedicated Repository API Specification
4
2. Digital Repository – A software application complying with DLTS specifications,
hosting a collection (database) of e-documents and exposing a standard API for
secure real-time access.
• While architecture does not restrict the number of repository providers, it is
recommended that few highly available and resilient repositories be setup
and encourage everyone to use that instead of having lots of repositories.
3. Digital Locker – A dedicated storage space assigned to each resident, to store
authenticated documents. The digital locker would be accessible via web portal or
mobile application.
4. Issuer – An entity/organization/department issuing e-documents to individuals in
DLTS compliant format and making them electronically available within a repository
of their choice.
5. Requester – An entity/organization/department requesting secure access to a
particular e-document stored within a repository. Examples:
• A university wanting to access 10th standard certificate for admissions
• A government department wanting to access BPL certificate
• Passport department wanting to access marriage certificate
6. Access Gateway – A software application complying with DLTS specifications
providing an online mechanism for requesters to access an e-document in a uniform
way from various repositories in real-time.
• Gateway services can be offered by repository providers themselves.
• While architecture does not restrict the number of repository providers, it is
suggested that few resilient and highly available central gateway systems be
setup and requesters can signup with any one of the gateways for accessing
documents in the Digital repositories.
7. Document URI – A unique document URI mandatory for every document. This
unique URI can be resolved to a full URL to access the actual document in
appropriate repository.
• Document URI is a persistent, location independent, repository independent,
issuer independent representation of the ID of the document.
• The existence of such a URI does not imply availability of the identified
resource, but such URIs are required to remain globally unique and
persistent, even when the resource ceases to exist or becomes unavailable.
• While document URI itself is not a secret, access to the actual document is
secure and authenticated.
6. Dedicated Repository API Specification
5
On-Boarding Flow
Document Codification Scheme
Unique Document URI
Every document that is issued and made accessible via e-Locker system must have a unique
way to resolve to the correct repository without conflict. This is critical to eliminate the
need for all documents reference to be in one system. Federated repositories storing
documents issued by various departments/agencies must be “reachable” via the gateway in
a unique fashion.
Get Issuer ID
Create
Document type
Generate URI
Map URI with
e-Document
Create CSV File
and upload via
issuer login
Create REST
based Pull URI
Request API
Create REST
based Pull Doc
Request API
All documents issued in compliance to DLTS should have the following URI format:
IssuerId-DocType-DocId where
IssuerId is a unique issuer entity ID across the country
DocType is the document type optionally defined by the issuer
DocId is a unique document ID within the issuer system
7. Dedicated Repository API Specification
6
Issuer ID (mandatory)
All departments/agencies within government issuing citizen documents, termed as “Issuers”
must have a unique identification to ensure all documents issued by them are accessible via
DLTS gateway.
Examples of issuer Ids are “maharashtra.gov.in” (Maharashtra State Government),
“kseeb.kar.nic.in” (Karnataka School Board”, “cbse.nic.in” (CBSE School Board), “UDEL”
(Delhi University), etc. These codes MUST BE unique across India and published as part of
standard e-governance codification list.
Document Type (mandatory)
Issuers can freely define a list of document types for their internal classification. For
example, CBSE may classify certificates into “MSTN” (10th mark sheet), “KVPY” (certificate
issued to KVPY scholarship fellows), etc. There are no requirements for publishing these via
any central registry.
Classifying documents into various types allows issuers to choose different repositories for
different types. This is to future proof the design without making assumption that all
certificates issued by the issuer are available in same repository. This also allows migration
from one repository to another in a gradual way. Issuers are free to define their document
types without worrying any collaboration across other issuers. Keeping the length minimal
allows manual entry of document URI without making it too long. Hence it is recommended
to keep length to be only up to 5.
Document ID (mandatory)
A document ID determined by the department/agency (issuer) should be assigned to every
document. It MUST BE unique either within the document types of that issuer or it can be
unique across all document types of that issuer.
It is recommended that issuers define document types either using pure alpha
case-insensitive strings of length up to 5. These document types MUST BE unique
WITHIN the issuer system. This classification within the issuer system also allows
versioning of documents making future documents to be of different formats and in
different repositories without having the need to have all documents in one repository.
If need arises in future to go beyond length 5, maximum length of doc type can
easily use increased without breaking compatibility any existing systems and
documents.
It is recommended that list of unique issuer codes be derived via their domain URL
whenever available and be published as part of e-governance standard codification
scheme with ability to add new issuers on need basis. When URL is not available for a
department, a unique (alpha) code may be assigned.
8. Dedicated Repository API Specification
7
Document Issuance Flow
Document issuance flow is given below:
1. Create a digitally signed e-document complying to DLTS specification with a unique
URI .
a. Issuer entity uses the unique code for itself (obtain a new one if not already
listed) that is available in common DLTS Issuer Codification e-governance
standards. This is a country wide “Unique Issuer ID.
b. Document type codification is done by the Digital Locker system administrator.
Issuers may choose an available document type or if a new type of document is
being issued then request Digital Locker team to create the required document
type.
2. Issuer should create a document repository for storing documents and making it
available online. This could be an existing database or document management
system where the issued documents are stored.
3. Issue the printed document to the individual(s) for whom the document is issued to
with a human readable document URI.
a. Issuer should also offer an option to people to push the document URI to the
digital lockers of the resident for whom the document was issued.
E-Document Specifications
Document URI
All documents issued in compliance to DLTS should have the following URI format:
<IssuerId>[-DocType]-<DocId>
Where,
IssuerId (mandatory) - is a unique issuer entity ID. This is a unique pure alpha
case-insensitive string. To easily make it unique, department’s domain URL can be
used whenever available. The list of issuer Ids must be published and should have a
mechanism to add new ones as required. Unique list of Issuer IDs MUST BE
unique and published via central e-governance codification scheme.
Document ID is an alpha-numeric string with maximum length of 10. It is
recommended that issuers define document IDs either using pure alpha case-
insensitive string using a RANDOM number/string generator. Document IDs MUST
BE unique WITHIN the issuer system within a document type. If need arises in
future to go beyond length 10, maximum length of doc ID can easily use increased
without breaking compatibility any existing systems and documents.
Using random string eliminates the possibility of “guessing” next sequence number and
accessing a list of documents in a sequential way. This is critical to ensure security of
documents and ensures document can be accessed ONLY IF the requester “knows” the
actual document ID (instead of guessing sequential numbers).
It is highly recommended that issuer needing to issue a total of n documents within a
document type use at least 10n random space from which the strings/numbers are
chosen to randomly allocate. Notice that since document types allow further
classification, it is suggested to keep the length minimal. Since issuers can easily add a
new document type without any collaboration and approvals across other issuers, if
more numbers are required, a new document type may be introduced.
9. Dedicated Repository API Specification
8
DocType (mandatory) - is the document type optionally defined by the issuer. This
is highly recommended for document classification and versioning purposes. Issuers
may decide their own classification mechanism. This is a 5 char pure alpha string
which can be expanded in future as needed.
DocId (mandatory) - is a unique document ID of length up to 10 within the issuer
system. It is highly recommended that this is either purely numeric or alpha to avoid
confusion with “0” with “o” etc. Also, it is highly recommended to use random strings
to avoid guessing the sequence of document IDs.
Document Owner
For avoiding document misuse, it is critical that all documents are “attached” to one or more
Aadhaar holders. For example, a caste certificate may be attached to one Aadhaar holder
while a marriage certificate is attached to two Aadhaar holders. Proposed DLTS solution
offers a mechanism for issuers to secure access via Aadhaar authentication of any of the
owners.
Document Format
All e-documents must be represented in PDF or XML format complying to DLTS
specifications. This ensures that a standardized XML structure is used to capture common
attributes of all documents.
Issuer Interfaces
Each issuer organization will have to consume or implement 3 interfaces to fully integrate
with the Digital Locker system. These 3 interfaces are:
1. Push URI to Digital Locker: This web based interface is provided to the issuers by
Digital Locker system to push the URI’s of all the documents available in their
repositories so that the same can be displayed to the residents. This will be a way if
notifying the resident that a particular issuers has following documents linked to the
user’s Aadhaar number.
2. Pull URI Request API: This REST based pull interface has to be implemented by the
issuer organization to allow a resident to query the issuer repository by providing
his/her Aadhaar number or any other identifier applicable to issuer organization
(such as Roll number + Year + Class for CBSE). This way the issuer may provide the
URI’s of all the documents that are linked to the Aadhaar number or other identifiers
provided by the resident.
3. Pull Doc Request API: This REST based pull interface has to be implemented by the
issuer organization to allow a resident to fetch a document from the issuer
repository by providing the URI of the document.
These 3 interfaces are defined in greater details below.
10. Dedicated Repository API Specification
2
Table of Contents
Revision History.......................................................................................................................................................1
Introduction...............................................................................................................................................................3
Digital Locker System Overview .......................................................................................................................3
Key Terminology .....................................................................................................................................................3
On-Boarding Flow...................................................................................................................................................5
Document Codification Scheme.........................................................................................................................5
Unique Document URI ......................................................................................................................................5
Issuer ID (mandatory)......................................................................................................................................6
Document Type (mandatory)........................................................................................................................6
Document ID (mandatory)..............................................................................................................................6
Document Issuance Flow .....................................................................................................................................7
E-Document Specifications..................................................................................................................................7
Document URI......................................................................................................................................................7
Document Owner................................................................................................................................................8
Document Format...............................................................................................................................................8
Issuer Interfaces ......................................................................................................................................................8
PUSH URI to Digital Locker.............................................................................................................................9
Pull URI Request API......................................................................................................................................10
Pull URI Request API elements..............................................................................................................10
Pull URI API Response...............................................................................................................................11
Pull URI API Response elements...........................................................................................................12
Pull Doc Request API......................................................................................................................................13
Pull Doc Request API elements..............................................................................................................13
Pull Doc API Response ..............................................................................................................................13
Pull Doc API Response elements...........................................................................................................14
11. Dedicated Repository API Specification
2
Table of Contents
Revision History.......................................................................................................................................................1
Introduction...............................................................................................................................................................3
Digital Locker System Overview .......................................................................................................................3
Key Terminology .....................................................................................................................................................3
On-Boarding Flow...................................................................................................................................................5
Document Codification Scheme.........................................................................................................................5
Unique Document URI ......................................................................................................................................5
Issuer ID (mandatory)......................................................................................................................................6
Document Type (mandatory)........................................................................................................................6
Document ID (mandatory)..............................................................................................................................6
Document Issuance Flow .....................................................................................................................................7
E-Document Specifications..................................................................................................................................7
Document URI......................................................................................................................................................7
Document Owner................................................................................................................................................8
Document Format...............................................................................................................................................8
Issuer Interfaces ......................................................................................................................................................8
PUSH URI to Digital Locker.............................................................................................................................9
Pull URI Request API......................................................................................................................................10
Pull URI Request API elements..............................................................................................................10
Pull URI API Response...............................................................................................................................11
Pull URI API Response elements...........................................................................................................12
Pull Doc Request API......................................................................................................................................13
Pull Doc Request API elements..............................................................................................................13
Pull Doc API Response ..............................................................................................................................13
Pull Doc API Response elements...........................................................................................................14
12. Dedicated Repository API Specification
11
UDF1 (Optional): User Defined Field
UDF2 (Optional): User Defined Field
UDF3 (Optional): User Defined Field
Pull URI API Response
The response to the PULL URI request will include the URI of any documents linked to the
given Aadhaar number in the request as well as additional meta data of the document. The
issuer will provide the response back to the Digital Locker system synchronously.
The following is the XML response template for the PULL URI Response API.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PullURIResponse xmlns:ns2="http://tempuri.org/">
<ResponseStatus StatusCode="" Status="1" ts=” YYYY-MM-DDThh:mm:ss+/-
nn:nn” txn=""> //1-Success //0-Failure
</ResponseStatus>
<EDocList URICount="2" IssuerCode="">
<Edoc>
<Meta uri="testt.in.gov.kerala.edistrict-A001116301471-420"
doc_type="Main" doc_name="ABCD" app_id="4200"
issueDateTime="05/02/2015" issuedToUID="221723431724">
<Owners>
<Aadhaar uid="221723431724"/>
</Owners>
<UDF1></UDF1> //User Defined Field
<UDF2></UDF2> //User Defined Field
<UDF3></UDF3> //User Defined Field
<Print format="" highResUrl="" lowResUrl=""/>
</Meta>
<Signature/>
</Edoc>
<Edoc>
<Meta uri="testt.in.gov.kerala.edistrict-A001116301471-421"
doc_type="Main" doc_name="ABCD" app_id="4200"
issueDateTime="05/02/2015" issuedToUID="221723431724">
<Owners>
<Aadhaar uid="221723431724"/>
</Owners>
<UDF1></UDF1> //User Defined Field
<UDF2></UDF2> //User Defined Field
<UDF3></UDF3> //User Defined Field
<Print format="" highResUrl="" lowResUrl=""/>
</Meta>
<Signature/>
</Edoc>
</EDocList>
</PullURIResponse>
13. Dedicated Repository API Specification
12
Pull URI API Response elements
ts (mandatory) = timestamp
txn (mandatory): Transaction id (same as the one received in the request)
uri (mandatory): URI identifies the document uniquely. Please refer to the Document
Codification Scheme to create the URI.
doc_type (mandatory): Defined by the Issuers. By default it is “MAIN”. It is for future use,
say in case a Supporting Document Type is added to the repository.
doc_name (mandatory): This is name of the document. This meta data will be used while
displaying the document in the User Digital Locker/ Requestor interface to identify the
document
app_id (mandatory): Unique id of the issuers application which generated the document.
This will be helpful in keeping the audit trail of source of the generated document.
issueDateTime(mandatory): Issued date and Time of the document to the user. Incase of
batch submission of the document to the repository, this can be a past date/time value.
issuedToUID (mandatory): Aadhaar Number of the Issuee.
Aadhaar UID (mandatory): Aadhaar Number of the owner of the document.
Print format (mandatory): Print Format specifies the document format type to be adopted
while printing. At present the value is APPLICATION/PDF only. It will provide the rendering
information to the REQUESTOR.
highResUrl (Optional): This stores the URL of the high resolution document available with
the ISSUER. This can be left blank at present.
lowResUrl (Optional): This stores the URL of the low resolution document available with
the ISSUER. This can be left blank at present.
docBody (Optional): issuer can add meta content specific to doc here. e.g.
<taluka>Borivali</taluka>in this tag.
Signature (Mandatory): The ISSUER has to sign the PUSH request with its Digital
Signature.
UDF1 (Optional): User Defined Field
UDF2 (Optional): User Defined Field
UDF3 (Optional): User Defined Field
14. Dedicated Repository API Specification
13
Pull Doc Request API
The REST based Pull Doc Request API has to be implemented by the issuers and will be
consumed by Digital Locker system. This API will be invoked when the resident clicks on
the URI displayed in the Govt. Issued documents section of the Digital locker portal. At the
time of the click the Digital Locker system will query the issuer repository to fetch the
document linked to the URI being clicked.
The following is the XML request template for the PULL Doc Request API.
The User details will be issued by the issuer to the Digital Locker system. This would consist
of Username and User Key.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PullDocRequest xmlns:ns2="http://tempuri.org/" ver=”1.0” ts=” YYYY-
MM-DDThh:mm:ss+/-nn:nn” txn=”” orgId=”” keyhash="sha256(key+ts)">
<DocDetails txn="">
<URI>testt.in.gov.kerala.edistrict-A001116301471-420</URI>
<UDF1></UDF1> //User Defined Field
<UDF2></UDF2> //User Defined Field
<UDF3></UDF3> //User Defined Field
</DocDetails>
</PullDocRequest>
Pull Doc Request API elements
ts (mandatory) = timestamp
txn (Mandatory) = transaction id
orgId (mandatory): Org Id is the id issued to Digital locker system by the issuer system as
part of allowing access to the Issuer APIs.
keyHash (mandatory): Key hash is SHA-256(API-key+ts). API key is provided to the
Digital Locker system by issuer system to access the issuer APIs.
uri (mandatory): URI identifies the document uniquely
UDF1 (Optional): User Defined Field
UDF2 (Optional): User Defined Field
UDF3 (Optional): User Defined Field
Pull Doc API Response
The response to the PULL Doc request will include the Doc content of any documents linked
to the given URI in the request. The issuer will provide the response back to the Digital
Locker system synchronously.
The following is the XML response template for the PULL Doc Response API.
15. Dedicated Repository API Specification
14
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PullDocResponse xmlns:ns2="http://tempuri.org/">
<ResponseStatus StatusCode="" Status="1" ts=” YYYY-MM-
DDThh:mm:ss+/-nn:nn” txn=""> //1-Success //0-Failure
</ResponseStatus>
<DocDetails>
<docContent>
//Bytes encoded with Base64 in string format
</docContent>
<UDF1></UDF1> //User Defined Field
<UDF2></UDF2> //User Defined Field
<UDF3></UDF3> //User Defined Field
</DocDetails>
</PullDocResponse>
Pull Doc API Response elements
ts (mandatory) = timestamp
txn (mandatory): Transaction id (same as the one received in the request)
statusCode (mandatory): URI identifies the document uniquely. Please refer to the
Document Codification Scheme to create the URI.
status (mandatory): Defined by the Issuers. By default it is “MAIN”. It is for future use, say
in case a Supporting Document Type is added to the repository.
docDetails (Mandatory): issuer can add meta content specific to doc here. e.g.
<taluka>Borivali</taluka>in this tag.
docContent (Mandatory): The ISSUER has to sign the PUSH request with its Digital
Signature.
UDF1 (Optional): User Defined Field
UDF2 (Optional): User Defined Field
UDF3 (Optional): User Defined Field