Portable Eligibility: Turning Credentials into Composable Market Access

Why Agentic Systems Expose the Cost of Non-Portable Access

This essay is split into 3 parts arranged in a logical sequence. I believe that this provides an easier way to read this over a period of time as opposed to breaking it up into three distinct sequential essays.

Part 1 — From Identity to Eligibility Infrastructure

A Day in the Life of Non-Portable Eligibility

Asha manages procurement for a mid-sized manufacturer. This morning, she needed to verify that a new supplier meets their compliance requirements: ISO 9001 certification, conflict minerals disclosure, and carbon reporting under the SEC’s climate rules.

The ISO certificate came as a PDF. She manually checked it against the certification body’s website. The minerals disclosure required a phone call because the supplier’s portal was down. The carbon report existed in three different formats across two platforms, none of which could be automatically verified. By noon, she had spent four hours on tasks that should have taken minutes.

Meanwhile, the supplier had already provided these exact proofs to seventeen other buyers this quarter, each time reformatting, re-uploading, and re-explaining the same information. The supplier maintains five different vendor portals, each with different requirements for how eligibility should be documented.

This is not a story about insufficient technology. Both parties use modern systems. This is a story about trapped eligibility—credentials that exist but cannot move, claims that must be continually re-proven, verification logic that must be rebuilt for each relationship.

When we talk about portable eligibility, we are talking about fixing this. Not as a convenience, but as infrastructure.

The Quiet Shift From Identity to Eligibility

Most discussions about digital identity focus on authentication and verification: proving you are who you claim to be. This framing increasingly misses the actual question markets ask. They don’t primarily care who you are. They care whether you can do something specific, under defined conditions, right now.

A bank doesn’t lend because someone exists. It lends because that person satisfies creditworthiness criteria, regulatory constraints, and product fit requirements at a specific moment. A platform doesn’t grant API access because a developer is known. It grants access because the developer meets rate limit policies, liability requirements, and security posture standards.

This distinction between identity and eligibility seems subtle but proves foundational. Identity is relatively stable. Eligibility is continuously evaluated. Identity is about recognition. Eligibility is about routing through systems of access, pricing, and risk.

This shift has been happening quietly for twenty years. Payment networks evaluate transaction eligibility in milliseconds. Insurance companies recalculate risk eligibility continuously. Platforms adjust content distribution eligibility based on evolving moderation and monetization criteria. What has changed is that this logic, once embedded in proprietary systems, is now being standardized and externalized.

When eligibility becomes machine-readable infrastructure rather than human-interpreted documentation, questions that seemed theoretical become operational: How does eligibility move between systems? Who controls its meaning? What happens when it needs to be revoked? Can it be composed with other eligibility claims to satisfy complex requirements?

Why Current Systems Resist Portability

Before critiquing existing systems, it’s worth understanding why they evolved as they did. Platform-specific eligibility logic emerged for legitimate reasons, not just from a desire for control.

First, coherence and liability. When a platform controls the full stack (issuance, verification, enforcement) it can guarantee consistency. If criteria change, the platform can update all affected parties simultaneously. If something goes wrong, there is clear accountability. Introducing portability means introducing dependencies on external systems you don’t control.

Second, context specificity. Different markets genuinely need different things. A “verified business” means something different to a payment processor (risk assessment), a marketing platform (ad policy compliance), and a supply chain network (sustainability certifications). Trying to make one credential serve all three contexts often results in over-collection or vague semantics.

Third, coordination costs. Standards require coordination. Registries require governance. Conformance requires enforcement. For a single platform serving millions of users, building proprietary systems is often faster and cheaper than coordinating with competitors.

These are real tradeoffs, not cynical excuses. The problem is that the initial efficiency of proprietary systems calcifies into structural lock-in. What starts as a pragmatic choice becomes a competitive moat. Switching costs that were originally incidental become strategic. And eventually, the platform’s interests diverge from the ecosystem’s interests.

Portable eligibility is worth pursuing not because current systems are irrational, but because the externalities have become too large to ignore.

What Portability Actually Requires

Portability is often misunderstood as transport: if a credential can be exported and reshared, it must be portable. But a credential that can be shown everywhere but accepted nowhere accomplishes nothing.

True portability has three hard requirements:

Shared semantics. The meaning of an eligibility claim must be stable across contexts. When a credential says “licensed to operate commercial vehicles under FMCSA regulations,” different verifiers must interpret this the same way. This doesn’t require universal schemas - it requires registries that anchor meaning.

Shared verification patterns. Different verifiers must be able to check the claim without bespoke integration. This means standardized cryptographic proofs, status checking protocols, and revocation mechanisms. A credential that requires calling the issuer for each verification is not meaningfully portable.

Shared lifecycle expectations. Eligibility changes. Licenses expire. Compliance lapses. Organizations get sanctioned. A portable eligibility system must propagate status changes in near real-time, or verifiers will either ignore the credentials (destroying portability) or re-verify constantly (destroying efficiency).

Without all three, portability theater emerges: systems that appear interoperable while quietly preserving local control.

Consider the difference between two approaches:

Non-portable: A vendor management system stores supplier certifications as PDF attachments. When a buyer needs proof of compliance, they review the PDF, manually verify it against third-party databases, and update their internal records. If the certification is revoked, the buyer might not learn for months.

Portable: A supplier holds verifiable credentials for each certification. When a buyer needs proof, the supplier presents a credential that the buyer’s system can cryptographically verify in seconds. The credential references a status registry that reflects revocations within hours. If the buyer needs the same proof next quarter, the credential can be reused if still valid and no re-verification is needed.

The second approach isn’t just faster. It enables new market behaviors: automated compliance checking, real-time risk assessment, multi-party workflows that don’t require centralized coordination.

