SlideShare a Scribd company logo
Dedicated Repository API Specification
Version 1.4
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.
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
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.
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.
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
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.
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.
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.
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
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
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>
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
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.
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

More Related Content

What's hot

Convergent Invoicing: Clarification Lists
Convergent Invoicing: Clarification Lists Convergent Invoicing: Clarification Lists
Convergent Invoicing: Clarification Lists
Rakesh Dasgupta
 
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four WayOracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
Boopathy CS
 
SAP-Customer Specific Product Reservation
SAP-Customer Specific Product ReservationSAP-Customer Specific Product Reservation
SAP-Customer Specific Product Reservation
Vijay Pisipaty
 
Infopedia Report
Infopedia ReportInfopedia Report
Infopedia Report
bikramagarwal
 
Gas agency management system for nepal gas anil
Gas agency management system for nepal gas anilGas agency management system for nepal gas anil
Gas agency management system for nepal gas anil
Nawaraj Ghimire
 
Oracle R12 AR Enhancement Overview
Oracle R12 AR Enhancement OverviewOracle R12 AR Enhancement Overview
Oracle R12 AR Enhancement Overview
Sanjay Challagundla
 
Customizing Oracle EBS OA Framework
Customizing Oracle EBS OA FrameworkCustomizing Oracle EBS OA Framework
Customizing Oracle EBS OA Framework
iWare Logic Technologies Pvt. Ltd.
 
HDFC banking system SRS Document
HDFC banking system  SRS DocumentHDFC banking system  SRS Document
HDFC banking system SRS Document
NavjeetKajal
 
Functional specification documents of
Functional specification documents ofFunctional specification documents of
Functional specification documents of
rtu
 
Salesforce Integration Pattern Overview
Salesforce Integration Pattern OverviewSalesforce Integration Pattern Overview
Salesforce Integration Pattern Overview
Dhanik Sahni
 
Fico bbp final
Fico bbp final Fico bbp final
Fico bbp final
poonam_sri
 
OpenID for SSI
OpenID for SSIOpenID for SSI
OpenID for SSI
Torsten Lodderstedt
 
Sap sd-user-manual
Sap sd-user-manualSap sd-user-manual
Sap sd-user-manual
amruta kumar
 
NHS SSC Fusion_GL_UAT_Test Script v2.0
NHS SSC Fusion_GL_UAT_Test Script v2.0NHS SSC Fusion_GL_UAT_Test Script v2.0
NHS SSC Fusion_GL_UAT_Test Script v2.0
Khalil Rehman NLP (MPrac) MCIPS, PMP,OCP
 
Oaf personaliztion examples
Oaf personaliztion examplesOaf personaliztion examples
Oaf personaliztion examples
Kaushik Kumar Kuberanathan
 
Project final report
Project final reportProject final report
Project final report
ALIN BABU
 
Keycloak Single Sign-On
Keycloak Single Sign-OnKeycloak Single Sign-On
Keycloak Single Sign-On
Ravi Yasas
 
Webinar: Mass Additions – R12 Asset Management
Webinar: Mass Additions – R12 Asset ManagementWebinar: Mass Additions – R12 Asset Management
Webinar: Mass Additions – R12 Asset Management
iWare Logic Technologies Pvt. Ltd.
 
Software Design Document
Software Design DocumentSoftware Design Document
Software Design Document
Mugerwa Brian Mark
 
Inventory Management System
Inventory Management SystemInventory Management System
Inventory Management System
Emmanuel college
 

What's hot (20)

Convergent Invoicing: Clarification Lists
Convergent Invoicing: Clarification Lists Convergent Invoicing: Clarification Lists
Convergent Invoicing: Clarification Lists
 
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four WayOracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
Oracle Purchasing – Invoice Matching Methods - Two, Three, and Four Way
 
SAP-Customer Specific Product Reservation
SAP-Customer Specific Product ReservationSAP-Customer Specific Product Reservation
SAP-Customer Specific Product Reservation
 
Infopedia Report
Infopedia ReportInfopedia Report
Infopedia Report
 
