OPENID4VP Same Device Flow Specifications

This document outlines the Same-Device flow (also known as app-app flow) for digital identity verification, following the OPENID4VP (OpenID for Verifiable Presentations) standards.

1.1 Introduction

Specifications describe how aadhaar number holder (ANH) verification is performed and credential exchange is undertaken.

1.2 Abbreviations

Abbreviation	Definition
OPENID4VP	OpenID for Verifiable Presentations
RP	Relying Party (e.g., service provider requesting credentials)
OP	OpenID Provider (issues or verifies credentials)
VC	Verifiable Credential
VP	Verifiable Presentation
ANH	Aadhaar Number Holder (also known as Holder)

1.3 Same-Device Flow

The Same-Device Flow for digital identity verification using the OPENID4VP (OpenID for Verifiable Presentations) standard. The process occurs on a single device, where the Verifier (entity requesting credentials) and the ANH (also referred as the holder) (user presenting credentials via the Aadhaar App) interact to authenticate and share Aadhaar credentials securely.

1.4 Step-by-Step Explanation of the Flow

1.4.1 Initiate Presentation Request:

• The ANH initiates the process by accessing the Verifier's app (e.g., a login page in a mobile app or browser).

• The Verifier App sends a request to the Verifier Backend, specifying the required claims (e.g., name, email, date of birth) for the intent (the purpose of the credential request). The backend is involved in this flow to digitally sign the intent request using a Class II or III Digital certificate.

• The Verifier Backend generates a signed JSON Web Token (JWT) containing the request details (e.g., the fields needed in the Verifiable Presentation).

• The JWT is returned to the Verifier Frontend with the specified Verifier fields.

Request Structure:

The <jwt> is signed with RS256 using the private key, and it contains:

Claim Name	Type	Description	Example Value
iss	String	Issuer of the JWT.	https://www.example.com/
aud	String	Audience of the JWT.	https://www.example.com/
client_id	String	Client identifier.	App identifier
ac	String	Application-specific code.	000 << To be verified>>
sc	String	Scope code.	212121 << To be verified>>
response_type	String	Expected response type.	vp_token
scope	String	Scope of access requested.	openid vp_token
call_back	String	Callback URL for the response.	https://example.com/openid/callback
nonce	String	Unique string from incoming JWT.	123e4567-e89b-12d3-a456-426614174000
txn	String	Transaction ID	987fcdeb-1234-5678-90ab-426614174000
exp	Integer	Expiration time (Unix timestamp, 1 hour from creation).	1740934440
presentation_definition	Object	Defines required credential fields.	See below

1.4.2 Structure of presentation_definition:

{
  "input_descriptors": [
    {
      "id": "aadhaar_credential",
      "constraints": {
        "fields": [
          {
            "path": ["$.credentialSubject.name"],
            "filter": {
              "type": "string",
              "minLength": 1
            }
          },
          {
            "path": ["$.credentialSubject.email"],
            "filter": {
              "type": "string",
              "minLength": 1
            }
          },
          {
            "path": ["$.credentialSubject.dob"],
            "filter": {
              "type": "string",
              "minLength": 1
            }
          },
          {
            "path": ["$.credentialSubject.address"],
            "filter": {
              "type": "string",
              "minLength": 1
            }
          },
          {
            "path": ["$.credentialSubject.mobile"],
            "filter": {
              "type": "string",
              "minLength": 1
            }
          }
        ]
      }
    }
  ]
}

1.4.3 Invoke Aadhaar App

• The Verifier Frontend invokes the Aadhaar App on the same device, passing the JWT as part of the request body. This is using an intent mechanism.

• Parse and Validate JWT:

  • The Aadhaar App parses the intent, extracts the JWT, and validates its signature using JSON Web Key Sets (JWKS) to ensure authenticity.

• Intent Signature Verification:

  • The Aadhaar App sends the intent to the Wallet Backend for signature verification.

  • The Wallet Backend verifies the intent and returns the result (verified).

• Face Authentication:

  • The Aadhaar App prompts the Holder to perform FaceAuth (facial authentication) for verification.

  • The app checks the FaceAuth status, confirming success.

• Match Aadhaar Credentials:

  • The Aadhaar App retrieves the requested Aadhaar credentials (e.g., name, email, dob) from the stored Verifiable Credential (VC).

• Create Verifiable Presentation (VP):

  • The app creates a Verifiable Presentation (VP) containing the requested Aadhaar credentials.

  • The VP is encapsulated in a Signed Data JWT (SD-JWT) and signed with the Holder's private key to ensure authenticity. This is an optional step.

• Submit VP to Verifier:

  • Aadhaar App submits the response to the Verifier app containing the credential.

  • If the Intent specs mention a callback url, the Aadhaar App sends a POST request to the Verifier's intent callback endpoint, containing the VP, a token, and state.

  • The Verifier Backend validates the VP by verifying the signatures, checking the nonce and state to prevent replay attacks, and ensuring the credentials meet the request requirements. This is a non-normative step.

Store Transaction Data:

• The Verifier Backend extracts the user data (e.g., name, email, date of birth) from the VP, encrypts it, and stores it in a transaction log for auditing purposes. This is a non-normative step.

• Please refer to the Aadhar Act and Regulations for the handling of the PII data.

1.4.4 Response Format

Wherever a callback URL is involved, the URL is expected to provide a response containing HTTP code for successful or any error conditions.

Content-Type: application/json
Success Response (HTTP Status: 200 OK)
{
  "txnID": "<transaction_id>",
  "responseCode": "200",
  "responseMsg": "Success"
}

• The Verifier Backend validates the VP by verifying the signatures, checking the nonce and state to prevent replay attacks, and ensuring the credentials meet the presentation definition.

• Notify Success:

• The Verifier Backend returns a response to the Verifier Frontend with a transaction ID (txnId), responseCode: 200, and responseMsg: "Success". This is a non-normative step. Grant Access:

• The Verifier Frontend notifies the Verifier User of successful verification, granting access to the requested service. This is a non-normative step.