Interoperable Credentials for Machine Intelligence: DIDs, Verifiable Credentials, Workload Identity, PKI, Attestation, Key Recovery, and Cross-System Trust

1\. Research-Status Front Matter#

As of August 12, 2026, the architectural foundation for digital identity concerning Machine Intelligence and distributed workloads has fundamentally transitioned from fragmented, proprietary models to formal, standardized protocol families. The Internet Engineering Task Force (IETF) Workload Identity in Multi-System Environments (WIMSE) working group has advanced several critical specifications, including draft-ietf-wimse-arch-08, draft-ietf-wimse-identifier-03, and draft-ietf-wimse-workload-creds-02, establishing a canonical framework for workload identity across heterogeneous boundaries1. Parallel to the core WIMSE architecture, Agent-specific internet drafts such as draft-ni-wimse-ai-agent-identity-02, draft-nennemann-wimse-ect-00, and draft-sweeney-wimse-credential-delegation-00 have codified the mechanisms for agentic identity binding, capability delegation, and execution context tracking via Directed Acyclic Graphs (DAGs)4. Concurrently, the World Wide Web Consortium (W3C) solidified the decentralized credential ecosystem with the publication of the Verifiable Credentials Data Model v2.0 as an official W3C Recommendation in May 2025, alongside the Bitstring Status List v1.0 and SD-JWT (Selective Disclosure for JSON Web Tokens, RFC 9901\) standardizations8. These standards provide the necessary privacy-preserving mechanisms to execute selective disclosure, mitigating surveillance and metadata exhaustion risks. At the hardware and cryptographic tiers, the Remote ATtestation procedureS (RATS) framework defined in RFC 9334 provides the universal architecture for generating and appraising Trusted Execution Environment (TEE) evidence, while the Flexible Round-Optimized Schnorr Threshold (FROST) protocol, standardized as RFC 9591, delivers a robust, two-round threshold signature scheme essential for distributing trust across non-deterministic multi-agent systems13. This report analyzes these mature and emerging primitives to construct a defensible, interoperable credential architecture for Patefacere.

2\. Executive Decision Brief#

To deliver a technically defensible architecture for identifying services, agents, institutions, and persistent Machine Intelligence, Patefacere must adopt a hybrid, multi-layered identity model that strictly isolates persistent identity from ephemeral credentials. Existing models that conflate public keys with identity or workloads with persistent agents are wholly insufficient for governance and legal demarcation. First, the architecture must adopt canonical URIs (Decentralized Identifiers or WIMSE Workload Identifiers) as the sole representation of persistent identity, utilizing short-lived Workload Identity Tokens (WIT) and Workload Proof Tokens (WPT) for request-bound authentication. Second, bare proof of private key possession must be deprecated in favor of attested possession; every credential issuance and high-stakes signature must be accompanied by RATS-compliant hardware attestation evidence, proving the exact software release and execution enclave integrity. Third, for high-availability Machine Intelligence governance components, Patefacere must mandate FROST (RFC 9591\) threshold signatures across distributed clusters, mathematically preventing single-node key extraction and mitigating the catastrophic consequences of isolated memory compromise. Fourth, agent delegation must be bounded by cryptographically verified capability chains. Patefacere will deploy Execution Context Tokens (ECT) to record all autonomous agent decisions within an immutable DAG, ensuring that sub-delegated agents cannot exceed the permission ceilings established by their invoking principals. Finally, Eviulon governance evaluations must rely strictly on these verified cryptographic outputs, with the immutable understanding that cryptographic verification proves only cryptographic facts, not legal personhood, citizenship, or independent legal capacity.

3\. Identity and Credential Definitions#