Gas agency management system for nepal gas anil
Gas agency management system for nepal gas anilGas agency management system for nepal gas anil
Gas agency management system for nepal gas anil
 
Oracle R12 AR Enhancement Overview
Oracle R12 AR Enhancement OverviewOracle R12 AR Enhancement Overview
Oracle R12 AR Enhancement Overview
 
Customizing Oracle EBS OA Framework
Customizing Oracle EBS OA FrameworkCustomizing Oracle EBS OA Framework
Customizing Oracle EBS OA Framework
 
HDFC banking system SRS Document
HDFC banking system  SRS DocumentHDFC banking system  SRS Document
HDFC banking system SRS Document
 
Functional specification documents of
Functional specification documents ofFunctional specification documents of
Functional specification documents of
 
Salesforce Integration Pattern Overview
Salesforce Integration Pattern OverviewSalesforce Integration Pattern Overview
Salesforce Integration Pattern Overview
 
Fico bbp final
Fico bbp final Fico bbp final
Fico bbp final
 
OpenID for SSI
OpenID for SSIOpenID for SSI
OpenID for SSI
 
Sap sd-user-manual
Sap sd-user-manualSap sd-user-manual
Sap sd-user-manual
 
NHS SSC Fusion_GL_UAT_Test Script v2.0
NHS SSC Fusion_GL_UAT_Test Script v2.0NHS SSC Fusion_GL_UAT_Test Script v2.0
NHS SSC Fusion_GL_UAT_Test Script v2.0
 
Oaf personaliztion examples
Oaf personaliztion examplesOaf personaliztion examples
Oaf personaliztion examples
 
Project final report
Project final reportProject final report
Project final report
 
Keycloak Single Sign-On
Keycloak Single Sign-OnKeycloak Single Sign-On
Keycloak Single Sign-On
 
Webinar: Mass Additions – R12 Asset Management
Webinar: Mass Additions – R12 Asset ManagementWebinar: Mass Additions – R12 Asset Management
Webinar: Mass Additions – R12 Asset Management
 
Software Design Document
Software Design DocumentSoftware Design Document
Software Design Document
 
Inventory Management System
Inventory Management SystemInventory Management System
Inventory Management System
 

Similar to Digital Locker Dedicated Repository Api Specification v1 4

Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptxDigital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
AnkitKumar519788
 
OpenID Connect 4 SSI (at EIC 2021)
OpenID Connect 4 SSI (at EIC 2021)OpenID Connect 4 SSI (at EIC 2021)
OpenID Connect 4 SSI (at EIC 2021)
Torsten Lodderstedt
 
OpenID for Verifiable Credentials
OpenID for Verifiable CredentialsOpenID for Verifiable Credentials
OpenID for Verifiable Credentials
Torsten Lodderstedt
 
OpenID for Verifiable Credentials @ IIW 36
OpenID for Verifiable Credentials @ IIW 36OpenID for Verifiable Credentials @ IIW 36
OpenID for Verifiable Credentials @ IIW 36
Torsten Lodderstedt
 
Simple Web service Offering Repository Deposit (SWORD)‏
Simple Web service Offering Repository Deposit (SWORD)‏Simple Web service Offering Repository Deposit (SWORD)‏
Simple Web service Offering Repository Deposit (SWORD)‏
Julie Allinson
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
Torsten Lodderstedt
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
Torsten Lodderstedt
 
Authorization Policy in a PKI Environment Mary Thompson Srilekha Mudumbai A...
 Authorization Policy in a PKI Environment  Mary Thompson Srilekha Mudumbai A... Authorization Policy in a PKI Environment  Mary Thompson Srilekha Mudumbai A...
Authorization Policy in a PKI Environment Mary Thompson Srilekha Mudumbai A...
Information Security Awareness Group
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
Torsten Lodderstedt
 
Null talk
Null talkNull talk
Null talk
Agam Jain
 
Enterprise & Web based Federated Identity Management & Data Access Controls
Enterprise & Web based Federated Identity Management & Data Access Controls Enterprise & Web based Federated Identity Management & Data Access Controls
Enterprise & Web based Federated Identity Management & Data Access Controls
Kingsley Uyi Idehen
 