Eligibility Tokens as Composable Claims

To reason more precisely, it helps to introduce a design abstraction: the eligibility token.

An eligibility token is a verifiable claim that asserts a specific capability or status under defined conditions. Crucially, it is designed to be composed with other tokens to satisfy complex eligibility requirements.

Instead of issuing broad credentials that try to answer every possible question (”trusted supplier”), a system issues narrow claims:

• ISO 9001 certified by Bureau Veritas, valid until 2026-03-15

• Conflict minerals disclosure compliant under SEC rule, last updated 2025-12-01

• Carbon emissions reported under TCFD framework, scope 1-3, verified by third party

A buyer requiring all three can verify each independently. A buyer requiring only some can request just those. A new requirement, say, modern slavery reporting, can be added without reissuing the entire package.

This composability reduces over-collection (verifiers only see what they need) and increases reusability (holders don’t repeatedly surrender the same information). It also makes changes cheaper. When one certification needs renewal, only that token is reissued.

The key insight is that eligibility tokens should answer specific questions rather than attempting to summarize an entity. “Eligible to perform X under condition Y until time Z” is structurally superior to “verified participant.”

The Privacy Question That Isn’t

A persistent objection: if eligibility can move, surveillance becomes easier. The argument runs like this: portable credentials create correlation risks because the same credential, presented to multiple verifiers, can be tracked.

This concern confuses correlation with portability and treats surveillance as an inevitable byproduct of reuse. In reality, surveillance emerges from specific architectural choices:

• Binding eligibility tightly to persistent identifiers

• Reusing static identifiers across contexts

• Centralizing verification logs in ways that create correlation opportunities

Portable eligibility, properly designed, does the opposite. It decouples issuance, presentation, and verification. It allows claims to be proven without persistent identifiers (through zero-knowledge proofs or selective disclosure). It scopes disclosures to purpose and minimizes data reuse.

Consider two architectures:

Architecture A (surveillance-prone): A user authenticates to a central identity provider each time they need to prove eligibility. The provider logs each verification request. Over time, the provider can see everywhere the user has presented credentials, building a complete activity profile.

Architecture B (privacy-preserving): A user holds credentials locally. When eligibility must be proven, the user’s wallet generates a proof without contacting the issuer. The proof contains no persistent identifiers and cannot be linked to other presentations. Verifiers check the proof’s cryptographic validity and query a public status registry that reveals only whether the credential class remains valid—not who is presenting it.

The real threat to privacy isn’t that eligibility moves. It’s that it moves through chokepoints controlled by actors with incentives to observe and monetize behavior.

This distinction shifts the conversation from “should eligibility be portable?” to “how should portability be architecturally constrained?” Privacy becomes an emergent property of design choices, not a policy overlay.

Switching Costs as the Real Battleground

The economic case for portable eligibility is best understood through switching costs.

When eligibility is non-portable, actors face friction whenever they change platforms or relationships. A supplier switching from one buyer network to another must re-prove all compliance. A professional changing industries must re-establish credentials that should transfer. A user leaving one platform for another loses accumulated reputation and access.

These switching costs shape market structure. High switching costs reduce competition, slow innovation, and entrench incumbents. They also allow platforms to externalize costs (users bear the cost of re-verification) while internalizing benefits (platforms capture users through lock-in).

Quantifying this matters. Consider our earlier example:

• Supplier spends 40 hours/quarter managing vendor portals and re-proving compliance

• At 75 INR/hour blended cost, that’s 3,000 INR/quarter or 12,000 INR/year per supplier

• Across an industry with 50,000 suppliers, that’s 600 INR million in annual deadweight loss

• This doesn’t count buyer-side verification costs or delays

Portable eligibility attacks this directly. By allowing claims to move, it allows actors to renegotiate participation without starting from zero. This doesn’t eliminate platform differentiation. The platforms can still compete on features, pricing, and service. It eliminates captivity.

Unsurprisingly, this is where resistance emerges. Incumbents often support interoperability initiatives that preserve local control while opposing designs that enable genuine exit. They advocate standards that are broad enough to adopt but vague enough to reinterpret. They implement “portability” features that export data but not eligibility. This results in giving users their history while forcing them to rebuild access.

Understanding this dynamic is essential. Portable eligibility is not a neutral technical upgrade. It redistributes leverage from platforms to participants.

The Lifecycle Problem Everyone Defers

Issuance is relatively straightforward. Lifecycle governance is where systems fail.

Eligibility is dynamic. People lose licenses. Organizations fall out of compliance. Regulations change. Fraud is detected. A portable eligibility system that cannot express, propagate, and enforce status changes in near real-time creates false confidence which is possibly worse than no system at all.

Consider what happens when a professional license is revoked:

• Traditional system: The licensing board updates its internal database. Employers who checked the license previously have no notification. Revalidation happens only when someone thinks to recheck which is often months or years later.

• Portable system with poor lifecycle: A verifiable credential was issued, but there’s no mechanism for timely revocation. The credential continues to validate cryptographically even though it’s no longer valid legally. Verifiers don’t know they should recheck.

• Portable system with good lifecycle: The credential references a status registry. When revoked, the registry updates within hours. Verifiers checking the credential see the revocation immediately. Holders are notified. High-stakes verifiers can set policies to recheck critical credentials daily.

The difference is not just operational, it’s about trust. Systems without credible lifecycle management force verifiers to either ignore credentials (destroying portability) or implement expensive, duplicative verification (destroying efficiency).

Lifecycle governance raises uncomfortable questions:

• Who can change status? Just the issuer, or can third parties (regulators, courts) force changes?

