Document Verification Guide

Table of Contents

1. What is Document Verification?
2. How to Verify a Document
3. Understanding Your Verification Results
4. What is a Verifiable Receipt?
5. The Transparency Log
6. Frequently Asked Questions (FAQ)

---

What is Document Verification?

When you sign a document through SignForge (or receive a document signed through SignForge), we create a multi-layered cryptographic proof that:

• These specific people signed it
• At this exact time the signing occurred
• The document hasn't been tampered with since signing (verified via hash comparison)
• This exact signed file was recorded in a public transparency log (verified via Merkle proof)

Think of it like a notary stamp — but digital, mathematically provable, and cryptographically protected against forgery.

How it works in practice: The signed PDF carries embedded proof (a W3C Verifiable Credential + public keys) that attests to the signing event, signers, and original document hash. The transparency log and downloadable receipt bind the final signed file's hash, completing the chain. Together, they prove both who signed what and this exact file is the result.

Real-World Analogy

Imagine you sign a contract at a notary's office. The notary:

1. Watches you sign (witnessing)
2. Stamps the document with their seal (attestation)
3. Records the signing in their logbook (transparency log)
4. Gives you a receipt (verifiable credential)
5. Takes a photo of the signed document (hash)

SignForge does all of this digitally. The "seal" is a cryptographic signature. The "logbook" is a public Merkle tree. The "photo" is a SHA-256 hash. And the "receipt" is a W3C Verifiable Credential embedded in the PDF itself.

---

How to Verify a Document

Method 1: Upload the PDF (Easiest)

1. Go to signforge.io/verify
2. Drag and drop your signed PDF
3. See instant verification results

Method 2: Use the Verification Code

Every signed document has a verification code (format: sf_xxxxxxxxxxxx) visible:

• On the QR code on the last page of the signed PDF
• In the audit certificate
• In the verification receipt

1. Go to signforge.io/verify
2. Enter the code or visit signforge.io/verify/sf_your_code_here

Method 3: Scan the QR Code

Every signed PDF has a QR code on the bottom-right of the last page. Scan it with your phone camera to go directly to the verification page.

Method 4: For Developers / AI Tools

# Compute the document hash
sha256sum your_document.pdf

# Check against the transparency log
curl https://signforge.io/api/transparency/hash/YOUR_HASH_HERE

# Or look up by verification code
curl https://signforge.io/api/verify/sf_your_code_here

---

Understanding Your Verification Results

When you verify a document, you'll see:

Verified (Green Shield)

Your document is authentic. The results show:

• Document title — The name of the envelope
• Sender — Who sent the document for signing
• Signer(s) — Who signed it and when
• Document hash — A unique fingerprint of the signed PDF
• Verification code — The unique code for this document

Additional Badges (if present)

• W3C VC 2.0 — The document includes a W3C Verifiable Credential (open standard receipt)
• Transparency Log #N — The document is recorded in our public transparency log at entry N
• EU Wallet Aligned — The receipt format aligns with the W3C VC standard that EU Digital Identity Wallets target

Hash Mismatch Warning (Yellow)

If you see "The file hash does not match," it means:

• The PDF was modified after signing (even adding a single space would trigger this)
• This doesn't necessarily mean fraud — it could be an innocent annotation
• But the current file is NOT the exact file that was signed

Not Found (Red)

• The document was not signed through SignForge
• Or it's so old that it predates our verification system
• Or the file is not a PDF

---

What is a Verifiable Receipt?

After signing is complete, everyone involved can download a Verifiable Receipt — a JSON file that proves the signing happened. This receipt:

• Follows the W3C Verifiable Credentials 2.0 standard (an open internet standard)
• Is digitally signed by SignForge using ECDSA cryptography
• Contains all signing details (who, what, when)
• Can be programmatically verified using open standards (not locked to SignForge)
• Is embedded inside the signed PDF AND available as a separate download

Why Would I Want the Receipt?

• Compliance records — Some industries require proof of signing separate from the document itself
• Audit trails — The receipt is machine-readable, making it easy to process in bulk
• Long-term preservation — Even if SignForge ceases to exist, the receipt's cryptographic signature remains verifiable
• EU Digital Identity Wallet — The receipt format aligns with the W3C VC standard that upcoming EU wallets target

---

The Transparency Log

What Is It?

Every document signed through SignForge is recorded in a public, append-only log. Think of it as a public ledger — but instead of financial transactions, it records signing events.

Real-World Analogy

Imagine a glass-walled vault containing a stack of numbered cards. Each card has a fingerprint (hash) of a signed document. The cards are numbered sequentially, and the system is designed to be append-only — any tampering would be detectable. Anyone can look through the glass and check if a specific fingerprint is in the stack.