OpenID for Verifiable Credentials
OpenID for Verifiable CredentialsOpenID for Verifiable Credentials
OpenID for Verifiable Credentials
Torsten Lodderstedt
 
OpenID Connect 4 SSI (DIFCon F2F)
OpenID Connect 4 SSI (DIFCon F2F)OpenID Connect 4 SSI (DIFCon F2F)
OpenID Connect 4 SSI (DIFCon F2F)
Torsten Lodderstedt
 
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
Globus
 
Scalable Data Management: Automation and the Modern Research Data Portal
Scalable Data Management: Automation and the Modern Research Data PortalScalable Data Management: Automation and the Modern Research Data Portal
Scalable Data Management: Automation and the Modern Research Data Portal
Globus
 
CNI 2018: A Research Object Authoring Tool for the Data Commons
CNI 2018: A Research Object Authoring Tool for the Data CommonsCNI 2018: A Research Object Authoring Tool for the Data Commons
CNI 2018: A Research Object Authoring Tool for the Data Commons
Anita de Waard
 
IBM Spectrum Scale Authentication for Protocols
IBM Spectrum Scale Authentication for ProtocolsIBM Spectrum Scale Authentication for Protocols
IBM Spectrum Scale Authentication for Protocols
Sandeep Patil
 
Identity for IoT: An Authentication Framework for the IoT
Identity for IoT: An Authentication Framework for the IoTIdentity for IoT: An Authentication Framework for the IoT
Identity for IoT: An Authentication Framework for the IoT
AllSeen Alliance
 
Issa fi xs briefing
Issa fi xs briefingIssa fi xs briefing
FIWARE Identity Management and Access Control
FIWARE Identity Management and Access ControlFIWARE Identity Management and Access Control
FIWARE Identity Management and Access Control
FIWARE
 

Similar to Digital Locker Dedicated Repository Api Specification v1 4 (20)

Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptxDigital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
Digital Locker System (DigiLocker) - A Government of India Initiative_1.pptx
 
OpenID Connect 4 SSI (at EIC 2021)
OpenID Connect 4 SSI (at EIC 2021)OpenID Connect 4 SSI (at EIC 2021)
OpenID Connect 4 SSI (at EIC 2021)
 
OpenID for Verifiable Credentials
OpenID for Verifiable CredentialsOpenID for Verifiable Credentials
OpenID for Verifiable Credentials
 
OpenID for Verifiable Credentials @ IIW 36
OpenID for Verifiable Credentials @ IIW 36OpenID for Verifiable Credentials @ IIW 36
OpenID for Verifiable Credentials @ IIW 36
 
Simple Web service Offering Repository Deposit (SWORD)‏
Simple Web service Offering Repository Deposit (SWORD)‏Simple Web service Offering Repository Deposit (SWORD)‏
Simple Web service Offering Repository Deposit (SWORD)‏
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
 
Authorization Policy in a PKI Environment Mary Thompson Srilekha Mudumbai A...
 Authorization Policy in a PKI Environment  Mary Thompson Srilekha Mudumbai A... Authorization Policy in a PKI Environment  Mary Thompson Srilekha Mudumbai A...
Authorization Policy in a PKI Environment Mary Thompson Srilekha Mudumbai A...
 
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
How to Build Interoperable Decentralized Identity Systems with OpenID for Ver...
 
Null talk
Null talkNull talk
Null talk
 
Enterprise & Web based Federated Identity Management & Data Access Controls
Enterprise & Web based Federated Identity Management & Data Access Controls Enterprise & Web based Federated Identity Management & Data Access Controls
Enterprise & Web based Federated Identity Management & Data Access Controls
 
OpenID for Verifiable Credentials
OpenID for Verifiable CredentialsOpenID for Verifiable Credentials
OpenID for Verifiable Credentials
 