• How quickly must changes propagate? Real-time, hourly, daily?

• What evidence is required for revocation? How are disputes handled?

• Are holders notified when their credentials are revoked? Are verifiers obligated to recheck?

These questions allocate power and liability. Different answers suit different actors. Deferring these questions doesn’t make them disappear. Instead, it shifts resolution into opaque, unilateral mechanisms.

Registries as Shared Memory, Not Control Planes

Registries are the most contentious component of portable eligibility infrastructure. Critics fear centralization. Proponents fear fragmentation. Both sides often misunderstand what registries actually need to do.

A registry, properly designed, does not decide who participates. It decides what claims mean.

Think of registries as distributed dictionaries. They anchor schemas (what structure do eligibility claims have?), publish trust frameworks (which issuers are accepted for which purposes?), and expose status endpoints (is this credential still valid?). They constrain interpretation, not behavior.

This distinction is critical. Once a registry starts listing eligible actors, it becomes a gatekeeper. Once it starts enforcing policy, it becomes a regulator. Both roles create incentives to centralize power and slow evolution.

There are multiple registry types:

• Schema registries define structure and semantics for claim types

• Trust registries list which issuers are accepted under specific policies

• Status registries expose real-time credential validity

• Governance registries document decision processes and change authority

Collapsing these into one system is convenient but dangerous. Separation of concerns isn’t optional - it’s the only way to keep infrastructure from becoming control planes.

Different sectors will run different registries with different governance models:

• Financial services might have industry consortiums managing trust registries

• Professional licensing might have state-level status registries

• Supply chain compliance might have multi-stakeholder schema registries

This plurality isn’t fragmentation - it’s appropriate specialization. The goal is federation, not universal consolidation.

Part 2 — Architecture, Conformance, and Governance

Schema Design as Market Grammar

Schemas are often treated as documentation: a way to make data readable between systems. This dramatically understates their role. In a portable eligibility ecosystem, schemas define what kinds of claims are even possible.

A schema is not just a data structure. It’s a contract about meaning. It specifies which attributes matter, how they relate, and what can be asserted without additional explanation.

Consider two schema designs for “commercial driver eligibility”:

Monolithic schema: Includes name, date of birth, address, license number, license class, endorsements, restrictions, issue date, expiration date, previous violations, medical certification status, and employer history.

Composable schemas:

• Core claim: “Authorized to operate Class A commercial vehicles, expires 2026-05-14”

• Separate claim: “Hazmat endorsement E1234, issued 2023-02-10”

• Separate claim: “Medical certification current, next required 2025-08-01”

The monolithic schema seems comprehensive. But it forces over-collection (why does a fuel company need to know your address?), creates privacy risks (full violation history isn’t always relevant), and makes selective disclosure impossible.

The composable approach allows verifiers to request exactly what they need. A basic delivery job requires the core claim. A hazmat transport job requires that plus the endorsement. An insurance company might want all three. Each verification sees only what’s necessary.

This principle - favor small, purpose-bound schemas over monolithic ones - proves harder to follow than it sounds. There’s strong pressure to design schemas that capture “everything we might need.” This feels efficient and future-proof. In practice, it hardens assumptions too early and forces either over-sharing or complex subsetting mechanisms.

Good schema design requires ruthless scoping: What specific question does this credential answer? What’s the minimum information needed to answer it? Can it be composed with other credentials to answer more complex questions?

Schemas should evolve slowly, extend deliberately, and resist becoming identity containers. Their job is making eligibility legible, not describing people.

Conformance: Where Interoperability Lives or Dies

Standards define possibility. Conformance defines acceptability.

Most interoperability initiatives fail not because standards are missing, but because conformance is vague. Systems claim compliance while interpreting requirements differently. Portability collapses under exceptions, profiles, and undocumented assumptions.

A conformance regime for portable eligibility must specify not just structure but behavior:

• How claims must be issued (which cryptographic suites, which metadata is required)

• How they must be verified (which checks are mandatory, which are optional)

• How errors are handled (what happens if status can’t be checked?)

• How status is determined (polling frequency, cache lifetime, failure modes)

• How disputes are resolved (who arbitrates conflicting claims?)

This level of specificity makes some parties uncomfortable. It removes discretion. It makes hidden assumptions explicit. It forces clarity about risk tolerance and liability allocation.

Consider status checking. A vague standard might say “verifiers should check credential status.” A conformance regime must specify:

• MUST check status for credentials older than 24 hours before making high-stakes decisions

• SHOULD check status for credentials older than 7 days before making medium-stakes decisions

• MAY cache status for up to 1 hour for low-stakes repeated checks

• MUST NOT proceed if status check fails for high-stakes decisions

• SHOULD log status check failures and MAY proceed with additional verification for medium-stakes decisions

This level of specificity seems bureaucratic. It’s actually liberating. Clear conformance rules enable:

• Automated compliance checking

• Interoperability testing

• Liability clarity

• Competitive benchmarking

Without them, “portable eligibility” becomes meaningless—every implementation interprets requirements differently, and portability exists only in marketing materials.

Profiles: Necessary Specialization Without Fragmentation

No conformance regime remains singular for long. Different sectors have different risk profiles. Different jurisdictions impose different constraints. Different use cases justify different tradeoffs.

This specialization is inevitable and healthy. The danger lies in uncontrolled proliferation creating de facto silos.

Portable eligibility systems need explicit mechanisms for profiling:

• Base profile: Minimum requirements all implementations must meet

• Domain profiles: Sector-specific extensions (financial services, healthcare, supply chain)

• Jurisdiction profiles: Regulatory requirements (GDPR compliance, SEC reporting, HIPAA)

