Architecting Multimodal Self: Identity as an Adaptive Protocol Stack

Identity systems today are brittle. They treat the user as a flat record: a username, an email, maybe a role. But each of us is multimodal—we present different facets to different contexts: a professional credential at work, a privacy-preserving alias on a forum, a verifiable age claim at a digital storefront. What we need is not a larger profile but a protocol that adapts, negotiating which attributes to reveal, when, and to whom. This is identity as an adaptive protocol stack.

Who needs this and what goes wrong without it

This architecture is for teams building cross-platform authentication systems where the same user moves between a mobile app, a web dashboard, an IoT device, and a third-party service—each with different trust requirements. It is also for architects designing consent management for data-sharing ecosystems, and for anyone working with verifiable credentials who has hit the wall of static attribute bundles.

Without an adaptive stack, common failures emerge. First, attribute bloat: a system collects more data than the current interaction requires because it cannot negotiate subsets. The user logs into a low-risk forum with their full government ID—unnecessary exposure. Second, scope creep: once a credential is issued, it is reused in contexts the issuer never intended. A university email used for years after graduation is a classic example. Third, consent drift: the user agrees to data sharing for one purpose, but the system later uses that data for analytics without re-negotiation. These are not just UX problems; they are security and compliance risks.

We have seen teams try to solve this with monolithic identity providers that try to be all things to all contexts. The result is a tangled mess of custom scopes, conditional claims, and session hacks. The adaptive protocol stack offers a cleaner separation—each layer handles one concern, and the stack renegotiates per interaction.

Prerequisites / context readers should settle first

Before diving into the stack, readers should be comfortable with OAuth2 and OpenID Connect flows, particularly authorization code grant and token exchange. Understanding verifiable credentials (W3C VC standard) and decentralized identifiers (DIDs) is helpful, though not required—we will reference them as examples. A working knowledge of zero-trust principles (never trust, always verify) and policy-as-code engines like Open Policy Agent (OPA) or Cedar will make the policy layer section more concrete.

We assume you have encountered the identity silo problem: a user has separate profiles for work, home, and healthcare, and there is no coherent way to bridge them without either leaking data or creating a single point of failure. The adaptive protocol stack is not a silver bullet, but it provides a framework for designing bridges that respect boundaries.

One common misconception: this is not about building a universal identity system. It is about building a system that can adapt to the identity system of the moment. The stack must handle multiple trust roots—some centralized, some federated, some self-sovereign.

Foundational concepts