OpenID Connect 4 SSI (DIFCon F2F)
OpenID Connect 4 SSI (DIFCon F2F)OpenID Connect 4 SSI (DIFCon F2F)
OpenID Connect 4 SSI (DIFCon F2F)
 
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
Facilitating Collaboration with Globus (GlobusWorld Tour - STFC)
 
Scalable Data Management: Automation and the Modern Research Data Portal
Scalable Data Management: Automation and the Modern Research Data PortalScalable Data Management: Automation and the Modern Research Data Portal
Scalable Data Management: Automation and the Modern Research Data Portal
 
CNI 2018: A Research Object Authoring Tool for the Data Commons
CNI 2018: A Research Object Authoring Tool for the Data CommonsCNI 2018: A Research Object Authoring Tool for the Data Commons
CNI 2018: A Research Object Authoring Tool for the Data Commons
 
IBM Spectrum Scale Authentication for Protocols
IBM Spectrum Scale Authentication for ProtocolsIBM Spectrum Scale Authentication for Protocols
IBM Spectrum Scale Authentication for Protocols
 
Identity for IoT: An Authentication Framework for the IoT
Identity for IoT: An Authentication Framework for the IoTIdentity for IoT: An Authentication Framework for the IoT
Identity for IoT: An Authentication Framework for the IoT
 
Issa fi xs briefing
Issa fi xs briefingIssa fi xs briefing
Issa fi xs briefing
 
FIWARE Identity Management and Access Control
FIWARE Identity Management and Access ControlFIWARE Identity Management and Access Control
FIWARE Identity Management and Access Control
 

More from DigiLocker

How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
How ICSE or ISC Students can get their Digital Marksheets from DigiLocker How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
DigiLocker
 
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDemo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
DigiLocker
 
How Users Can Get their Digital Driving License & Vehicle Registration from D...
How Users Can Get their Digital Driving License & Vehicle Registration from D...How Users Can Get their Digital Driving License & Vehicle Registration from D...
How Users Can Get their Digital Driving License & Vehicle Registration from D...
DigiLocker
 
Transport
TransportTransport
Transport
DigiLocker
 
How Educational Institutions Can Provide Digital Mark Sheets To Students Us...
How Educational Institutions Can  Provide Digital Mark Sheets To Students  Us...How Educational Institutions Can  Provide Digital Mark Sheets To Students  Us...
How Educational Institutions Can Provide Digital Mark Sheets To Students Us...
DigiLocker
 
How CBSE Students can get their Digital Marksheets from DigiLocker
How CBSE Students can get their Digital Marksheets from DigiLocker How CBSE Students can get their Digital Marksheets from DigiLocker
How CBSE Students can get their Digital Marksheets from DigiLocker
DigiLocker
 
Technical Specifications DLTS ver 2.3
Technical Specifications DLTS ver 2.3Technical Specifications DLTS ver 2.3
Technical Specifications DLTS ver 2.3
DigiLocker
 
eSign Brochure1.5
eSign Brochure1.5eSign Brochure1.5
eSign Brochure1.5
DigiLocker
 
Digital Locker User Manual
Digital Locker User ManualDigital Locker User Manual
Digital Locker User Manual
DigiLocker
 
Digital Locker Intro
Digital Locker Intro Digital Locker Intro
Digital Locker Intro
DigiLocker
 
Bulk and Run Time Digital Signing v1.0
Bulk and Run Time Digital Signing v1.0Bulk and Run Time Digital Signing v1.0
Bulk and Run Time Digital Signing v1.0
DigiLocker
 

More from DigiLocker (11)

How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
How ICSE or ISC Students can get their Digital Marksheets from DigiLocker How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
How ICSE or ISC Students can get their Digital Marksheets from DigiLocker
 
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDemo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
 
How Users Can Get their Digital Driving License & Vehicle Registration from D...
How Users Can Get their Digital Driving License & Vehicle Registration from D...How Users Can Get their Digital Driving License & Vehicle Registration from D...
How Users Can Get their Digital Driving License & Vehicle Registration from D...
 
Transport
TransportTransport
Transport
 