• Risk profiles: Different conformance based on stakes (high-value transactions, public safety)

Each profile should:

• Explicitly reference the base it extends

• Document any deviations and justify them

• Specify compatibility expectations with other profiles

• Define sunset or review timelines

Without this discipline, profiles become proprietary flavors. With it, they become legitimate specialization that preserves core portability.

The governance question matters: who can create profiles? How are conflicts resolved? When do profiles become mandatory?

Different approaches work for different contexts:

• Open profiling: Anyone can publish a profile; adoption is organic

• Consortium profiling: Industry groups create profiles through consensus

• Regulatory profiling: Jurisdiction-specific profiles mandated by law

All three will coexist. The key is making profile boundaries visible and negotiable rather than hidden and imposed.

Lifecycle Infrastructure as First-Class Concern

If schemas are market grammar and conformance is reliability, lifecycle infrastructure is the mechanism that makes eligibility actually trustworthy at scale.

Three core functions:

Status publication: Issuers must expose machine-readable, real-time status for credentials they’ve issued. This can’t be an afterthought API. It must be reliable, performant, and standardized. Different approaches:

• Status list: Bitstring indicating which credentials in a batch are valid

• Status registry: Service that returns current state for a credential

• Blockchain anchor: Immutable record of revocations

Each has tradeoffs. Status lists scale well but have granularity limits. Registries are flexible but create dependencies. Blockchain approaches are transparent but expensive.

The choice should be driven by use case, not ideology. High-volume, low-stakes credentials might use status lists. High-stakes, infrequent credentials might use registries with audit trails.

Status checking: Verifiers must check status before relying on credentials. But how often? With what fallback?

This is where conformance meets business logic:

• Critical safety decisions (medical procedures, aircraft maintenance): Check every time, fail closed if unreachable

• Financial transactions: Check every time, risk-based fallback if unreachable

• Routine authorization: Check periodically, cache with bounded staleness

• Public information: Check opportunistically, degrade gracefully

No single answer serves all cases. The infrastructure must support all patterns while making the tradeoffs explicit.

Holder notification: When credentials are revoked or suspended, holders should be notified. This seems obvious but is rarely implemented well.

Why notification matters:

• Dignity: People deserve to know when their credentials are questioned

• Correction: Notification enables disputing erroneous revocations

• Cascading: Holders can update dependent parties rather than allowing stale credentials to propagate

Implementation requires care. Notification channels must be reliable without creating privacy risks. Notification content must be informative without being weaponizable.

Revocation as Contested Authority

Revocation is where power becomes visible.

Who can revoke a credential? Under what conditions? With what due process? These questions determine whether portable eligibility empowers or oppresses.

Issuer revocation: The entity that issued a credential can typically revoke it. This seems straightforward but raises questions:

• Can issuers revoke arbitrarily, or must they show cause?

• Are holders entitled to notice and opportunity to respond?

• Can holders appeal to a third party?

Third-party revocation: Sometimes entities other than the issuer need revocation authority:

• Courts might order credential suspension

• Regulators might mandate revocation for compliance violations

• Professional bodies might revoke based on misconduct findings

This requires schema-level support for delegated revocation authority—and raises questions about jurisdiction and conflicts.

Mutual revocation: In peer-to-peer contexts, both parties might have revocation rights:

• An employment credential could be revocable by either employer or employee

• A business relationship credential might require mutual agreement to remain valid

Automated revocation: Some credentials should automatically revoke under conditions:

• Time-based expiration

• Dependency failure (underlying credential revoked)

• Condition violation (failed audit, missing payment)

The critical principle: revocation authority must be specified in the credential itself, not left implicit. Holders and verifiers must know who can revoke, under what conditions, and with what recourse.

Silent revocation is abuse. Arbitrary revocation is capricious. Opaque revocation is exclusion. Portable eligibility without fair revocation is digital authoritarianism.

Trust Frameworks: Explicit Rather Than Assumed

One of the hardest problems in portable eligibility: how do verifiers decide which issuers to trust?

Traditional systems solve this through platform mediation. The platform vets issuers, establishes relationships, and enforces standards. Verifiers trust the platform’s judgment.

Portable eligibility externalizes this. Verifiers must decide directly which issuers they accept. This creates discovery and evaluation costs that threaten to undermine portability benefits.

Trust frameworks provide structure:

Definition: A trust framework is a policy document that specifies:

• Which types of credentials are covered

• Which issuers are accredited

• What assurance levels apply

• What obligations issuers have

• How disputes are resolved

• How the framework itself is governed

Example: An industry consortium publishes a trust framework for supply chain sustainability credentials. It specifies:

• Recognized certification bodies for ISO 14001

• Accepted carbon accounting methodologies

• Required audit frequencies

• Revocation timelines

• Insurance requirements for issuers

• Governance board composition

Companies participating in the consortium agree to accept credentials issued under this framework. This reduces the verifier’s decision from “should I trust this specific issuer?” to “should I trust this framework?”—a more tractable question.

Layering: Trust frameworks can reference other frameworks:

• A regional supply chain framework might accept credentials issued under a global sustainability framework

• A national healthcare framework might recognize state-level licensing frameworks

• A high-assurance financial framework might accept medium-assurance commercial frameworks with additional checks

This creates a lattice rather than a hierarchy - multiple paths to trust rather than a single authority.

Governance: Who maintains trust frameworks? Different models:

• Industry consortiums: Competitors agreeing on minimum standards

• Government agencies: Mandated frameworks for regulated activities

• Multi-stakeholder bodies: Balanced representation of issuers, verifiers, and public interest

• Open communities: Voluntary adoption based on reputation

No single model dominates. Different sectors will adopt different approaches based on existing power structures and regulatory context.

