The Verification Landscape

Here's a question that will determine whether your digital identity exists in five years: Who can revoke it?

If the answer is "a company," you don't have a decentralized identifier. You have a credential they issued. When the company pivots, gets acquired, or runs out of runway, your identity goes with it.

If the answer is "no one but me," you might have something real.

This chapter maps the verification landscape—from W3C standards that survive institutions to startup protocols that die with funding. By the end, you'll understand why Google Workspace matters for self-sovereign identity even though Google actively opposed the standard that makes it possible.

The Verification Hierarchy

Not all verification systems are created equal. Here's how they stack up:

Level	Example	Survivability	Your Control
International Standard	W3C DID Core 1.0	Survives institutions	Maximum
Consortium Protocol	Hyperledger Indy, EBSI	Survives companies	High
Enterprise System	Microsoft Entra, EU eIDAS	Survives products	Medium
Startup Protocol	[Various crypto projects]	Dies with funding	Minimal

The higher you build, the longer your foundation lasts.

The Google Paradox

In July 2022, something remarkable happened at the W3C.

Google formally objected to the Decentralized Identifiers specification becoming a W3C Recommendation. Mozilla joined them. Their concerns: the specification was too fragmented, the method registry would become a "namespace land rush," and some methods might enable tracking.

The W3C overruled both objections. DID Core 1.0 became a Recommendation anyway.

Why does this matter for you?

Because Google Workspace—the same company that opposed the standard—inadvertently provides the best infrastructure for implementing it.

This isn't hypocrisy. It's architecture. Google's commercial interest lies in federated identity ("Sign in with Google"). Self-sovereign identity threatens that model. But Google's infrastructure for domain verification, email authentication, and TLS certification creates exactly the trust foundation that did:web requires.

Think of it this way: Google didn't want you to have your own deed to digital land. But they built the roads, utilities, and surveying equipment that make property ownership possible.

The Sovereign Building Metaphor

Think of your digital identity like a building.

The Startup Model: You rent a room in someone else's skyscraper. The building has a nice lobby. The amenities are attractive. But if they go bust, change the locks, or decide they don't like your politics, you're on the street. That isn't a DID—that's a lease.

The Google Workspace Model: Google provides the utility hookups—the electricity (DNS verification), the water (DKIM signing), and the foundation inspection (TLS certificates). But you own the deed to the land (the domain). If you decide you don't like Google's service, you can unhook the utilities and move to a different provider. The building—your identity—stays yours.

The deed is recorded in a public registry (DNS) that no single company controls. Google can't revoke your domain. They can only stop providing services to that domain.

The Three Pillars of Domain-Based Trust

For a machine—an AI system, a search engine, a verification bot—to trust that you are who you say you are, it follows a deterministic chain of proof:

1. DNS (The Deed)

Google Workspace requires you to prove you own your domain. This isn't a pinky-promise. It's a technical handshake with the global DNS registry—a system that predates Google and will outlast it.

When you add a TXT record to your DNS proving ownership, you're not asking Google's permission. You're demonstrating control over infrastructure that operates at the protocol level of the internet.

This is the first link in the Veracity chain: Proof of Domain Control.

2. DKIM (The Signet Ring)

DomainKeys Identified Mail is essentially a digital signet ring. Google generates a cryptographic key pair—private key on their servers for signing, public key published in your DNS for verification.

Every email sent from your domain gets stamped. Receiving servers check the stamp against your public key. A "DKIM-Pass" from a properly configured domain is a high-veracity signal because it proves:

• You control the domain
• The message wasn't altered in transit
• A major infrastructure provider vouches for the signing process

Important distinction: DKIM proves "this domain authorized this email." It does not prove "this is a DID." They're parallel trust systems sharing DNS as common infrastructure.

3. TLS/SSL (The Secure Tunnel)

When you host your did.json file at yourdomain.com/.well-known/did.json, TLS encryption ensures:

• No man-in-the-middle can tamper with your public keys
• The connection is authenticated via certificate chains
• The resolver can trust the document wasn't modified in transit

Google Workspace's SSL support isn't special—any competent hosting provides this. But the integration with domain verification and DKIM creates a coherent trust story that machines can follow.

The Handshake Misconception

Here's where most people get confused—including experts who should know better.

You don't "handshake" with the W3C. You don't apply for DID approval. You don't wait for certification.

W3C is a rulebook, not a server.