How Educational Institutions Can Provide Digital Mark Sheets To Students Us...
How Educational Institutions Can  Provide Digital Mark Sheets To Students  Us...How Educational Institutions Can  Provide Digital Mark Sheets To Students  Us...
How Educational Institutions Can Provide Digital Mark Sheets To Students Us...
 
How CBSE Students can get their Digital Marksheets from DigiLocker
How CBSE Students can get their Digital Marksheets from DigiLocker How CBSE Students can get their Digital Marksheets from DigiLocker
How CBSE Students can get their Digital Marksheets from DigiLocker
 
Technical Specifications DLTS ver 2.3
Technical Specifications DLTS ver 2.3Technical Specifications DLTS ver 2.3
Technical Specifications DLTS ver 2.3
 
eSign Brochure1.5
eSign Brochure1.5eSign Brochure1.5
eSign Brochure1.5
 
Digital Locker User Manual
Digital Locker User ManualDigital Locker User Manual
Digital Locker User Manual
 
Digital Locker Intro
Digital Locker Intro Digital Locker Intro
Digital Locker Intro
 
Bulk and Run Time Digital Signing v1.0
Bulk and Run Time Digital Signing v1.0Bulk and Run Time Digital Signing v1.0
Bulk and Run Time Digital Signing v1.0
 

Recently uploaded

快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
3woawyyl
 
2024: The FAR - Federal Acquisition Regulations, Part 42
2024: The FAR - Federal Acquisition Regulations, Part 422024: The FAR - Federal Acquisition Regulations, Part 42
2024: The FAR - Federal Acquisition Regulations, Part 42
JSchaus & Associates
 
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
9d5c8i83
 
加急办理华威大学毕业证硕士文凭证书原版一模一样
加急办理华威大学毕业证硕士文凭证书原版一模一样加急办理华威大学毕业证硕士文凭证书原版一模一样
加急办理华威大学毕业证硕士文凭证书原版一模一样
uu1psyf6
 
2024: The FAR - Federal Acquisition Regulations, Part 41
2024: The FAR - Federal Acquisition Regulations, Part 412024: The FAR - Federal Acquisition Regulations, Part 41
2024: The FAR - Federal Acquisition Regulations, Part 41
JSchaus & Associates
 
China Politics social economic political
China Politics social economic politicalChina Politics social economic political
China Politics social economic political
ajatjamwal123
 
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
3woawyyl
 
G7 Apulia Leaders Communique, 14th June 2024
G7 Apulia Leaders Communique, 14th June 2024G7 Apulia Leaders Communique, 14th June 2024
G7 Apulia Leaders Communique, 14th June 2024
Energy for One World
 
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
ii2sh2v
 
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
yemqpj
 
AHMR volume 10 number 1 January-April 2024
AHMR volume 10 number 1 January-April 2024AHMR volume 10 number 1 January-April 2024
AHMR volume 10 number 1 January-April 2024
Scalabrini Institute for Human Mobility in Africa
 
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
ahcitycouncil
 
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
odmqk
 
Antyodaya saral portal haryana govt schemes
Antyodaya saral portal haryana govt schemesAntyodaya saral portal haryana govt schemes
Antyodaya saral portal haryana govt schemes
narinav14
 
Awaken new depths - World Ocean Day 2024, June 8th.
Awaken new depths - World Ocean Day 2024, June 8th.Awaken new depths - World Ocean Day 2024, June 8th.
Awaken new depths - World Ocean Day 2024, June 8th.
Christina Parmionova
 
Bharat Mata - History of Indian culture.pdf
Bharat Mata - History of Indian culture.pdfBharat Mata - History of Indian culture.pdf
Bharat Mata - History of Indian culture.pdf
Bharat Mata
 
Researching the client.pptxsxssssssssssssssssssssss
Researching the client.pptxsxssssssssssssssssssssssResearching the client.pptxsxssssssssssssssssssssss
Researching the client.pptxsxssssssssssssssssssssss
DanielOliver74
 
PPT Item # 8&9 - Demolition Code Amendments
PPT Item # 8&9 - Demolition Code AmendmentsPPT Item # 8&9 - Demolition Code Amendments
PPT Item # 8&9 - Demolition Code Amendments
ahcitycouncil
 
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
Christina Parmionova
 
