VaultESign

VaultESign manages the complete electronic signature lifecycle for VaultPDF-generated documents. It operates independently of third-party e-signature platforms.

Your document rendering, signing, and audit storage occur entirely in your Azure subscription via the Vault Dispatcher and Processor. Signers interact with a stateless signing portal hosted on Vault Shared Services by Refract Logic. Signer invitations are routed through Azure Communication Services under standard Data Processing Agreements. All signature evidence is stored as immutable audit records in your tenant, designed to meet the technical requirements for admissibility as electronic evidence under e-signature laws in most jurisdictions.

Key Difference from Traditional eSign: Unlike platforms that store your documents on external servers, Vault keeps document content in your infrastructure from rendering through final sealing.

How It Works

1. A document is rendered by your Vault Dispatcher (direct on-demand render) or Vault Processor (workflow seal, batch distribution). The resulting PDF is stored in your Azure Blob Storage.

2. An initiator (SPFx command set or API caller) creates a signing session via POST /api/esign/session (calls your customer-hosted Dispatcher).

3. Your Dispatcher communicates with Vault Shared Services by Refract Logic to generate per-signer invitation emails with unique portal links and security tokens.

4. Each signer visits their portal link (hosted on Vault Shared Services), optionally verifies via OTP, reviews the document, completes any manifest fields (initials, date, text, checkboxes), and applies their signature.

5. The signer's completed submission is posted as a callback to your Dispatcher (POST /api/esign/callback). The Dispatcher validates the HMAC signature, updates slot state, and enqueues a seal message to your Azure Service Bus. Your Processor picks up the seal message for cryptographic sealing and evidence certificate generation.

6. The completed signed PDF and evidence certificate are stored in your Azure Blob Storage and (optionally) written back to SharePoint.

Infrastructure Locations

Signing Modes

Session Expiry

Sessions expire when the expiresInMinutes TTL elapses before all required slots are signed.

What happens when a session expires:

• The session state transitions to expired.
• Any portal links held by signers return 410 Gone — the document is inaccessible.
• All signing progress from the expired session is lost. Partially-signed sessions do not carry forward individual slot completions.

There is no extend or revive endpoint. To recover from an expired session, create a new session via POST /api/esign/session. All signers — including those who had already signed — must sign again in the new session.

POST /api/esign/session/{correlationId}/resend-invite does not rescue expired sessions. It only resends the invitation email for slots already in activated, viewed, or otp_verified state within a live session.

Session States

Slot States (Per Signer)

OTP Verification

Each signing slot can be configured to require a one-time passcode before the signer can access the document. OTP delivery channels:

Consent Model

Before applying their signature, each signer confirms three consent statements:

1. Document reviewed: the signer confirms they have read and understood the document.
2. Electronic consent: the signer consents to signing electronically in lieu of a handwritten signature.
3. Binding acknowledgement: the signer acknowledges the electronic signature is legally binding.

The verbatim text of all three statements is frozen at signing time and embedded in the evidence certificate, ensuring historical accuracy independent of any future copy changes. This supports compliance and non-repudiation requirements.

Evidence Certificate

When all required slots are complete, the processor generates an evidence certificate and appends it to the signed PDF. This certificate is designed to meet the technical requirements for admissibility as electronic evidence and supports non-repudiation under e-signature laws (E-SIGN Act, UETA, eIDAS) in most jurisdictions.

Certificate Contents:

• Document metadata: title, correlation ID, SHA-256 hash of rendered PDF (proves document integrity)
• Per-signer record:
  • Name and email (email hashed for storage)
  • IP address and user-agent (device/browser info for audit)
  • Slot state timeline (pending → activated → viewed → signed)
  • Timestamp of each state transition (nanosecond precision)
  • OTP verification record (if applicable)
• Consent acknowledgments:
  • Verbatim text of all three consent statements
  • Timestamp each consent was accepted
• Session metadata:
  • Signing mode (single/sequential/parallel)
  • Session expiration time
  • Engine version and tenant ID

PII Protection in Storage:

Email addresses are protected with multiple layers:

• In audit storage: Stored as HMAC-SHA256 hash (one-way, cryptographic hash—no recovery)
• In operational lookup: Encrypted with AES-256-GCM at rest (allows display without plaintext logging)
• In logs: Never logged in plaintext; correlation IDs and tokens only
• In evidence certificate: Hashed for durability while protecting privacy

This ensures the evidence certificate is tamper-evident and designed to support admissibility as electronic evidence, while preventing email exposure if storage is breached.

Data Residency & Compliance

Architecture Overview

Your Vault Platform deployment consists of:

Customer-Hosted Infrastructure (Your Azure Subscription):

• Vault Dispatcher (API, session state management, token generation)
• Vault Processor (rendering, signing, sealing, audit logging)
• Azure Blob Storage (documents, PDFs, signed documents, certificates)
• Azure Table Storage (audit records, evidence, session state)
• Application Insights (audit logging and tracing)
• SharePoint (optional integration for document storage/retrieval)

Vault Shared Services by Refract Logic (Refract Logic's Azure Subscription):

• eSign Portal (stateless UI, no document storage, session tokens only)
• Notification Service (email delivery orchestration via Azure Communication Services)
• Licensing API (metering, session validation, feature entitlements)

Data Flow - What Stays vs. What Crosses

Stays in Your Azure Subscription (stored at rest):

• Document source data (templates, field values, business context)
• Rendered PDF bytes (all rendering pipelines, all transformations)
• Signature bytes and images — stored in your Azure Table Storage and sealed into your Blob Storage; not persisted on portal servers (see note below)
• Form field values (initials, date, text, checkboxes)
• Signing workflow state (session state, slot status, completion tracking)
• Complete audit trail (every state change with timestamps)
• Evidence certificates — generated in your Processor and stored in your Blob Storage

All encrypted at rest in your storage. All in the Azure region of your choice.

Crosses to Vault Shared Services:

• Signer email address — for invitation delivery via Azure Communication Services
• Signer name and signature PNG — in-memory during HMAC callback dispatch to your Dispatcher (not stored on portal)
• Portal access token — stateless, time-limited, single-use HMAC-signed token
• Correlation ID — for distributed tracing across your Dispatcher and our systems
• Session state notifications — pending → signed, no document content

Protection of External Data:

All metadata transmitted to Vault Shared Services is protected under:

• HTTPS/TLS encryption in transit (AES-256)
• Data Processing Agreement (DPA) with Refract Logic
• Microsoft Standard Contractual Clauses (via Azure Communication Services)
• Email addresses hashed in any audit storage (HMAC-SHA256)

Compliance by Regulation

HIPAA Compliance Example

Scenario: Healthcare provider with patient consent forms

Patient Document (stays in your Azure):
├─ Rendered PDF with patient instructions
├─ Patient signature field
└─ Stored in encrypted Blob Storage

Patient Notification (routed through Vault Shared Services):
├─ Email invitation to sign (patient email + name transmitted)
├─ Unique portal link with time-limited token
├─ No document content included

Patient Signature flow:
├─ Signature drawn by patient in portal browser UI
├─ Portal POSTs HMAC-signed callback (includes signature PNG) → your Dispatcher
├─ Dispatcher validates HMAC, enqueues seal to Service Bus
├─ Processor seals PDF with evidence certificate
└─ Signed PDF + certificate stored in your Azure Blob Storage

Relevant considerations for covered entities:
├─ Document bytes (ePHI): stored in your subscription only ✓
├─ Patient email + name: transmitted to Vault Shared Services for portal session
│   → covered under Refract Logic DPA; BAA assessment recommended
├─ Patient signature PNG: transits Vault Shared Services in-memory during callback
│   → not stored; evaluate whether this meets your HIPAA requirements
├─ Audit trail: complete and immutable, in your subscription ✓
└─ Signer PII at rest: AES-256-GCM encrypted in your Azure Table Storage ✓

GDPR Compliance Example

Scenario: EU financial services company with contracts

Document Processing (in your Azure region):
├─ Documents stored in EU-West Azure region
├─ All rendering in EU-West
├─ All sealing in EU-West
└─ Data residency: EU (guaranteed)

Signer Notification (routed through Vault Shared Services):
├─ Signer email transmitted to ACS
├─ Covered by Microsoft Standard Contractual Clauses
├─ Data Processing Agreement in place
└─ Signer can exercise right to erasure (email hashed, can be deleted)

Relevant considerations for GDPR:
├─ Documents stored in EU Azure region (data residency in your control) ✓
├─ Personal data (email) processed under Refract Logic DPA and Microsoft SCCs ✓
├─ Right to access: document data and audit records are in your subscription ✓
├─ Right to erasure: signer email is stored as HMAC-SHA256 hash (audit) and as
│   AES-256-GCM encrypted value (operational display). Both must be deleted to
│   satisfy erasure. The encrypted value is in your Azure Table Storage under
│   your control. Hash-only deletion does not fully satisfy right to erasure.
└─ Cross-border: signer email transits Vault Shared Services (covered under SCCs);
    confirm Refract Logic's processing region meets your transfer requirements.

SOX Compliance Example

Scenario: Financial services company with invoice approvals

Signing Workflow (in your infrastructure):
├─ Invoice generated by AP system
├─ Invoice rendering in your Processor
├─ Invoice sent to Approver 1 (sequential signing mode)
├─ Approver 1 signs, evidence recorded
├─ Invoice sent to Approver 2
├─ Approver 2 signs, evidence recorded
├─ Signed invoice sealed with evidence certificate

Audit Trail (immutable, in your subscription):
├─ Invoice creation timestamp (June 4, 2026, 10:30:00 UTC)
├─ Approver 1 notification (June 4, 2026, 10:31:00 UTC)
├─ Approver 1 review (June 4, 2026, 10:35:00 UTC)
├─ Approver 1 signature (June 4, 2026, 10:36:00 UTC)
├─ Approver 2 notification (June 4, 2026, 10:36:01 UTC)
├─ Approver 2 review (June 4, 2026, 11:02:00 UTC)
├─ Approver 2 signature (June 4, 2026, 11:03:00 UTC)
└─ Document sealed (June 4, 2026, 11:04:00 UTC)

Audit evidence generated (supports SOX Section 302/404 documentation):
├─ Complete approval chain documented with timestamps ✓
├─ Proof of sequential approval order (non-repudiation) ✓
├─ Document integrity verified via SHA-256 hash ✓
├─ Signed consent acknowledgements per signer ✓
└─ Immutable audit trail in your subscription, available for inspection ✓

Create Signing Session: Quick Reference

POST /api/esign/session

Auth: Entra ID JWT

Request body:

{
  "correlationId": "rnd-00123",
  "documentId": "DOC-456",
  "docType": "vendor-contract",
  "pdfBlobPath": "generatedDocuments/2026/06/rnd-00123.pdf",
  "pdfHash": "sha256:abc123...",
  "signingMode": "sequential",
  "expiresInMinutes": 4320,
  "signers": [
    {
      "slotIndex": 0,
      "role": "vendor",
      "email": "[email protected]",
      "namePrefill": "Vendor Contact"
    },
    {
      "slotIndex": 1,
      "role": "manager",
      "email": "[email protected]"
    }
  ]
}

Response 201:

{
  "groupId": "a3f1c2d4-8e9b-4f0a-b2c3-1d4e5f6a7b8c",
  "expiresAt": "2026-06-12T12:00:00.000Z",
  "slots": [
    {
      "slotIndex": 0,
      "sessionId": "b5c2d3e4-9f0a-4b1c-d2e3-2e5f6a7b8c9d",
      "portalUrl": "https://portal.vaultpdf.io/sign?token=<slotToken>"
    },
    {
      "slotIndex": 1,
      "sessionId": "c6d3e4f5-0a1b-4c2d-e3f4-3f6a7b8c9d0e",
      "portalUrl": "https://portal.vaultpdf.io/sign?token=<slotToken>"
    }
  ]
}