That's our transparency log. The "glass wall" is the public API. The "numbered cards" are log entries. The "fingerprints" are SHA-256 hashes.

How to Use It

Visit signforge.io/transparency to:

• See how many documents have been logged
• Search for a specific document by its hash
• Look up a specific entry by its number

Technical Details (for the curious)

The log uses a Merkle Mountain Range (MMR) data structure — a type of hash tree that efficiently proves a specific item exists in a list without revealing any other items. Each entry comes with:

• A Merkle proof — a chain of hashes that proves this entry is part of the tree
• A Signed Tree Head (STH) — a snapshot of the tree state signed by our log key
• Both can be verified offline using only the public key

---

Frequently Asked Questions (FAQ)

General Questions

Q: Why don't I see a "trusted" or "valid signature" badge in Adobe Acrobat?

A: Adobe Acrobat's blue "Signed and all signatures are valid" badge only appears for signatures made with certificates from Adobe's Approved Trust List (AATL), which requires a paid signing certificate. This is a different trust model from the one SignForge uses.

Real-world analogy: It's like a "Verified" badge on social media. Not having the badge doesn't mean the account is fake — it means they use a different way to establish trust. Similarly, not having Adobe's badge doesn't mean the signature is invalid — it means we use an open, standards-based trust model instead.

What we provide instead:

• Our own verification at signforge.io/verify
• W3C Verifiable Credential (open standard, not locked to one company)
• Public transparency log with cryptographic proofs
• Embedded verification data that works offline
• QR code on every signed PDF for instant verification

Is the signature still legally valid? Yes. E-signatures are legally binding under the ESIGN Act (USA), eIDAS Regulation (EU), and equivalent laws in 60+ countries. Legal validity does not depend on any specific trust badge or vendor program.

---

Q: How is SignForge verification different from other e-signature platforms?

A: Most e-signature platforms provide tamper evidence and audit trails. SignForge goes further with a few key design choices:

• Embedded proof — Verification data lives inside the signed PDF, not just on our servers
• Open standards — Built on W3C Verifiable Credentials and Decentralized Identifiers, not a proprietary format
• Public transparency log — Anyone can check that a document was logged, with cryptographic proof
• Offline verification — Embedded keys and VC allow verification without contacting SignForge
• Tool-agnostic — Can be programmatically verified using open standards, not locked to one vendor

Many other providers rely more heavily on platform-hosted verification flows. SignForge emphasizes portable, self-contained proof that travels with the document.

Real-world analogy: Some platforms keep your receipt in their vault — you go to their website to see it. SignForge gives you the receipt embedded in the document itself AND records it in a public ledger that anyone can check.

---

Q: Is a SignForge e-signature legally binding?

A: Yes. Electronic signatures are legally recognized in many major jurisdictions, including:

• United States: ESIGN Act (2000) and UETA (1999)
• European Union: eIDAS Regulation (2014) — SignForge provides Simple Electronic Signatures (SES)
• United Kingdom: Electronic Communications Act (2000)
• Canada: PIPEDA and provincial legislation
• Australia: Electronic Transactions Act (1999)
• India: Information Technology Act (2000)
• 60+ other countries have equivalent legislation

What makes it legally valid:

1. Intent to sign (the signer clicked to apply their signature)
2. Consent to do business electronically
3. Association of signature with the record
4. Record retention (audit trail, certificate, verification)

What it's NOT suitable for:

• Wills and testaments (most jurisdictions require wet signatures)
• Court orders
• Some real estate transactions (varies by jurisdiction)
• Any situation requiring a Qualified Electronic Signature (QES) under eIDAS

---

Q: What happens if SignForge shuts down? Can I still verify my documents?

A: Yes. This is one of our core design principles. Here's what works even if signforge.io completely disappears:

1. Embedded W3C VC — The signed PDF contains a Verifiable Credential with a cryptographic signature. Any tool that understands W3C VCs can verify the signature using the embedded public keys.

2. Embedded public keys — The PDF contains signforge_keys.json with both public keys (issuer + log). These are all you need to verify the VC and STH signatures.

3. Embedded legacy JSON — The older verification format with its own ECDSA signature also remains in the PDF.

4. Transparency proof file — If you downloaded the transparency proof JSON, you can verify the Merkle proof against the signed tree head using basic SHA-256 operations.

What you lose if SignForge goes down:

• The web-based verification page
• New transparency log entries
• The ability to look up entries in the log
• did:web:signforge.io resolution (but did:key still works — it's the primary identifier)

Real-world analogy: If the notary's office burns down, your notarized document is still notarized. The stamp, seal, and signature on your document are the proof — not the office building.

---

Q: Can ChatGPT or Claude verify a SignForge document?

A: Yes! AI tools with internet access can verify documents in multiple ways:

Online verification (if SignForge is accessible):

"Can you verify this SignForge document? The SHA-256 hash is abc123...
Check https://signforge.io/api/transparency/hash/abc123..."

Offline verification (using embedded data): AI tools can extract and verify the embedded W3C VC's cryptographic signature using the embedded public keys, without contacting SignForge at all.

Verification code lookup:

"Look up SignForge verification code sf_abc123def456 at
https://signforge.io/api/verify/sf_abc123def456"

---

Q: What is a "Merkle tree" and why should I care?

A: A Merkle tree is a data structure used in cryptography to efficiently prove that a piece of data exists in a collection without revealing the rest of the collection.

Real-world analogy — The Tamper-Evident Notebook:

Imagine a notebook where:

• Each page has a unique fingerprint based on its content
• Each pair of pages combines into a chapter fingerprint
• Chapters combine into section fingerprints
• All sections combine into one master fingerprint (the "root")

If someone tries to change even one word on one page, that page's fingerprint changes, which changes the chapter fingerprint, which changes the section fingerprint, which changes the root. You can detect any tampering by just comparing roots.

Why it matters to you:

• It proves your document was logged at a specific position (entry #N)
• It proves no entries were added, removed, or reordered before or after yours
• It's the same technology used by Bitcoin, Git, and Certificate Transparency (the system that keeps SSL certificates honest)

---

Q: What does "EU Wallet Aligned" mean?

A: The European Union is building the European Digital Identity Wallet (EUDI Wallet) under the eIDAS 2.0 regulation. This wallet will allow EU citizens to:

• Store digital identity documents
• Present verifiable credentials
• Sign documents electronically

SignForge's signing receipts are built on W3C Verifiable Credentials 2.0 — the same open standard that EU wallets are designed to accept. This positions SignForge receipts for future EU wallet compatibility as the specifications are finalized.

Current status: We've built the technical foundation. Deep integration with specific wallet implementations will follow as the EU specifications are finalized.

---

Security Questions

Q: Can someone forge a SignForge verification?

A: To forge a valid verification, an attacker would need SignForge's private ECDSA key — a 256-bit secret. Breaking this requires approximately 2^128 operations, which is computationally infeasible with current or foreseeable technology.

However: If someone obtains our private key (through a server breach, for example), they could forge new verifications. Our two-key architecture limits the damage — compromising the issuer key doesn't let them forge the transparency log, and vice versa.

---

Q: What if someone modifies the PDF after signing?

A: Any modification — even adding a comment, highlight, or annotation — changes the file's SHA-256 hash. When you verify the modified PDF:

• The hash won't match the one in our records
• You'll see a warning: "The file hash does not match the original signed document"
• The embedded VC still proves it WAS originally signed (the VC signature remains valid)

Real-world analogy: If you photocopy a notarized document and write notes in the margin, the notary's stamp is still visible — but anyone comparing it to the original can see it was modified.

---

Q: How do I know SignForge isn't tampering with the transparency log?

A: Several mechanisms make tampering detectable:

1. Append-only design — We can only ADD entries, never modify or delete them
2. Merkle proofs — Each entry's proof is mathematically linked to all previous entries. Changing any past entry would change the root hash, which would invalidate all subsequent proofs
3. Signed Tree Heads — Each checkpoint is signed with a separate key. You can save STHs over time and detect if the tree was ever modified (the root would change)
4. Embedded proofs — Every signed PDF contains its own proof data. If we tampered with the log, the proofs in already-distributed PDFs would no longer verify

What we can't prevent: We could theoretically refuse to log a document (omission). But the absence would be detectable — if someone has a signed PDF with an embedded VC but can't find it in the log, that's suspicious.

Real-world analogy: Imagine a newspaper that prints a new page every day and never reprints old ones. You can keep old newspapers to verify that today's newspaper is consistent with yesterday's. If the newspaper tries to change history, your saved copies would show the discrepancy.

---

Q: Is my document data visible in the transparency log?

A: No. The transparency log contains only:

• A hash of the signed PDF (a 64-character hexadecimal string) — not the document content
• The envelope ID (a random UUID)
• The verification code (e.g., sf_abc123)
• Cryptographic proofs (Merkle proof, Signed Tree Head)

It does NOT contain:

• The document itself
• The document's content or text
• Signer names or email addresses
• Any personally identifiable information

The hash is a one-way function — you cannot reconstruct the document from its hash.

---

Technical Questions

Q: What hashing algorithm do you use?

A: SHA-256 (part of the SHA-2 family), as defined in FIPS 180-4. This is the same algorithm used by Bitcoin, TLS certificates, and most of the internet's security infrastructure. It produces a 256-bit (64 hexadecimal character) digest.

---

Q: What is did:key and why do you use it?

A: did:key is a Decentralized Identifier (DID) method from the W3C DID specification ecosystem. The did:key method itself is a W3C Credentials Community Group draft — widely adopted in the VC ecosystem but not yet a full W3C Recommendation. Unlike did:web (which resolves via HTTP), did:key encodes the public key directly in the identifier:

did:key:zDnae... → decode → public key bytes

Why we use it as primary:

• It works offline (no HTTP needed)
• It's domain-independent (works even if signforge.io is down)
• It's deterministic (same key = same DID, always)
• It's the mathematically strongest identifier — it IS the key

We also publish did:web:signforge.io as an alias for human-friendly discovery and service endpoint resolution, but verification always uses did:key.

---

Q: Can I verify a document programmatically?

A: Yes. Here are several approaches:

1. API verification (simplest):

curl https://signforge.io/api/verify/sf_YOUR_CODE

2. Hash check against transparency log:

HASH=$(sha256sum document.pdf | cut -d' ' -f1)
curl https://signforge.io/api/transparency/hash/$HASH

3. Extract and verify embedded VC (offline):

import fitz, json
doc = fitz.open("signed.pdf")
vc = json.loads(doc.embfile_get("signforge_receipt.vc.json"))
keys = json.loads(doc.embfile_get("signforge_keys.json"))
# Verify the DataIntegrityProof using the issuer's public key
# See /docs/verification-architecture for full implementation

4. Bulk verification:

for f in *.pdf; do
    hash=$(sha256sum "$f" | cut -d' ' -f1)
    result=$(curl -s "https://signforge.io/api/transparency/hash/$hash")
    echo "$f: $result"
done

---

Q: What is the difference between the embedded VC and the downloadable receipt?

A:

Both are signed with the same key and contain the same core data. The embedded copy is the self-contained proof that travels with the document. The downloadable version adds the signed PDF hash, which is useful for cross-referencing with the transparency log.

---

Q: How does SignForge compare to blockchain-based document signing?

A:

Key difference: Blockchain adds decentralization (no single operator can tamper). Our log is operated by SignForge — we mitigate this by publishing proofs in every PDF (distributed to all parties), making tampering detectable even without a third party.

---

Business Questions

Q: Can I use SignForge-signed documents in court?

A: E-signatures, including those created through SignForge, are generally admissible as evidence in court. The key factors courts consider:

1. Authentication — Can you prove the signature is genuine? (Yes — cryptographic proof)
2. Intent — Did the signer intend to sign? (Yes — active click/draw action required)
3. Record keeping — Is there an audit trail? (Yes — full event timeline)
4. Integrity — Has the document been altered? (Verifiable — hash comparison)

SignForge provides all four elements. Our audit certificate documents the complete signing process, and our verification system provides mathematical proof of document integrity.

Disclaimer: We are not lawyers. For specific legal advice about e-signature admissibility in your jurisdiction, consult with a legal professional.

---

Q: What is the audit certificate?

A: The audit certificate is a separate PDF document generated after signing is complete. It contains:

• Document information (title, ID, completion time)
• Sender and signer details
• Document integrity hashes (original + signed PDF)
• Verification code and URL
• Transparency log entry (if available)
• Complete audit event timeline (every action: created, sent, viewed, signed, completed)
• IP addresses and timestamps for each event
• Legal notice about e-signature validity

The certificate is available for download by both the sender and the signer.

---

Q: Do you store my documents?

A: Yes, we store your documents in encrypted storage for as long as your account is active. However:

• Documents are stored in a private bucket — no public URLs
• All access goes through our backend with authentication checks
• You can delete envelopes from your dashboard (verification records are preserved separately)
• We do NOT sell, share, or analyze your document content
• See our Privacy Policy for full details

---

Q: Can I verify documents in bulk?

A: Yes, using our API:

# Verify multiple documents by hash
for file in *.pdf; do
    hash=$(sha256sum "$file" | cut -d' ' -f1)
    response=$(curl -s "https://signforge.io/api/transparency/hash/$hash")
    verified=$(echo "$response" | jq -r '.entry_id // "NOT FOUND"')
    echo "$file -> Entry #$verified"
done

Rate limits apply (30 requests/minute for transparency lookups). For higher volumes, contact us.

---

Glossary

---

This guide is maintained by the SignForge team. For technical implementation details, see the Verification Architecture reference.