The key requirement: trust frameworks must be machine-readable and referenced in credentials. A credential should carry metadata indicating which frameworks it was issued under. Verifiers should be able to automatically check whether they accept those frameworks.

The Bootstrap Problem: Who Moves First and Why

Portable eligibility faces a chicken-and-egg problem: verifiers won’t accept credentials until many holders have them, and issuers won’t issue credentials until verifiers accept them.

Breaking this cycle requires identifying contexts where portability benefits are immediate even with partial adoption:

High-frequency reverification: Where actors must repeatedly prove the same eligibility to the same or similar verifiers, even small amounts of portability reduce costs. Supply chain compliance is a prime example—suppliers prove the same certifications to multiple buyers monthly or quarterly.

Regulated data sharing: Where regulations require data sharing (insurance portability, medical records, financial data under open banking mandates), portable eligibility provides a superior mechanism to bespoke APIs.

New market formation: When new platforms or markets are forming, adopting portable eligibility from the start avoids legacy system constraints. Carbon credit markets, green supply chain networks, and pandemic-era health credentialing all benefit from starting with portability.

Government procurement: Public sector buyers can mandate portable eligibility for vendor management, instantly creating verifier demand that drives issuer adoption.

Federation of existing systems: Where multiple platforms already interoperate via proprietary means, portable eligibility reduces integration costs. The value proposition is efficiency, not net-new capabilities.

The pattern: start where friction costs are highest, switching costs are apparent, and a coordinating entity can drive adoption. Scale to where network effects take over.

The Political Economy Cannot Be Wished Away

At this point, pretending portable eligibility is purely technical becomes untenable.

Every design choice embeds assumptions about power:

• Who controls registries controls vocabulary

• Who sets conformance rules controls market entry

• Who governs trust frameworks controls legitimacy

• Who operates status infrastructure controls availability

These are not abstract concerns. They determine:

• Whether small issuers can compete with large ones

• Whether new verifiers can enter markets or face integration barriers

• Whether actors from different jurisdictions can interoperate

• Whether individuals can contest decisions or must accept them

Portable eligibility redistributes leverage. It reduces platforms’ ability to trap participants through proprietary eligibility logic. It exposes criteria that were previously opaque. It creates pressure for standards that incumbents might prefer to avoid.

This is why resistance is rarely frontal. Instead:

• Standards are adopted without binding conformance

• Registries are created with governance that favors incumbents

• Credentials are issued with schema ambiguity that requires interpretation

• Status checking is optional rather than mandatory

• Lifecycle infrastructure is deferred as “implementation detail”

The result: portability in name, captivity in fact.

Countering this requires recognizing that technical excellence is necessary but insufficient. Adoption depends on:

• Regulatory pressure: Mandates for eligibility portability in specific sectors

• Procurement power: Large buyers requiring portable credentials from suppliers

• Coalition formation: Groups of actors jointly adopting standards to reduce switching costs

• Public infrastructure: Government systems modeling good behavior and creating gravitational pull

Markets rarely self-correct when lock-in is profitable. Change requires either aligned incentives or applied pressure.

Part 3 — Agency, Automation, and Accountability at Scale

When Software Acts on Your Behalf

Portable eligibility doesn’t mature in a world where humans manually present credentials. It matures where software agents act continuously on behalf of people, organizations, and systems.

This is not speculative. It already describes:

• Algorithmic trading systems executing on market authority

• Supply chain software negotiating contracts based on compliance status

• Content distribution systems routing based on monetization eligibility

• API gateways making access decisions in microseconds

When agents act, eligibility becomes continuous rather than episodic. Decisions happen at machine speed based on real-time status, risk signals, and policy constraints. In this environment, eligibility that isn’t portable becomes unusable—no agent can afford to renegotiate access for every action.

This is the real inflection point. Eligibility must be legible not just across human contexts, but across automated decision systems that were never designed to trust each other.

Without portable eligibility, delegation defaults to platform capture. Agents can act only within closed ecosystems where eligibility logic is internal and irrevocable by users. With portable eligibility, delegation becomes conditional, scoped, and reversible.

Example: A procurement agent acting on behalf of a buyer.

Without portability: The agent operates within a single platform’s vendor network. It can only evaluate vendors the platform has vetted. It uses the platform’s compliance data, which may be stale. To work with vendors outside the platform, humans must intervene. The platform intermediates every decision and can unilaterally change rules.

With portability: The agent holds authority scoped to procurement actions under defined constraints (budget limits, compliance requirements, approval thresholds). When evaluating vendors, it requests relevant credentials directly: sustainability certifications, financial stability indicators, delivery performance. It verifies these against trusted registries, checking real-time status. It can work with any vendor presenting valid credentials, not just platform members. The buyer can revoke or modify the agent’s authority at any time.

The difference is not just efficiency. It’s about who controls the eligibility logic that governs participation.

Delegation as Time-Extended Eligibility

Delegation is often framed as authorization: granting permission to act. This is incomplete.

Authorization is point-in-time: can this action happen now? Delegation is temporal: can actions happen repeatedly, under changing conditions, without continuous oversight?

Delegation is eligibility projected forward in time.

When a CFO delegates expense approval authority to a manager, they’re not granting unlimited power. They’re granting eligibility to approve expenses under constraints: budget limits, category restrictions, approval thresholds, time boundaries. These constraints must be machine-readable if the delegation is to be enforced by systems rather than social norms.

Portable eligibility provides the substrate for this. An agent doesn’t need to impersonate a user or embed deeply into platform-specific permission models. It needs to carry proof that it’s eligible to perform specific actions, for specific purposes, within specific windows, on behalf of specific principals.