Contributi dei parlamentari del PD - Contributi L. 3/2019
Contributi dei parlamentari del PD - Contributi L. 3/2019Contributi dei parlamentari del PD - Contributi L. 3/2019
Contributi dei parlamentari del PD - Contributi L. 3/2019
Partito democratico
 

Recently uploaded (20)

快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
快速办理(Bristol毕业证书)布里斯托大学毕业证Offer一模一样
 
2024: The FAR - Federal Acquisition Regulations, Part 42
2024: The FAR - Federal Acquisition Regulations, Part 422024: The FAR - Federal Acquisition Regulations, Part 42
2024: The FAR - Federal Acquisition Regulations, Part 42
 
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
在线办理美国乔治华盛顿大学毕业证(gwu毕业证书)学历学位证书原版一模一样
 
加急办理华威大学毕业证硕士文凭证书原版一模一样
加急办理华威大学毕业证硕士文凭证书原版一模一样加急办理华威大学毕业证硕士文凭证书原版一模一样
加急办理华威大学毕业证硕士文凭证书原版一模一样
 
2024: The FAR - Federal Acquisition Regulations, Part 41
2024: The FAR - Federal Acquisition Regulations, Part 412024: The FAR - Federal Acquisition Regulations, Part 41
2024: The FAR - Federal Acquisition Regulations, Part 41
 
China Politics social economic political
China Politics social economic politicalChina Politics social economic political
China Politics social economic political
 
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
原版制作(英国Southampton毕业证书)南安普顿大学毕业证录取通知书一模一样
 
G7 Apulia Leaders Communique, 14th June 2024
G7 Apulia Leaders Communique, 14th June 2024G7 Apulia Leaders Communique, 14th June 2024
G7 Apulia Leaders Communique, 14th June 2024
 
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
原版制作(Hope毕业证书)利物浦霍普大学毕业证文凭证书一模一样
 
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
快速办理(UVM毕业证书)佛蒙特大学毕业证学位证一模一样
 
AHMR volume 10 number 1 January-April 2024
AHMR volume 10 number 1 January-April 2024AHMR volume 10 number 1 January-April 2024
AHMR volume 10 number 1 January-April 2024
 
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
PPT Item # 5 - 318 Tuxedo Ave. (sign. review)
 
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
一比一原版(theauckland毕业证书)新西兰奥克兰大学毕业证成绩单如何办理
 
Antyodaya saral portal haryana govt schemes
Antyodaya saral portal haryana govt schemesAntyodaya saral portal haryana govt schemes
Antyodaya saral portal haryana govt schemes
 
Awaken new depths - World Ocean Day 2024, June 8th.
Awaken new depths - World Ocean Day 2024, June 8th.Awaken new depths - World Ocean Day 2024, June 8th.
Awaken new depths - World Ocean Day 2024, June 8th.
 
Bharat Mata - History of Indian culture.pdf
Bharat Mata - History of Indian culture.pdfBharat Mata - History of Indian culture.pdf
Bharat Mata - History of Indian culture.pdf
 
Researching the client.pptxsxssssssssssssssssssssss
Researching the client.pptxsxssssssssssssssssssssssResearching the client.pptxsxssssssssssssssssssssss
Researching the client.pptxsxssssssssssssssssssssss
 
PPT Item # 8&9 - Demolition Code Amendments
PPT Item # 8&9 - Demolition Code AmendmentsPPT Item # 8&9 - Demolition Code Amendments
PPT Item # 8&9 - Demolition Code Amendments
 
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
United Nations World Oceans Day 2024; June 8th " Awaken new dephts".
 
Contributi dei parlamentari del PD - Contributi L. 3/2019
Contributi dei parlamentari del PD - Contributi L. 3/2019Contributi dei parlamentari del PD - Contributi L. 3/2019
Contributi dei parlamentari del PD - Contributi L. 3/2019
 

Digital Locker Dedicated Repository Api Specification v1 4

  • 1. Dedicated Repository API Specification Version 1.4
  • 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