Three ideas underpin the stack: layering (each layer has a distinct responsibility), negotiation (the layers communicate to agree on what to present), and context-awareness (the stack adapts based on the relying party, the device, the jurisdiction, and the user's current intent).

Core workflow: the adaptive protocol stack in action

The stack has four layers: Source Layer, Semantic Layer, Policy Layer, and Presentation Layer. They work together per interaction. Here is the flow for a typical scenario: a user wants to prove they are over 21 to enter a digital age-restricted store.

Layer 1: Source Layer

This layer holds raw identity claims from authoritative issuers: a government-issued ID, a driver's license, a birth certificate. These are stored in a secure wallet (device-local or cloud-based with strong encryption). The source layer does not interpret or transform; it just stores and exposes claims upon request. In our example, the wallet contains a verifiable credential from the DMV with the user's date of birth.

Layer 2: Semantic Layer

The semantic layer maps raw claims to abstract predicates. It knows that the date-of-birth field can be used to derive an "over 21" boolean. It also handles units, formats, and language. This layer is where translation happens: a university credential might map to "alumni status" in one context and "student discount eligibility" in another. For the age gate, the semantic layer produces a derived claim: ageOver21 = true.

Layer 3: Policy Layer

The policy layer evaluates whether the derived claim should be released given the context. It checks: Is the relying party authorized to request this claim? Does the user's consent policy allow release for this purpose? What is the jurisdiction (e.g., GDPR requires minimal disclosure)? The policy engine might be OPA with rules like: allow if request.purpose == 'age_verification' and user.consent.age_verification == true. If the policy denies, the stack stops here and returns a rejection to the relying party.

Layer 4: Presentation Layer

This layer formats the response for the relying party. It may produce a zero-knowledge proof (e.g., a BBS+ signature that reveals only the over-21 predicate without the actual birth date) or a simple signed assertion. The presentation layer also handles transport—whether via HTTP headers, a QR code, or a verifiable presentation in a JWT.

The negotiation happens across layers: the presentation layer can ask the policy layer for alternative claims if the first request is denied. The policy layer may consult the semantic layer for additional derivations. This back-and-forth is what makes the stack adaptive, not just a pipeline.

Tools, setup, and environment realities

Implementing the stack requires a mix of standards and runtimes. For identifiers, did:key is lightweight for prototyping; did:web works well for organizations that already control a domain. Verifiable credentials should follow the W3C VC 1.1 or 2.0 spec; choose a signature suite that supports selective disclosure (e.g., BBS+ with ECDSA). For the policy layer, OPA is a solid choice because it is language-agnostic and supports fine-grained attribute-based access control. If you are in the AWS ecosystem, Cedar is a viable alternative with native integration.

The environment matters: on mobile, the source layer often lives in a secure enclave (e.g., iOS Secure Enclave, Android TEE). On the server side, you might use a hardware security module (HSM) to store private keys. The semantic and policy layers can run as sidecar containers or Lambda functions to keep them isolated.

One practical setup: use a wallet SDK (such as those from the Aries framework or the OpenWallet Foundation) for the source and presentation layers, and OPA as a sidecar for policy. The semantic layer can be a simple microservice with a mapping table. For a proof of concept, you can skip the HSM and use software keys with proper access controls.

Trade-offs in tool selection

Variations for different constraints

The stack is modular; you can swap layers based on constraints. For offline-first environments (e.g., a field worker's device with intermittent connectivity), the source layer must cache credentials locally, and the policy layer must include a local cache of consent decisions. The presentation layer can create verifiable presentations offline and send them when connectivity returns.

For high-assurance government use, the source layer must use hardware-backed credentials (e.g., PIV cards), the semantic layer must enforce strict attribute derivation rules (no inference beyond what is explicitly allowed), and the policy layer must log every decision for audit. The presentation layer may require qualified electronic signatures (eIDAS level).

For privacy-preserving mobile scenarios, the semantic layer can produce zero-knowledge proofs instead of raw attributes. The policy layer must support selective disclosure—allow the user to reject specific claims. The presentation layer should minimize data sent; for example, use a BBS+ proof that only reveals the minimum age, not the birth date.

Another variation: cross-organizational trust. If two companies want to share employee attributes, each runs their own stack but with a federated policy layer that uses a shared trust framework. The semantic layers map attributes to a common ontology (e.g., schema.org/Person).

Pitfalls, debugging, and what to check when it fails

Even with a clean design, the stack can fail in subtle ways. Here are the most common issues and how to diagnose them.

Session drift across layers

The source layer issues a credential with a certain validity, but the policy layer evaluates later and the credential has expired. The presentation layer might include a stale proof. Fix: ensure each layer has access to a common clock or a mechanism to check freshness. Use short-lived credentials and require re-issuance for long sessions.

Policy conflicts

Two policies may contradict: one says "allow age verification for any relying party," another says "deny for relying parties in jurisdiction X." The policy engine must have a conflict resolution strategy—usually deny-overrides or most-specific-wins. Debug: log the full set of policies evaluated and the decision trace. Use OPA's built-in tracing to see which rule fired.

Credential revocation gaps

A credential is revoked at the source, but the semantic and policy layers do not check revocation status because the wallet did not provide an update. Fix: include a status list reference in the credential (e.g., a BitstringStatusList) and have the policy layer check it. If revocation is not possible, the stack should treat credentials as short-lived.

Semantic mismatch

The relying party expects a claim in a certain format (e.g., "birthDate" as ISO 8601), but the semantic layer outputs a different format. Fix: define a clear contract between the semantic and presentation layers. Use a schema registry (like JSON Schema) to validate inputs and outputs.

When debugging, start at the presentation layer and work backwards: what did the relying party receive? Then check the policy decision, the semantic derivation, and finally the source credential. Most failures are in the policy layer because rules are misconfigured or missing.

Frequently asked questions and checklist

FAQ

Do we need all four layers for every system? No. Start with source and presentation, add semantic if you need attribute derivation, and add policy if you have multiple contexts or compliance requirements. Many systems work fine with three layers.

How does the stack handle user consent? Consent is stored as a policy rule in the policy layer. The user can modify their consent policies through a management interface. The stack never releases claims without a matching consent rule.

Is this compatible with existing OAuth2/OIDC? Yes. The presentation layer can produce an ID token or access token that contains the derived claims. The stack acts as a claims source for the token endpoint.

Checklist for implementation

• Define the trust root for each source credential (who is the issuer?).
• Map each attribute to a semantic predicate and decide on derivation rules.
• Write policy rules for each context (purpose, relying party, jurisdiction).
• Choose a credential format and signature suite (e.g., JWT-VC with BBS+).
• Implement revocation checking (status list or short-lived credentials).
• Test with at least three distinct relying party scenarios.
• Log every layer decision for audit and debugging.

What to do next

Start by mapping your current identity flow to the four layers. Identify where attributes are over-collected or under-negotiated. Then prototype a minimal stack for one interaction: a user proving a single claim (e.g., email ownership) to a single relying party. Use did:key for the identifier, a simple JSON-LD credential for the claim, and a small OPA policy that checks the relying party's domain.

Once that works, add a second context: the same user proving a different claim to a different party. See how the stack renegotiates. Then introduce a policy conflict and observe how your resolution strategy works. Finally, consider integrating with your existing OAuth2/OIDC infrastructure by writing a custom claims provider that calls the stack.

This is not a one-time architecture; it evolves as trust models and privacy regulations change. The adaptive protocol stack gives you a framework to adapt without rebuilding from scratch. Your next step is to pick one use case and build the thinnest possible version today.