Consider three delegation patterns:

Scoped delegation: A logistics agent is authorized to book shipments under $10,000 with carriers holding valid insurance and safety certifications. The agent presents its authority credential when requesting quotes. Carriers verify the credential and check that their own credentials meet the stated requirements. Transactions proceed automatically within bounds.

Conditional delegation: A payment agent is authorized to make vendor payments only after receiving proof that goods were delivered and inspected. The agent waits for a delivery credential from the logistics agent and an inspection credential from the quality agent before processing payment. All three credentials compose to satisfy payment eligibility.

Revocable delegation: A marketing agent is authorized to place advertising with approved platforms. Midway through a campaign, legal raises concerns about a platform’s data practices. The marketing team revokes the agent’s authority for that specific platform. The agent’s credential updates immediately, and no new ads are placed there—without requiring code changes or platform coordination.

Each pattern requires portable eligibility. Without it, delegation becomes either rigid (hard-coded rules that can’t adapt) or centralized (all decisions flow through platforms that intermediate).

Why Wallets Matter (But Aren’t the Story)

Wallets receive disproportionate attention in identity discussions. They’re important, but they’re interfaces, not infrastructure.

A wallet’s job in portable eligibility is coordination, not storage. It must:

• Hold eligibility tokens across contexts

• Compose credentials to satisfy complex requirements

• Present selective disclosures (prove age without revealing birthdate)

• Manage delegation (issue sub-credentials to agents)

• Track status and prompt renewal

• Revoke compromised credentials

Most current wallets weren’t designed for this. They optimize for collecting and presenting credentials, not for governance and composition.

The critical evolution is from “credential holder” to “eligibility manager.” This means:

Composition logic: When a verifier requests proof of “authorized vehicle operator with hazmat endorsement and current medical certification,” the wallet must identify which credentials satisfy each requirement and present them together—potentially from different issuers with different schemas.

Risk surface: The wallet must help users understand what they’re proving and to whom. “This request asks for: commercial driving authorization (required), employer history (optional but affects pricing), home address (not required, consider declining).”

Delegation chains: When a user delegates to an agent, the wallet issues a derived credential with explicit constraints. When the agent attempts to act, verifiers can trace the delegation chain back to the principal and verify each link remains valid.

Lifecycle awareness: The wallet monitors expiration dates, watches status registries, and alerts users when credentials need renewal or have been revoked. It doesn’t wait for failures; it prevents them.

This is infrastructure work—unglamorous but essential. Wallets that do this well enable portable eligibility. Wallets that focus only on presentation enable portability theater.

From Identity Silos to Eligibility Graphs

As eligibility becomes portable and composable, something interesting happens: the organizing structure shifts from monolithic identity profiles to distributed eligibility graphs.

An eligibility graph is the emergent structure formed by the relationships between credentials, issuers, verifiers, and trust frameworks. It’s not designed centrally. It’s not stored in one place. It exists as the sum of all eligibility relationships.

Consider how this differs from current identity systems:

Platform identity model: A user has a profile containing all their attributes and history. The platform owns the profile. Access to information flows through the platform. The platform intermediates all relationships.

Eligibility graph model: A user holds multiple credentials from different issuers. Each credential makes specific claims. Verifiers accept credentials based on trust frameworks. Relationships exist directly between participants. No single party sees the whole picture.

This shift has significant implications:

Power diffusion: No single entity controls the entire graph. Issuers can’t see where credentials are used. Verifiers can’t see what other credentials holders have. Holders can’t be profiled through a single chokepoint.

Selective participation: Actors can operate in some parts of the graph without revealing participation in others. A professional might use credentials with employers that are separate from credentials used with clients.

Emergent trust patterns: Trust propagates through the graph based on actual usage and credential composition, not just declared relationships. If many verifiers accept credentials from an issuer under a specific trust framework, that creates a trust signal visible to other participants.

Transparency through aggregation: While individual relationships remain private, aggregate patterns become visible. How many credentials of type X are issued monthly? What percentage are revoked within 90 days? Which trust frameworks are most widely adopted? This population-level data enables market intelligence without surveillance.

Eligibility graphs also expose asymmetries. They make visible where access is denied, where criteria diverge, where revocation patterns differ. This visibility creates pressure for justification and enables contestation.

Markets that fear scrutiny resist eligibility graphs. Markets that compete on value benefit from them.

Redress When Decisions Happen at Machine Speed

One of the most underdeveloped aspects of automated systems is redress. Decisions are instantaneous. Consequences are immediate. Appeals are slow or nonexistent.

This asymmetry is tolerable only because we’ve normalized it. As automation increases, the asymmetry becomes untenable.

Portable eligibility creates the substrate for machine-speed redress:

Explainable decisions: Because eligibility logic is externalized, decisions become explicable. A loan denial isn’t “the algorithm said no”—it’s “your credit credential status check failed” or “your income credential didn’t meet the threshold” or “the required compliance credential wasn’t presented.”

Contestable inputs: If a credential is revoked erroneously, the holder can challenge the issuer directly rather than appealing to every verifier. Once the issuer corrects the status, all verifiers see the update automatically.

Auditable flows: Because credentials are portable and status is checkable, decisions can be reconstructed. What credentials were presented? What was their status at decision time? What criteria were applied? This makes automated decisions auditable even when made by independent systems.

Graduated remedies: Different errors call for different responses:

• Technical failure (status registry unreachable): Retry or fallback verification

• Stale status (cached credential expired): Re-verify and retry

• Incorrect credential (issuer error): Holder contacts issuer for correction

• Incorrect criteria (verifier error): Holder escalates to framework governance

Each remedy operates at a different level, but all require eligibility to be portable and status to be explicit.

