DigiLocker Consent Fields and Document Permissions

Write the DigiLocker purpose for a person who has just reached the consent screen. Describe the current service and the document it needs. After the redirect, check the permissions actually returned before you retrieve a document.

The v2.4 authorization section describes required purpose and service name fields. It also describes requesting document types from those approved for the client. Check the matching section in the provider contract. Requester v2.4 specification

Review each field with the service owner

Field	Role in the documented flow	Synthetic example
purpose	Explains why the application requests access	Verify driving licence for vehicle pickup
service_name	Identifies the service asking for access	Example Rental Booking
req_doctype	Limits which approved types the request presents	DRVLC
scope	Selects the documented OpenID Connect path when set to openid	openid

The specification restricts the consent strings to letters, digits, spaces, and underscores. Confirm the provider-approved text and capabilities for the application. Keep those values in reviewed configuration.

Check the grant before retrieval

A requested document type expresses intent. The returned permissions express the scope of the actual grant. Keep these in separate fields in your application.

For the NamoID preview, the authorization request uses openid. Its backend checks returned list and exact document permissions before retrieval. The configured requester and approved issuer still determine what can be used.

In a synthetic partial-grant case, a person authorizes sign-in and document listing but does not grant the selected document. Show a recoverable outcome and stop before fetching that document. Apply the approved token cleanup procedure.

Review changes to consent text

1. Write a label that identifies the application.
2. Write a purpose that matches the current task.
3. Confirm the permitted document types.
4. Check the text against the documented character set.
5. Review the rendered screen in the approved environment.
6. Record the consent configuration version used for each test.

Treat a different purpose as a policy change. If a document was requested for handover, check the proper authorization before reusing it for another purpose.

Separate the user messages

Use different messages for denied consent, a missing issued record, and a missing permission. A person can decline and continue with an approved alternative. A support agent can investigate a configuration issue without requesting a raw response.

Keep the consent version and bounded outcome in your diagnostics. Exclude tokens, full document URIs, and document contents. DigiLocker troubleshooting guide.

Review your consent screen with NamoID

NamoID engineers can help review purpose text, allowed document types, and how your application responds to a partial grant. Share a synthetic consent screen and your intended workflow in Slack. Message the NamoID team in Slack