Government of Andhra Pradesh / MobileSigner eFile platform
Introduction

Introduction

Overview

What the MobileSigner eFile platform is, who it is for, and what is actually implemented.

MobileSigner is an eFile approval workstation for Government of Andhra Pradesh officers. It replaces the USB-token-and-desktop-browser dependency in the departmental approval chain with a FIDO2 security key that works on any device, including a phone.

This documentation describes the system as built, and is explicit about the boundary between what is cryptographically real and what is presentation.

The problem it addresses

An officer approving a G.O. in an eOffice-style workflow today needs a Class-3 DSC on a USB crypto token, a Windows desktop, a Java-based middleware host and a browser that still tolerates it. The practical consequences:

  • Approvals stall whenever the officer is away from the one machine that has the middleware installed.
  • The token is physically handed to staff to keep files moving, which destroys the non-repudiation the token exists to provide.
  • Mobile approval is impossible, so MOST_IMMEDIATE files wait for the officer to return to a desk.

MobileSigner keeps the hardware-bound private key requirement — that is the part with legal weight — and removes the desktop, the middleware and the driver stack. The key is a FIDO2 authenticator; the ceremony is browser-native WebAuthn; the platform is anything with a modern browser.

What is in the repositories

Repository Stack Role
mobilesigner-webauthn-backend-demo Quarkus 3.38.1, Java 17, Hibernate ORM with Panache, PostgreSQL WebAuthn relying party, eFile domain model, audit ledger, verification service
mobilesigner-webauthn-next-demo Next.js 16.3.0, React 19.2.8, TypeScript 5.9.3 Officer workstation UI, plus the @mobilesigner/web-sdk npm workspace package
mobilesigner-docs Quarkus 3.38.1, Qute, commonmark This documentation site

The SDK is a real workspace package (packages/web-sdk), built by npm run sdk:build before every dev and build, and consumed by the workstation as @mobilesigner/web-sdk. It is not a copy-pasted snippet.

The platform at a glance

Eight routes make up the workstation. Click through to the reference for any of them.

graph LR
  subgraph WS["Workspace"]
    Dash["/<br/><small>Dashboard</small>"]
    Inbox["/files<br/><small>File inbox</small>"]
    Detail["/files/[id]<br/><small>File detail</small>"]
  end
  subgraph CO["Compliance"]
    Verify["/verify<br/><small>Verify signature</small>"]
    Audit["/audit<br/><small>Audit trail</small>"]
  end
  subgraph AD["Administration"]
    Devices["/devices<br/><small>Signing devices</small>"]
  end
  subgraph RE["Resources"]
    Dev["/developer<br/><small>SDK reference</small>"]
    About["/about<br/><small>Programme context</small>"]
  end

  Dash --> Inbox --> Detail
  Detail -- "signs, then deep-links" --> Verify
  Detail -- "records" --> Audit

  click Dash "/workstation" "Workstation UI reference"
  click Inbox "/workstation" "Workstation UI reference"
  click Detail "/workstation" "Workstation UI reference"
  click Verify "/backend-api" "Backend API reference"
  click Audit "/backend-api" "Backend API reference"
  click Devices "/data-model" "Data model reference"
  click Dev "/web-sdk" "Web SDK reference"

  classDef hot fill:#e4f4ec,stroke:#0d6b4f,color:#18221d
  class Detail hot

The centrepiece is /files/[id]. It reproduces the structure a Section Officer would recognise from NIC eOffice: the document of record on one side, the noting sheet as a threaded series of numbered notes underneath, and the action rail on the right. Notes carry the eOffice colour convention — GREEN for a permanent signed note, YELLOW for a draft — surfaced in the UI as "Permanent note" and "Draft note".

The approval ceremony

Approving a file is not a button that flips a status column. The sequence is:

  1. The officer enrols a FIDO2 key once, through the Quarkus WebAuthn registration endpoint. One credential per officer is enforced in DemoWebAuthnUserProvider.store().
  2. Authenticating runs a real WebAuthn assertion. The resulting identity lives in an encrypted session cookie.
  3. On Approve, the browser computes the SHA-256 digest of the document body with crypto.subtle.digest inside the SDK, then posts {action, note, documentHash} to POST /api/files/{id}/action.
  4. The backend rejects the call outright if the identity is anonymous (401) or the digest is not 64 hex characters (400). A hash is mandatory to approve; a note is mandatory to reject or return.
  5. On success it appends a numbered GREEN note carrying signatureHash and signedAt, writes an Approval row, and records a FILE_APPROVED audit event.

That digest is what /verify later resolves. The chain from "officer touched a key" to "this digest is on record" is genuine. Architecture has the full ceremony sequences.

Three actions, not one

Real files do not only get approved. The action rail offers:

graph TB
  Pending{{"File status<br/>PENDING"}}
  Pending -->|"Approve & Sign<br/><small>requires SHA-256 digest</small>"| Approved["APPROVED<br/><small>GREEN note + signature</small>"]
  Pending -->|"Reject<br/><small>requires a note</small>"| Rejected["REJECTED<br/><small>GREEN note</small>"]
  Pending -->|"Return for clarification<br/><small>requires a note</small>"| Returned["RETURNED<br/><small>YELLOW draft note</small>"]

  classDef ok fill:#e4f4ec,stroke:#0d6b4f,color:#18221d
  classDef bad fill:#fdeaea,stroke:#8b2020,color:#18221d
  classDef back fill:#e8f0f9,stroke:#1d4e89,color:#18221d
  class Approved ok
  class Rejected bad
  class Returned back

Rejection produces a permanent GREEN note because a rejection is a decision of record. A return produces a YELLOW draft note, because the file is going back down the chain rather than being disposed of.

What is real and what is staged

Being precise about this matters more than the demo looking impressive.

Real: the WebAuthn registration and assertion ceremonies, the credential store including signature-counter updates, the encrypted session cookie, SHA-256 digest computation in the browser, digest-to-approval binding, and the audit ledger append path.

Staged: the X.509 material. VerifyResource does not parse a PKCS#7 blob or contact an OCSP responder. It looks up the digest in the Approval table and, if found, emits six PASS steps with realistic issuer, TSA and key-usage strings derived from the hash. The Security model page sets out exactly where the boundary is and what would have to be built to cross it.

Documentation map