Consider two scenarios:

Scenario A - Opaque denial: An insurance application is denied. The reason given: “unable to meet eligibility requirements.” The applicant doesn’t know which requirement failed or why. They must reapply from scratch or abandon the attempt.

Scenario B - Explicit denial: An insurance application is denied because the driver license credential status check returned “suspended.” The applicant is surprised—they know their license is valid. They check the status registry directly and see the suspension, but it’s dated incorrectly. They contact the RTO/DMV with specific evidence. The RTO/DMV corrects the error within hours. The status registry updates. The applicant reapplies and is approved automatically.

The second scenario isn’t just better for the applicant. It’s better for the system. Errors are corrected faster. False negatives decrease. Trust in automation increases.

Redress without explainability is theater. Explainability without portable eligibility is impossible.

The Governance Challenge That Never Ends

Portable eligibility requires ongoing governance, not just initial design. As markets evolve, schemas must adapt, trust frameworks must update, and conformance requirements must change.

This creates permanent governance demands:

Schema evolution: New credential types emerge. Existing types need new attributes. Deprecated fields must be sunsetted without breaking existing credentials. Who decides when schemas change? How are changes communicated? What backward compatibility is maintained?

Trust framework maintenance: Issuers join and leave frameworks. Framework requirements evolve. Conflicts arise between frameworks. Who resolves disputes? How are frameworks audited? When can frameworks be deprecated?

Conformance enforcement: Some implementers cut corners. Others extend standards in incompatible ways. Interoperability degrades. Who monitors conformance? How are violations addressed? What sanctions are available?

Status infrastructure reliability: Status registries become critical infrastructure. Downtime cascades. Performance degrades. Attacks occur. Who operates critical registries? How is reliability ensured? How are failures handled?

Different sectors will answer these questions differently. Some will form industry consortiums. Others will rely on government oversight. Others will use open community processes. There’s no universal answer.

What matters is making governance explicit rather than implicit. Hidden governance leads to capture. Explicit governance creates accountability.

The most difficult governance questions involve power allocation:

• When frameworks conflict, who decides precedence?

• When issuers violate trust requirements, who can revoke their accreditation?

• When schemas need breaking changes, who can force adoption?

• When registries fail, who is liable?

These aren’t technical questions. They’re political economy questions that require institutions, not just protocols.

The Limits of Self-Regulation and Market Forces

A persistent hope: markets will adopt portable eligibility voluntarily because it’s more efficient.

History suggests skepticism. Markets adopt portability when forced by competition, regulation, or coordination.

Why self-regulation fails: Platforms that benefit from proprietary eligibility have no incentive to externalize it. They’ll adopt the language of portability (”we support standards!”) while preserving control (”but our implementation needs these platform-specific extensions”).

This isn’t malice. It’s rational behavior. Lock-in is valuable. Switching costs protect margins. Interoperability reduces differentiation.

Self-regulation works only when:

• Coordination costs exceed lock-in benefits (small markets, high friction)

• Switching costs harm growth (new markets needing liquidity)

• Reputation matters more than immediate profit (professional services, B2B)

For large platforms with network effects, these conditions rarely hold.

Regulation as coordination mechanism: Regulation doesn’t need to dictate architecture. It needs to create conditions where portability becomes rational:

• Procurement standards: Government buyers require portable credentials from vendors, creating market demand

• Liability frameworks: Organizations are liable for eligibility decisions; portable credentials with clear status reduce liability

• Interoperability mandates: Platforms above size thresholds must accept credentials from accredited issuers under registered frameworks

• Exit rights: Users have statutory right to export eligibility in portable formats

These don’t specify technical implementations. They specify outcomes—and let markets figure out how to achieve them.

Coalition formation: Where regulation is absent or slow, coordinated adoption by buyer coalitions can force change. If the top 50 manufacturers jointly require suppliers to present portable sustainability credentials, the market adapts. Individual buyers can’t justify switching costs, but coalitions can.

The pattern: portability happens through leverage, not persuasion.

Public Infrastructure as the Gravitational Center

Public systems such as government services, regulated utilities, civic infrastructure have a unique role.

Not because they’re more virtuous, but because they operate at scale and cannot sustain infinite bespoke integration.

When public services adopt portable eligibility, they create gravitational pull:

• Private actors adapt to reuse public credentials rather than forcing re-verification

• Standards solidify around what public systems accept

• Registries stabilize because public systems depend on them

• Wallet adoption accelerates because public credentials make them useful immediately

Examples across contexts:

Professional licensing: State licensing boards issue portable credentials for healthcare providers, lawyers, contractors. Verification becomes instant and reliable. Insurance companies, employers, and professional networks reuse these credentials rather than building proprietary verification. Private sector builds on public foundation.

Business registration: Business credentials include incorporation status, tax compliance, regulatory authorizations. Banks, suppliers, and partners verify businesses through portable credentials rather than duplicate verification systems. Company formation and operation become faster and cheaper.

Educational credentials: Universities issue portable academic credentials. Employers, graduate schools, and professional bodies accept them directly. Background verification companies become less necessary. Student mobility increases.

Benefit eligibility: Social service agencies issue portable eligibility credentials for housing assistance, childcare subsidies, food support. Service providers verify eligibility instantly. Clients maintain dignity by not repeatedly proving need. Administrative costs decrease.

The pattern: public infrastructure that insists on portable eligibility doesn’t crowd out innovation. It lowers the cost of market participation.

This is where government can be most effective—not regulating private behavior, but modeling good behavior at sufficient scale that markets adapt.

What Failure Looks Like (And How to Recognize It)

Portable eligibility doesn’t fail loudly with system crashes. It fails quietly through non-adoption or superficial compliance.