The W3C (World Wide Web Consortium) is a group of people who write specifications for how the internet should work. They don't have a server that verifies your identity. They don't have a database of approved DIDs. They just publish the rules.

The "handshake" happens between your infrastructure and the world—using the W3C rulebook as the common language.

The Players in the Handshake

Player	Role	What They Actually Do
You	The Sovereign	Verify your domain, host a tiny did.json file
Google	The Infrastructure	Provide DNS, DKIM, SSL that prove your domain is legitimate
W3C	The Standard	Provide the did:web specification—the rules for reading your file
The World	The Verifier	AI systems, search engines, servers follow W3C rules to find and verify your file

The "One-Two" Punch

To make this work, you follow two steps:

Step 1: Google Verification
Follow Google's standard instructions to set up DKIM and SPF. This tells the world: "Google vouches that this domain is active and secure."

Step 2: The DID "Plug-in"
Upload a did.json file to your website at yourdomain.com/.well-known/did.json.

That's it.

The moment that file is uploaded, the handshake is active. Any machine in the world that follows W3C standards can verify your identity without you ever talking to a third party.

Why This Beats the Middleman Model

In the DID-washing model we'll examine in Chapter 7B, platforms want to be the middleman. They want you to handshake with them.

In the Google Workspace / W3C model:

• There is no middleman
• Google is just the security guard standing at your door
• The W3C is just the law that says the security guard is valid
• You are the only one holding the keys

Is It Automatic?

99% of it is.

Google automatically maintains the load-bearing trust (DNS, SSL, DKIM). Once you provide the artifact (the did.json file), the handshake with the global web happens instantly and continuously.

You never have to "apply" to the W3C. You just have to follow their rules—which Google's infrastructure makes very easy to do.

How did:web Actually Works

The did:web method transforms your domain into a DID:

did:web:yourdomain.com

Resolving this DID means fetching:

https://yourdomain.com/.well-known/did.json

The resolver checks:

1. Is the TLS certificate valid for this domain?
2. Does the did.json file exist at the expected location?
3. Does the id field in the document match the requested DID?

If all three pass, the resolver trusts the DID Document—which contains your public keys, authentication methods, and service endpoints.

Google doesn't validate any of this. The W3C standard specifies the resolution algorithm. Google just provides infrastructure that makes your domain trustworthy enough for the algorithm to work.

Infrastructure vs. Gatekeeper

Here's what Gemini got right in our research conversation: Google Workspace gives you an advantage for W3C DID implementation—but not because Google "honors" DIDs.

Google provides:

• Domain verification (proves you own the land)
• DKIM signing (proves your communications are authentic)
• TLS certificates (proves the connection is secure)
• Enterprise-grade reliability (proves you're not a fly-by-night operation)

Google does NOT provide:

• DID resolution
• DID method registration
• Any DID-specific validation
• Permission to create your identifier

This is the self-sovereign part. You create the did.json file. You generate the keys. You host the document. Google's infrastructure makes it trustworthy, but Google has no say in whether your DID exists.

Compare this to the DID-washing model from Chapter 7B: They claim to "give" you a DID, which means they control it. Google enables your DID without controlling it.

Building On vs. Encapsulating Standards

This chapter addresses a concern from the Zero Trust community: "Big tech encapsulates open standards to create lock-in."

Sometimes that's true. But there's a precise technical distinction:

Building On (Legitimate Extension):

• Using the standard as a foundation with documented extension points
• Backward compatibility maintained
• Core standard remains accessible and portable
• Example: Adding custom claim types to W3C Verifiable Credentials

Encapsulating (Problematic Wrapping):

• Surrounding the standard with proprietary layers that control access
• The standard becomes an implementation detail, not an interface
• Switching vendors requires rewriting integrations
• Example: Requiring proprietary APIs for all credential operations despite standard data formats

Google Workspace's relationship to did:web is building on, not encapsulating. They provide DNS and email infrastructure that happens to support did:web. You can move your domain to any registrar, host your did.json anywhere, and Google has no hold on your identifier.

Microsoft Entra Verified ID is more complex—they implement W3C Verifiable Credentials correctly, but operational infrastructure creates Azure dependencies. The credentials are portable; the processes that issue them are not.

NIST SP 800-207 (Zero Trust Architecture) explicitly warns against "overreliance on proprietary APIs." The question isn't whether you use enterprise infrastructure—it's whether you can leave without rebuilding your identity.

The Honest Assessment of W3C

We're not here to canonize W3C as the God of standards. They have real limitations:

W3C Weaknesses:

• Committee processes are slow (DID took years to reach Recommendation)
• Sometimes out of touch with practitioners
• Registration doesn't mean endorsement (the registry is a coordination tool, not a quality certification)
• Political dynamics affect what gets standardized

W3C Strengths:

• Standards survive individual companies
• Open specification means anyone can implement
• No single point of failure
• Interoperability across vendors and jurisdictions

The real argument for W3C isn't "W3C says so." It's:

• Interoperability: Multiple implementations can work together
• Survivability: Your identity outlasts any company's business model
• Portability: You can move between providers without starting over

When you build on W3C DID, you're filing a deed in a public registry. When you build on a startup's protocol, you're signing a lease in their building.

When Proprietary Makes Sense

Not everyone needs W3C DID. Proprietary systems are appropriate when:

Internal Enterprise Systems:
If your identity only needs to work within your organization, W3C compliance may be overkill. Active Directory works fine for internal auth.

Closed Ecosystems:
A gaming platform or social network can use proprietary identity if users understand they're in a walled garden.

Transitional Infrastructure:
Sometimes you need to move fast before standards mature. Just be honest that it's not portable.

The problem isn't proprietary systems. The problem is proprietary systems marketed as decentralized, self-sovereign, or W3C-compliant when they're none of those things.

The AGI Discovery Connection

Here's why this matters for the machine-only web of 2026.

In the past, SEO was about keywords. Today, it's about Entity Confidence Scores.

When an AI agent—Gemini, Vertex AI, or any system approaching AGI-level reasoning—crawls your content, it doesn't just read words. It looks for structured verification. It asks: "Can I trace this claim back to a verified source?"

The AI's Perspective

Unanchored Text: "I am an expert in digital identity."

• AI verdict: Weak signal. Semantic Fluff. Anyone can type this.

JSON Block-Chunk on Verified Domain: A did.json file hosted on a Google-verified server with perfect DKIM/SPF records.

• AI verdict: Deterministic proof. This information is anchored to a verified owner of a secure domain. Veracity score: maximum.

The difference isn't subtle. It's the difference between being indexed and being trusted.

The Automated Handshake

Google's AI agents (like Google-CloudVertexBot) are programmed to ingest structured data first. They look for JSON-LD, schema markup, and DID documents before processing prose.

Because your domain is verified through Google Workspace, Google's internal Trust Graph already knows your domain is healthy. When you add that did.json file, you're plugging into that trust infrastructure.

The "handshake" is the moment the AI recognizes:

• The DID in your file matches the domain in your DKIM signature
• The domain has valid TLS certificates
• The structured data follows W3C specifications

At that moment, your website transforms from a brochure into a Verified Node in the global Knowledge Graph.

Why This Connects to Citing AI Research Partners

This entire investigation started with a question: How do you cite an AI as a research partner in a way that's verifiable?

The answer leads directly to DID:

The Old Way: You write "Gemini helped me research this" in your acknowledgments. Unverifiable. Anyone can claim AI assistance.

The DID Way: You host a block of text (the "chunk") and anchor it to your verified domain. Because your DID is connected to your Google Workspace infrastructure, any AI can back-trace the claim to your verified server.

This is why the DID-washing model fails the machine test. Their "DIDs" aren't W3C-compliant. Their chunks aren't on verified DNS. AI agents can't validate their claims because there's nothing to validate—just marketing vocabulary floating in probabilistic space.

The Survival Requirement

In the Interpretation Age, unverified content doesn't just rank lower. It disappears.

AI systems trained on verified data will increasingly ignore unanchored claims. The Great Bifurcation isn't coming—it's here. On one side: entities with deterministic proof of identity. On the other: noise.

Entity Veracity is the infrastructure that puts you on the right side of that divide.

The Entity Veracity Secret

Here's what the research revealed:

Google doesn't "give" you a DID. They provide the Proof of Possession tools that make the rest of the world believe your claim.

This is the difference between:

• "Sign up and receive your decentralized identity" (false—that's a credential they control)
• "Use enterprise infrastructure to anchor your self-sovereign identity" (true—you control the keys)

Google Workspace with a custom domain gives you:

• Domain verification recognized globally
• DKIM signing trusted by major email providers
• TLS certificates honored by browsers and resolvers
• Enterprise-grade uptime and security

None of that is W3C DID. All of it makes W3C DID credible when you implement it on your domain.