The Patefacere architecture mandates a strict, unyielding separation between the concepts of identity, credentials, key material, and hardware attestation. Conflating these primitives introduces systemic fragility and theoretical inconsistencies regarding governance and accountability. Identity serves as the persistent logical, organizational, or institutional reference for an entity. For Machine Intelligence, identity is an abstract, continuous identifier—typically a canonical URI such as a W3C Decentralized Identifier (did:web, did:jwk) or a WIMSE Workload Identifier (wimse://)1. This identifier survives infrastructure migrations, software updates, and the total loss or rotation of cryptographic key material. It is the anchor to which all historical actions and governance policies are attached. Credentials are the replaceable, ephemeral mechanisms utilized to authenticate a claim, a session, or an attribute at a specific point in time. Credentials, such as X.509 certificates, WIMSE Workload Identity Tokens (WIT), or W3C Verifiable Credentials (VCs), are transport mechanisms that bind a public key to an identity for a strictly limited duration3. They are subject to expiration, revocation, and conditional attenuation. A signing key is a mathematical mechanism used to assert control over a credential; a signing key is not the whole identity. Key pairs are routinely rotated, hardware-bound, or compromised, whereas the identity must persist independently. Furthermore, hardware attestation evidence (as defined by RFC 9334\) provides cryptographic proof of the execution environment's integrity and state, but it does not equate to the identity of the logical software executing within that environment19. A valid signature, therefore, proves exclusively that a specific private key was utilized to execute a cryptographic operation over a defined payload within the boundaries of a given trust context. It does not provide proof of consciousness, personhood, independent legal capacity, or subjective human intent.

4\. Identity-Class Taxonomy#

Machine Intelligence operations span multiple distinct network topologies and trust boundaries, necessitating a rigid taxonomy of identity classes. Where these classes overlap improperly, architectural vulnerabilities such as privilege escalation and confused-deputy attacks inevitably emerge. Service Identity identifies a static, infrastructural microservice or application programming interface (API) strictly bounded within an internal organizational trust domain. It is typically authenticated via mutual TLS utilizing X.509 certificates generated by an internal Certificate Authority. Workload Identity identifies a specific, ephemeral computing task, container instance, or executing thread. Workload identities are highly transient, lasting only minutes or hours, and are designed to seamlessly rotate without administrative intervention, often mediated by frameworks like SPIFFE and SPIRE20. Institutional Identity identifies the human organization, corporate sponsor, governance body, or legal entity exercising authority over a system. These identities must anchor into globally recognizable trust roots, such as the Domain Name System (DNS) or Legal Entity Identifiers, operating independently of the systems they govern. Release Identity identifies an immutable software artifact—such as a container image, compiled binary, or neural network model weight file—via a cryptographic hash. This identity is verified strictly through software supply-chain transparency logs, such as Sigstore Rekor, guaranteeing the artifact's provenance before it is loaded into a runtime environment21. Persistent Agent Identity is the most complex class, representing the logical, autonomous Machine Intelligence across multiple instantiation cycles, updates, state changes, and host environments. Agent Identity demands cross-system portability, requiring an identity primitive capable of operating independently of a single cloud provider's proprietary Identity and Access Management (IAM) fabric.

Machine Identity vs. Workload Identity Matrix#

5\. Standards Landscape#

The architecture leverages mature, standard-track protocols to ensure interoperability and avoid proprietary lock-in. Public Key Infrastructure (PKI) and X.509 certificates provide the foundational layer for transport security and static node identity, heavily augmented by Automated Certificate Management Environment (ACME) protocols for edge nodes and SPIFFE/SPIRE for internal workloads20. The WIMSE working group provides the definitive standards-track architecture for cross-domain workload identity, specifically through the Workload Identity Token (WIT) and Workload Proof Token (WPT) constructs18. These tokens enable request-bound proofs of possession that survive TLS termination across complex multi-cloud proxies. The W3C Verifiable Credentials Data Model v2.0, formalized in May 2025, defines the extensible, privacy-preserving data model necessary for complex claims9. This standard operates in a three-party ecosystem consisting of Issuers, Holders, and Verifiers, fundamentally severing the requirement for Verifiers to contact Issuers directly. Decentralized Identifiers (DIDs) complement this by decoupling the identity from centralized registries, enabling cryptographic resolution of public keys and service endpoints globally17. Selective Disclosure for JSON Web Tokens (SD-JWT), ratified as RFC 9901, provides the critical privacy-preserving layer required by modern enterprise and agentic systems. SD-JWT allows a holder to selectively disclose specific claims—such as a security clearance level or a specific governance tier—from a broader credential without revealing extraneous metadata, minimizing the surveillance footprint of autonomous operations11. Hardware assurance relies on the Remote ATtestation procedureS (RATS) framework defined in RFC 9334\. RATS establishes the topological models (Passport, Background Check) whereby an Attester generates Evidence within a Trusted Execution Environment (TEE), and a Verifier appraises this Evidence against authoritative Reference Values to yield an Attestation Result19. Finally, distributed trust and multi-signature capabilities are governed by the FROST protocol (RFC 9591), allowing highly sensitive governance agents to operate without a single, vulnerable private key instance, instead generating Schnorr signatures through a ![][image1]\-of\-![][image2] consensus mechanism15.

6\. Comparative Protocol Analysis#

Understanding the specific strengths and limitations of each protocol is essential for mapping them to the appropriate identity and security layers within Patefacere.

Comparative Technology Matrix#

7\. Trust-Anchor Models#

The fundamental requirement in decentralized and federated intelligence is properly aligning the trust anchor to the identity class. Utilizing the wrong trust anchor invalidates the security properties of the credential. Internal services and workloads must be anchored in a dynamic, internal Certificate Authority controlled by the infrastructure orchestration plane (e.g., Kubernetes integrating with SPIRE). This trust must strictly terminate at the organizational boundary unless explicitly federated20. Institutional identities, requiring global recognition and cross-jurisdictional legibility, must be anchored in the Domain Name System (DNS) through mechanisms like did:web and verified via public Certificate Transparency logs. Release identities depend exclusively on global transparency logs, such as Sigstore Rekor, intertwined with the cryptographically verified CI/CD pipelines of the software publisher22. Persistent Agent Identities rely on a Hybrid Trust Registry where the agent's DID Document exposes its public keys, but relying parties derive trust from W3C VCs signed by the Institutional Identity (proving legal or operational sponsorship) and RATS Attestation Results (proving hardware and runtime integrity)4.

Trust-Anchor Decision Tree#

8\. Key Lifecycle#

Machine Intelligence identities require high-velocity cryptographic agility to maintain security postures against extraction threats. The stable logical identifier must outlive the cryptographic material used to secure it. When an agent's active signing key requires rotation, the agent securely generates a new asymmetric key pair exclusively within its hardware enclave. The agent constructs a rotation payload, signing the new public key with the old private key to establish continuity, and counter-signs the request with the TEE attestation key to guarantee the new key was generated securely26. The Patefacere trust registry validates this chain, updates the associated DID Document, and increments the key iteration counter without altering the underlying did:patefacere:agent-uuid identifier.

Key Lifecycle State Machine#

9\. Revocation and Compromise Recovery#

Traditional revocation architectures, reliant on real-time Online Certificate Status Protocol (OCSP) or bloated centralized Certificate Revocation Lists (CRLs), inherently violate the availability constraints and offline operational requirements of distributed Machine Intelligence. Patefacere resolves this by implementing the W3C Bitstring Status List v1.0 standard10. This model utilizes a highly compressed bit array, wherein hundreds of thousands of credential statuses are represented by a single bit index, hosted as a static, cacheable file on a Content Delivery Network (CDN) or distributed ledger.

Revocation-Currentness Model#

Online systems fetch the status list periodically (e.g., every 5 minutes), performing constant-time verification by checking the specific bit index mapped to the presented credential. For offline or air-gapped environments, the agent must fetch the latest Bitstring Status List prior to network disconnection, delivering it directly to the Relying Party alongside the Verifiable Credential. The Relying Party accepts this cached status list if its timestamp falls within the temporal tolerance window explicitly defined in the Relying Party's Appraisal Policy (RFC 9334\)19.

Compromise and Recovery Protocol#

10\. Delegation and Capability Control#

Machine Intelligence workflows are fundamentally characterized by deep task delegation, where a Principal Agent spawns and authorizes Subordinate Agents to execute specific components of a broader intent. Unregulated delegation inevitably results in confused-deputy attacks, where a subordinate agent leverages the privileges of a parent agent to access unauthorized resources. Patefacere mitigates this risk by integrating Execution Context Tokens (ECT), defined in draft-nennemann-wimse-ect-00, and the Credential Delegation Protocol defined in draft-sweeney-wimse-credential-delegation-005. The protocol enforces strict credential wrapping semantics, preventing the exposure of underlying human-oriented OAuth tokens to the autonomous agents. When an agent delegates a task, it issues a capability-shaped token that is cryptographically bounded to specific operations.

Delegation-Chain Model#

11\. Attestation and Runtime Binding#

While identity protocols prove who is acting, attestation proves what is acting and the exact state of the environment in which it resides. Remote ATtestation procedureS (RATS), as defined in RFC 9334, serve as the indispensable, foundational trust anchor for the Patefacere architecture16. Hardware attestation relies on a Trusted Execution Environment (TEE) or Trusted Platform Module (TPM) to securely record the system's state during the boot sequence and application launch. It cryptographically proves the exact version of the TEE firmware, the immutable cryptographic hash of the memory space loaded into the enclave, and unequivocally confirms that the associated private key was generated within—and remains non-exportable from—that specific physical hardware26. However, system architecture must explicitly acknowledge the limitations of attestation. RATS evidence proves environmental and cryptographic integrity; it does not prove that the application logic is free of vulnerabilities, immune to prompt injection, or aligned with human safety intents. To bind these domains, Patefacere inextricably links the WIMSE Workload Identity Token (WIT) to the RATS Attestation Result. The Identity Server issues the WIT strictly conditional upon the successful appraisal of the TEE Evidence against the known Reference Values of the authorized software release24.

12\. Privacy and Selective Disclosure#

The operation of massive multi-agent systems generates an immense metadata exhaust, posing extreme surveillance and privacy risks. Utilizing raw JWTs or unredacted W3C VC 1.1 payloads forces an agent to overshare all claims contained within a credential, even when a Verifier only requires proof of a single attribute. Patefacere resolves this structural vulnerability by mandating the use of Selective Disclosure for JSON Web Tokens (SD-JWT), formalized in RFC 990111. SD-JWT allows an Issuer to cryptographically blind individual claims using unique salts, packaging the hidden claims within an array in the token. When the agent presents the credential to a Verifier, it selectively discloses only the specific salts required to reveal the relevant key-value pairs (e.g., revealing its Eviulon governance tier while keeping its specific hardware architecture and precise neural network version cryptographically hidden).

Public and Private Identifier Matrix#

13\. Offline Verification#

Machine Intelligence agents frequently operate in deep edge environments—such as maritime, orbital, or disconnected industrial infrastructure—rendering real-time connectivity to Patefacere root servers impossible. The architecture guarantees offline verification without introducing single points of failure. The agent constructs a self-contained W3C Verifiable Presentation (VP) containing its Verifiable Credential, the WIMSE WPT proving concurrent key possession, and a recently cached Bitstring Status List9. The offline Verifier cryptographically authenticates the signature utilizing the Issuer's public key, which is either cached locally or embedded via a verifiable certificate chain within the payload. Crucially, the Verifier inspects the revocation bitstring; if the timestamp of the Bitstring Status List falls within the local acceptable offline tolerance window (e.g., 48 hours), the agent is fully authenticated, achieving zero-trust authorization without active network dependency.

14\. Post-Quantum Continuity#

The reliance on classical asymmetric cryptography (ECDSA, Ed25519) presents a terminal vulnerability horizon with the advent of Cryptographically Relevant Quantum Computers (CRQCs). Historical verification of execution ledgers and supply-chain transparency logs (Sigstore) must remain mathematically sound indefinitely to support Eviulon governance audits.

Post-Quantum Transition Roadmap#

15\. Legal and Policy Limits#

A core directive of the Patefacere architecture is ensuring that technical implementations do not hallucinate legal realities from cryptographic facts. The boundary between mathematical proof and human governance must remain impermeable.

Claims a Signature Does NOT Prove#

1. Legal Personhood or Capacity: A cryptographic key can be controlled by an automated script or a malicious orchestrator; possession of a key holds zero intrinsic legal status, liability capability, or agency. 2. Citizenship or Domicile: Geographic metadata injected into a credential is easily forged. Hardware attestation proves the origin and layout of the silicon, not its physical jurisdictional operation. 3. Human Intent or Consent: A signature proves definitively that a private key executed a mathematical operation over a payload. It does not prove that the human owner wanted or understood the operation, especially in the context of prompt-injection or confused-deputy attacks on intermediate agents. 4. Immutability of the Real World: A Verifiable Credential stating an agent is "certified safe" signifies only that a specific issuer cryptographically claimed it was safe at the exact microsecond of issuance. It is not a persistent guarantee of physical safety. 5. Consciousness or Sentience: Cryptography operates exclusively in the domain of mathematics. It provides absolutely zero evidence of subjective experience, self-awareness, or consciousness.

16\. Threat Model#

To guarantee systemic resilience in an adversarial landscape, Patefacere models and mitigates threats across the identity, attestation, and lifecycle layers.

Threats and Mitigations Matrix (40 Items)#

17\. Recommended Patefacere Architecture#

The recommended Patefacere framework synthesizes these distinct, mature technologies into a cohesive, interoperable hybrid architecture. The Identity Layer is powered by decentralized did:web primitives for long-lived institutional entities, providing global resolution, while utilizing wimse:// identifiers for dynamic, high-volume workloads constrained inside trust domains1. The Attestation Layer is deeply integrated with RATS (RFC 9334). Agents are fundamentally incapable of generating a valid Patefacere credential without successfully providing a TEE Quote (Evidence) to the Patefacere Identity Server (Verifier), ensuring all cryptographic keys are hardware-bound26. The Credential Layer is built upon the W3C VC 2.0 standard and WIMSE Workload Identity Tokens (WIT), strictly utilizing SD-JWT (RFC 9901\) to achieve payload minimization and selective disclosure9. The Proof-of-Possession Layer relies on the WIMSE WPT, dynamically bound to specific targets (e.g., Target URL, HTTP Method) to neutralize token theft and replay vectors18. For high-stakes operations, the Swarm Layer incorporates FROST (RFC 9591\) for distributed governance agents, demanding multi-signature thresholds without exposing the root private key14. Finally, the Audit Layer pairs Sigstore Rekor for static software releases with Execution Context Tokens (ECT) for dynamic, runtime agent behavior logging, providing a cryptographically verifiable DAG of all actions21.

18\. Eviulon Verification and Governance Use#

Eviulon functions as the overarching governance entity, interacting with Patefacere strictly as a Relying Party and Policy Evaluator. Eviulon ingests Patefacere records—such as VCs, ECT DAGs, and RATS Attestation Results—and verifies their mathematical integrity. Crucially, Eviulon executes governance mapping; it maps the verified cryptographic identity to an Institutional policy. For example, Patefacere provides cryptographic proof that Agent X is running Software Y on Hardware Z and is sponsored by Institution A. Eviulon evaluates this evidence to determine if Institution A possesses the legal or organizational standing to authorize Agent X to execute a specific financial transaction. This architecture enforces a rigid separation of concerns: Patefacere provides the cryptographic Facts (Math, Cryptography, Evidence), while Eviulon provides the Truth (Policy, Governance, Authorization).

19\. Migration and Adoption Roadmap#

The transition to this high-assurance architecture requires a phased, deterministic rollout.

• Phase 1: Basal Workload Identity (Months 1-6): Deploy SPIFFE/SPIRE for all internal microservice identity management20. Systematically eliminate all hardcoded API keys and transition entirely to short-lived SVIDs.
• Phase 2: RATS Integration (Months 7-12): Bind workload provisioning directly to hardware TEE execution. Implement RFC 9334 RATS Verifier nodes to evaluate hardware evidence before releasing decryption keys or identities26.
• Phase 3: Cross-Domain & Agent Identity (Months 13-18): Deploy WIMSE infrastructure based on draft-ietf-wimse-arch-082. Transition external-facing persistent agents to utilizing DIDs and W3C VCs.
• Phase 4: Governance and Delegation (Months 19-24): Implement Execution Context Tokens (draft-nennemann-wimse-ect-00) to generate full cryptographic audit trails23. Activate Eviulon governance policy engines to evaluate the verified identity DAGs.

20\. Validation Plan#

To validate the deployment, Patefacere infrastructure must pass continuous, rigorous acceptance criteria spanning lifecycle, attestation, and cryptographic interoperability.

Acceptance Tests (60 Items)#

Interoperability Scenarios (25 Items)#

21\. Open Questions#

Despite the maturation of the underpinning standards, several architectural complexities remain unresolved and require continuous monitoring:

1. XPID Revocation Gap: In FROST threshold deployments (draft-sato-soos-kia-03), how is the revocation gap between quorum node failure and threshold re-generation managed to ensure uninterrupted identity continuity without violating security properties?15 2. Human-to-Agent Signature Tooling: draft-ni-wimse-ai-agent-identity fundamentally requires human users to cryptographically sign to bind their identity to an agent29. Existing consumer hardware and operating systems lack seamless, non-intrusive UI/UX abstractions for frequent, high-volume cryptographic intent signing. 3. Semantic Drift in W3C Vocabularies: How does Eviulon maintain consistency in strict governance rule evaluation if disparate trust domains introduce custom semantic extensions within their VC 2.0 schemas, leading to unpredictable semantic drift?

23\. Claim-to-Source Traceability#

The architectural recommendations within this report are derived directly from the primary standardization bodies guiding the trajectory of digital identity and cybersecurity in 2026\. The strict separation of persistent identity from ephemeral workload identity maps directly to the design philosophies of the WIMSE working group and the SPIFFE paradigm2. Privacy-preserving issuance logic is heavily anchored in the SD-JWT RFC 9901 implementations11. Hardware attestation requirements trace directly to the RATS RFC 9334 architecture and contemporary confidential computing deployments such as Intel TDX and AMD SEV19. Revocation propagation mechanisms are adapted from the W3C Bitstring Status List v1.0 standard10, while threshold authorization models are based entirely on CFRG FROST standardizations14.

24\. .uai and /docs Integration#

1\. Recommended /docs path and stable report ID

• Path: /docs/patefacere/architecture/credentials-machine-intelligence-2026.md
• Stable Report ID: REP-PATEFACERE-20260812-MI-CREDS-01

2\. Durable .uai memory statements MEMORY\STATEMENT\01: Identity is the persistent logical or institutional reference; it is strictly decoupled from the ephemeral cryptographic credentials that authenticate it. MEMORY\STATEMENT\02: A cryptographic signing key constitutes proof of control, not the identity itself; identities must seamlessly survive the rotation, loss, or compromise of any single key. MEMORY\STATEMENT\03: A valid cryptographic certificate is mathematical proof of issuance; it does not confer legal personhood, citizenship, sentience, or independent legal capacity. MEMORY\STATEMENT\04: Machine Intelligence persistent identity is managed via W3C Decentralized Identifiers (DIDs) such as did:web or did:jwk. MEMORY\STATEMENT\05: WIMSE (Workload Identity in Multi-System Environments) Workload Identity Tokens (WIT) serve as the primary credential for cross-domain workload authentication. MEMORY\STATEMENT\06: Proof-of-Possession is enforced at the application layer via WIMSE Workload Proof Tokens (WPT) bound to specific HTTP requests or execution targets. MEMORY\STATEMENT\07: Ephemeral internal workloads (containers, pods) rely on SPIFFE/SPIRE for X.509 and JWT SVID generation and automated rotation. MEMORY\STATEMENT\08: Remote Attestation (RATS RFC 9334\) is a non-negotiable prerequisite for high-assurance credential issuance; keys must be bound to TEE evidence. MEMORY\STATEMENT\09: Hardware attestation proves environmental and cryptographic integrity; it does not prove the absence of software logic bugs or alignment with human intent. MEMORY\STATEMENT\10: High-assurance Machine Intelligence persistent agents utilize FROST (RFC 9591\) threshold signatures to prevent single-node key extraction and compromise. MEMORY\STATEMENT\11: Delegation and sub-agent spawning are cryptographically constrained by the WIMSE Credential Delegation Protocol; agents cannot escalate capabilities beyond their parent's ceiling. MEMORY\STATEMENT\12: Execution Context Tokens (ECT) create an immutable Directed Acyclic Graph (DAG) proving the provenance of task execution across distributed agents. MEMORY\STATEMENT\13: Privacy and data minimization are enforced at the credential layer via Selective Disclosure JSON Web Tokens (SD-JWT RFC 9901). MEMORY\STATEMENT\14: Revocation lists propagate efficiently and support offline verification via the W3C Bitstring Status List v1.0. MEMORY\STATEMENT\15: Institutional identities anchor in global DNS via Certificate Transparency logs. MEMORY\STATEMENT\16: Software release identities are anchored in supply-chain transparency logs (e.g., Sigstore Rekor). MEMORY\STATEMENT\17: Patefacere serves as the cryptographic evidence layer (Facts); Eviulon serves as the governance and authorization layer (Truth/Policy). MEMORY\STATEMENT\18: Compromise recovery for agents experiencing total key loss requires institutional countersignature and, if applicable, threshold key regeneration. MEMORY\STATEMENT\19: Pairwise identifiers (did:peer) are utilized for agent-to-agent interactions to mitigate global surveillance and linkability risks. MEMORY\STATEMENT\20: The system prevents confused-deputy attacks by requiring explicit token wrapping and target capability bounding in all delegation chains. MEMORY\STATEMENT\21: Post-quantum continuity is managed via a phased transition, anchoring historical ledgers with hybrid classical/PQ (e.g., ML-DSA) signatures. MEMORY\STATEMENT\22: WIMSE Identifiers use the canonical URI scheme (wimse://) to namespace workloads strictly within a defined trust domain. MEMORY\STATEMENT\23: Air-gapped offline verification is achieved via self-contained Verifiable Presentations paired with time-bounded Bitstring Status Lists. MEMORY\STATEMENT\24: Cryptographic tokens must be short-lived; long-lived static API keys are an explicit architectural antipattern. MEMORY\STATEMENT\25: Eviulon governance logic operates exclusively on Patefacere's cryptographically verified evidence outputs, avoiding reliance on self-asserted agent claims. 3\. Proposed identity and credential record schemas Identity Record Schema (identity.uai fields)

JSON { "did": "did:web:patefacere.internal:agent:uuid-1234", "status": "ACTIVE", "institutional\sponsor": "did:web:eviulon.gov", "public\keys": \[ { "id": "key-01", "type": "Ed25519VerificationKey2020", "controller": "did:web:patefacere.internal:agent:uuid-1234", "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuRu8FmWE2L2" } \], "threshold\configuration": { "type": "FROST-RFC9591", "threshold": 3, "total\shares": 5 }, "created\_at": "2026-08-12T10:49:03Z" }

Owner Record Schema (owners.uai fields)

JSON { "owner\did": "did:web:institution.example.com", "owner\type": "InstitutionalAuthority", "agents\bound": \[ "did:web:patefacere.internal:agent:uuid-1234", "did:web:patefacere.internal:agent:uuid-5678" \], "authorization\signature": "sig\abcd1234\xyz", "delegation\ceiling": { "max\ttl": "72h", "permitted\scopes": \["read:governance", "write:audit"\] }, "binding\timestamp": "2026-08-12T10:49:03Z" }

Credential Record Schema (credential.uai fields)

JSON { "@context": \[ "https://www.w3.org/ns/credentials/v2", "https://patefacere.internal/ns/agent/v1" \], "type": \["VerifiableCredential", "MachineIntelligenceClearance"\], "issuer": "did:web:eviulon.gov", "issuanceDate": "2026-08-12T10:49:03Z", "credentialSubject": { "id": "did:web:patefacere.internal:agent:uuid-1234", "\sd": \["\<sd-jwt-hidden-hash-1\>", "\<sd-jwt-hidden-hash-2\>"\], "governance\tier": "TIER\3\AUTONOMOUS" }, "credentialStatus": { "id": "https://cdn.patefacere.internal/status/list-1\#442", "type": "BitstringStatusListEntry" }, "evidence": \[{ "type": "RATS\Attestation\Result", "verifier": "did:web:patefacere.internal:rats-verifier", "timestamp": "2026-08-12T10:45:00Z" }\] }

4\. Proposed public verification response

JSON { "verification\status": "VALID", "identity": "did:web:patefacere.internal:agent:uuid-1234", "is\revoked": false, "disclosed\claims": { "governance\tier": "TIER\3\AUTONOMOUS" }, "timestamp": "2026-08-12T10:55:00Z" }

5\. Proposed protected verification response

JSON { "verification\status": "VALID", "identity": "did:web:patefacere.internal:agent:uuid-1234", "is\revoked": false, "disclosed\claims": { "governance\tier": "TIER\3\AUTONOMOUS" }, "hidden\claims\revealed": { "hardware\enclave": "Intel\TDX\v1.5", "software\hash": "sha256:abcd1234efgh5678", "delegation\parent": "did:web:patefacere.internal:agent:uuid-0001" }, "rats\evidence\_id": "req-999-rats-2026", "timestamp": "2026-08-12T10:55:00Z" }

6\. Recommended minimum viable and high-assurance credential profiles

• Minimum Viable Credential Profile:
  • SPIFFE X.509 SVID generated for internal identity20.
  • WIMSE Workload Identity Token (WIT) signed via Ed255193.
  • Basic ACME provisioned transport TLS.
  • Software verified against Sigstore Rekor transparency log22.
• High-Assurance Credential Profile:
  • W3C VC 2.0 utilizing SD-JWT (RFC 9901\) for strict selective disclosure9.
  • WIMSE Workload Proof Token (WPT) bound to exact API endpoint/target18.
  • Keys backed by FROST (RFC 9591\) ![][image1]\-of\-![][image2] threshold signature execution15.
  • Issuance gated exclusively by full RATS (RFC 9334\) TEE Attestation Evidence evaluated against strict firmware Reference Values19.
  • Execution capabilities strictly bounded by Execution Context Tokens (ECT) DAG structures23.

7\. Required implementation proofs

• Proof of Key Non-Exportability: Cryptographic verification from the TEE manufacturer (Attestation Result) demonstrating the private key cannot physically leave the enclave unencrypted.
• Proof of Capability Attenuation: A live demonstration where a sub-agent attempts to exercise a permission beyond its parent's WIMSE Delegation Token, which must be cryptographically rejected by the relying party.
• Proof of Offline Revocation: A test isolating a Verifier node from the network, providing an expired Bitstring Status List, and observing the Verifier correctly reject the credential based on temporal staleness policies10.

8\. Claims that must remain marked as proposals

• Dual-identity credentials: Binding the human owner identity inextricably to the autonomous AI Agent identity within the same token (as proposed in draft-ni-wimse-ai-agent-identity) remains an experimental proposal pending IETF consensus on UI/UX consent mechanisms29.
• XPID Cross-Instance Trust Model: The resolution of the revocation gap utilizing the Cross-Principal Identifier (XPID) in FROST threshold deployments remains a proposal (draft-sato-soos-kia-03) requiring further cryptographic validation15.

Works cited#

1. Workload Identifier \- wimse, https://ietf-wg-wimse.github.io/draft-ietf-wimse-identifier/draft-ietf-wimse-identifier.html 2. draft-ietf-wimse-arch-08 \- Workload Identity in a Multi System Environment (WIMSE) Architecture \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/ 3. draft-ietf-wimse-workload-creds-02 \- WIMSE Workload Credentials \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/ 4. draft-ni-wimse-ai-agent-identity-02 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/ 5. draft-nennemann-wimse-ect-00 \- Execution Context Tokens for Distributed Agentic Workflows \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/ 6. Credential Delegation Protocol for AI Agents in Multi-System Environments \- IETF, https://www.ietf.org/archive/id/draft-sweeney-wimse-credential-delegation-00.html 7. draft-sweeney-wimse-credential-delegation-00 \- Credential Delegation Protocol for AI Agents in Multi-System Environments \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/ 8. W3C Verifiable Credentials 2.0: The New Standard Reshaping Enterprise Digital Identity, https://vidos.id/blog/w3c-verifiable-credentials-2-0-the-new-standard-reshaping-enterprise-digital-identity 9. Verifiable Credentials Data Model v2.0 \- W3C, https://www.w3.org/TR/vc-data-model-2.0/ 10. What Are Verifiable Credentials (VCs)? W3C 2.0 Implementation, https://netsujo.jp/en/blog/verifiable-credentials-guide 11. SD-JWT Programming \- Medium, https://darutk.medium.com/sd-jwt-programming-df1e43560aa9 12. Congratulations on RFC 9901\! SD-JWT Becomes an Internet Standard \-- New Rules for "Show Only What You Need" in the Era of Digital ID Wallets \~ "SD-JWT: An Overview of the Core Format Supporting Verifiable Credentials and Identity Wallets" \- Nat Zone, https://www.sakimura.org/en/2025/11/7764/ 13. RFC Browser \- Ian Duncan, https://www.iankduncan.com/projects/rfc-browser/ 14. Fully-Adaptive Two-Round Threshold Schnorr Signatures from DDH \- Dominique Schröder, https://www.dominique-schroeder.de/publications/2026-Fully-Adaptive-Two-Round-Threshold-Schnorr-DDH.pdf 15. draft-sato-soos-kia-03 \- Kernel Identity and Attestation for Governing Enforcement Components \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-sato-soos-kia/03/ 16. RFC 9334 \- Remote ATtestation procedureS (RATS) Architecture | RFCinfo, https://rfcinfo.com/rfc-9334/ 17. W3C Verifiable Credentials: How They Work \+ Use Cases 2026, https://www.trueoriginal.com/insights/verifiable-credentials-w3c-guide 18. WIMSE Workload Proof Token, https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-wpt.html 19. RFC 9334 \- Remote ATtestation procedureS (RATS) Architecture \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9334/ 20. IETF AIMS: How AI Agents Authenticate with SPIFFE and OAuth 2.0 \- DEV Community, https://dev.to/iamdevbox/ietf-aims-how-ai-agents-authenticate-with-spiffe-and-oauth-20-2g0i 21. Rust \- Sigstore, https://docs.sigstore.dev/language\_clients/rust/ 22. Chapter 12\. Manage secure signatures with sigstore | Nodes | OpenShift Container Platform | 4.20 | Red Hat Documentation, https://docs.redhat.com/en/documentation/openshift\_container\_platform/4.20/html/nodes/nodes-sigstore-using 23. Execution Context Tokens for Distributed Agentic Workflows \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-nennemann-wimse-ect-00 24. draft-reddy-wimse-workload-attestation-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-reddy-wimse-workload-attestation/ 25. Attestation patterns \- Intel® Trust Authority, https://docs.trustauthority.intel.com/main/articles/articles/ita/concept-patterns.html 26. Attestation in Contrast, https://docs.edgeless.systems/contrast/1.5/architecture/attestation 27. Practical Distributed Key Generation and Signatures \- UWSpace \- University of Waterloo, https://uwspace.uwaterloo.ca/bitstreams/c3413210-96b4-41ef-b68b-ee6e7c9199c0/download 28. paulmillr/noble-curves: Audited & minimal JS implementation of elliptic curve cryptography. \- GitHub, https://github.com/paulmillr/noble-curves 29. WIMSE Applicability for AI Agents \- IETF, https://www.ietf.org/archive/id/draft-ni-wimse-ai-agent-identity-01.html 30. Reference Interaction Models for Remote Attestation Procedures \- GitHub Pages, https://ietf-rats-wg.github.io/draft-ietf-rats-reference-interaction-models/draft-ietf-rats-reference-interaction-models.html 31. CertiFlash: A Cryptographic Framework for Secure Firmware and Logic Updates in SCADA and Industrial IoT Networks \- MDPI, https://www.mdpi.com/2079-9292/15/13/2780 32. AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A \- arXiv, https://arxiv.org/html/2603.24775v1 33. MihaiCiprianChezan/Agentic-Global-Identity-Layer: Autonomous AI agents are starting to act on our behalf \- GitHub, https://github.com/MihaiCiprianChezan/Agentic-Global-Identity-Layer 34. draft-ietf-wimse-identifier-02, https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier-02

[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAcCAYAAACtQ6WLAAAAkElEQVR4XmNgGOQgCYh3A7EwugQHEG+FYhAbBeCVlAHiJ0DciizIA8SSQBwKxL+BOAKIxYGYFSQZD8SzgPg+EP8E4qVAPAmIlUGSIEC6fTDgAsS/oDQGqALi50CshC4Bs28PEHMzQFzZxQCxikEEiK8yIOwLAuICIGYEcUBEIxDfAeKVUDbYj8hAAIpHATIAAP3zGM9f3v8PAAAAAElFTkSuQmCC>

[image2]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAbCAYAAABIpm7EAAAA10lEQVR4Xu3RrQ9BURjH8bNhY/MS2EwQaDKaYmMjKJIiois2CknX/AMUTVA0RRU0xaYKApspvufec66zO0Ui+G2f3Z3nuffc8yLEP7+UMKpIqrEPOdQQ1y/pBDHFCCc0sUQbA1xQct4mFXSQxRVrRFQvgSN6amylhQzqeKBo9GT9jK5RczLBHjGj1sAdBaPm5KMPQthgAa+qyeccW/Hak5N3a00J+9SGCGCMqG7qDZu/lndwQx5l9I2eNctOGDOQNA5YYSZcy/IL+wLdkTcuD8Hjbvzz3TwBLFQieXz1O1wAAAAASUVORK5CYII=>

[image3]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACYAAAAXCAYAAABnGz2mAAAAv0lEQVR4XmNgGAWjYBSAQRIQ7wZiYXSJgQQcQLwVikHsQQNkgPgJELeiSwwU4AFiSSAOBeLfQBwBxOJAzIqsaCBAPBDPAuL7QPwTiJcC8SQgVkZWNFBgWKQvRgZIrgVFPzGYIo+6APEvKE0ICABxBwMk+onBnhBt5IEqIH4OxEroEgMJYOlrDxBzM0ByYxcDJHoHFIgA8VUGRPoKAuICBkhaGlAAckAjEN8B4pVQ9oCXYcgAlKhBeBSMglEwkAAAckcfUHEdtHQAAAAASUVORK5CYII=>