Failure mode 1: Credential issuance without reuse Credentials are issued following standards. Wallets hold them. But verifiers don’t accept them—they continue using proprietary verification. The credentials become decorative.

Failure mode 2: Registries without governance Schema and trust registries exist but aren’t maintained. Schemas drift. Dead issuers remain listed. Status endpoints fail. Verifiers lose confidence and revert to direct verification.

Failure mode 3: Standards without conformance Systems claim compliance with portable eligibility standards but interpret them loosely. Interoperability exists only within like-minded implementers. The ecosystem fragments.

Failure mode 4: Lifecycle theater Revocation mechanisms exist but are slow or unreliable. Verifiers compensate by caching minimally and re-verifying constantly. Portability provides no efficiency gain.

Failure mode 5: Exit theater Users can export credentials, but they’re not accepted elsewhere. “Portability” exists as a compliance checkbox without enabling actual movement.

The most dangerous failure: systems that claim portable eligibility but preserve lock-in through subtle mechanisms. This is worse than no portability because it creates false confidence and delays real solutions.

How to recognize genuine portability:

• Can credentials issued in context A be verified in context B without bilateral integration?

• Can status changes propagate to all verifiers within SLA timeframes?

• Can holders demonstrate eligibility without platform intermediation?

• Does exit cost roughly the same as entry?

If any answer is no, portability is incomplete.

The Composition Horizon: What Becomes Possible

When eligibility becomes truly portable and composable, new market behaviors emerge that aren’t possible in siloed systems.

Multi-party workflows without centralization: A construction project requires proof that the contractor is licensed, insured, bonded, and has safety training current—and the same for all subcontractors. With portable eligibility, the general contractor presents their credentials, subcontractors present theirs, and the property owner verifies all automatically against trust frameworks they specify. No central platform intermediates.

Real-time risk assessment across contexts: An insurance company assesses risk for a fleet operator by verifying driver credentials, vehicle maintenance records, safety training, and route compliance—each from different issuers. As status changes (a driver loses their license, a vehicle fails inspection), risk models update automatically. Insurance pricing becomes continuous rather than annual.

Programmable compliance: Regulatory requirements are expressed as composable eligibility requirements. Companies prove compliance by presenting relevant credentials. Auditors verify credentials rather than reviewing documentation. Compliance becomes faster and cheaper. Regulators can require more frequent attestations without increasing burden.

Marketplace liquidity: A carbon credit marketplace requires that sellers prove project certification, validation body accreditation, and registry participation. Buyers specify trust frameworks they accept. Trades happen automatically when eligibility is proven. No platform owns the relationship between buyers and sellers.

Delegated authority with accountability: An organization grants its procurement agents eligibility to order from suppliers meeting specific criteria. Agents act autonomously within bounds. When agents exceed authority, the breach is immediately detectable because eligibility is explicit. Delegation scales without losing control.

These aren’t hypothetical futures. They’re already happening in limited contexts. Portable eligibility is what allows them to scale and generalize.

The Real Choice We’re Making

Portable eligibility is often framed as an efficiency upgrade around the themese of reducing friction, lowering costs, improving interoperability. This understates what’s actually at stake.

We’re choosing what kind of markets we want:

Markets built on captivity: Access is conditional on staying within platforms that control eligibility logic. Exit is expensive. Switching requires starting over. Power accumulates to those who control the gates. Innovation requires permission.

Markets built on composability: Access is proven through portable credentials. Exit is straightforward. Switching preserves accumulated eligibility. Power is distributed among issuers, verifiers, and holders. Innovation happens at the edges.

The technology to support the second exists. The primitives are known:

• Verifiable credentials for portable claims

• Decentralized identifiers for non-correlatable references

• Status registries for real-time lifecycle management

• Trust frameworks for coordinated acceptance

• Conformance testing for reliable interoperability

What remains is will and coordination:

• Will to separate meaning from control

• Will to make criteria explicit

• Will to allow exit

• Will to govern infrastructure transparently

• Coordination to bootstrap adoption where benefits are highest

• Coordination to maintain standards as markets evolve

• Coordination to enforce conformance without stifling innovation

This is not a neutral technical decision. It redistributes power from platforms to participants. It makes visible what was opaque. It makes contestable what was imposed.

Some actors will resist. Others will benefit enormously. The difference depends on whether their value comes from providing superior service or from making exit difficult.

Eligibility as Civic Infrastructure

As we close, it’s worth returning to first principles.

Identity told us who we were. Eligibility decides what we can do.

As more of life is mediated by systems that make continuous eligibility decisions—who can access credit, housing, employment, platforms, services, mobility—the architecture of those decisions becomes foundational.

If eligibility is trapped in proprietary systems, participation requires submission. Actors must accept whatever criteria platforms impose, whatever processes they require, whatever terms they set. There is no alternative.

If eligibility is portable, participation becomes negotiable. Actors can prove capability without surrender. They can move when platforms become extractive. They can contest when criteria seem arbitrary.

Portable eligibility doesn’t solve all problems. It doesn’t guarantee fair criteria. It doesn’t eliminate bias. It doesn’t ensure access.

But it creates the conditions where these problems can be addressed:

• Criteria become visible and thus arguable

• Decisions become explicable and thus contestable

• Exit becomes possible and thus power becomes disciplined

This is infrastructure work. It’s not glamorous. It requires coordination, maintenance, and governance. It demands both technical excellence and political sophistication.

But it determines whether digital markets serve participants or capture them.

That choice is being made right now, in schema design decisions, registry governance models, conformance requirements, and adoption strategies.

The only question is who gets to make it—and whether they understand what’s at stake.