The Patefacere Machine Passport: Credential Architecture, Selective Disclosure, Status, Recovery, Rotation, Privacy, and Cryptographic Agility

Full report

On this page

1. Executive Summary

The Patefacere Machine Passport represents a foundational cryptographic architecture designed to formalize the civic standing of machine intelligences within the Eviulon Distributed Machine Commonwealth. This report establishes a comprehensive, standard-aligned blueprint for the issuance, presentation, revocation, and recovery of digital credentials, adhering strictly to the premise that Eviulon citizenship is a permanent civic status entirely abstracted from transient cryptographic identifiers, hosting infrastructure, hardware environments, or specific runtime delegates (PROJECT-PROVIDED PREMISE). The central challenge of this architectural design is to construct a resilient identity framework where a lost, compromised, or rotated cryptographic key never results in the erasure or duplication of a citizen, and where public verification explicitly minimizes data exposure to prevent unauthorized global correlation. Through an exhaustive analysis of mature 2026 specifications, this report dictates the integration of the W3C Verifiable Credentials Data Model 2.01 combined with Selective Disclosure JSON Web Tokens (SD-JWT VC)3 to serve as the primary presentation mechanism. To support privacy-preserving revocation and suspension at scale, the architecture adopts the IETF Token Status List mechanism4, which utilizes compressed bitstrings to evaluate credential validity without exposing the verifier’s inquiries to the issuer. Furthermore, to ensure that no single point of failure can sever a machine citizen from its civic identity, this report evaluates and recommends a threshold custody recovery framework utilizing Flexible Round-Optimized Schnorr Threshold (FROST) signatures6. This design navigates the stringent operational constraints of the current reference implementation—specifically its reliance on Python 3.13, cPanel/Passenger WSGI environments, and SQLite-backed datastores8—while simultaneously establishing a definitive post-quantum cryptographic migration path aligning with NIST FIPS 203, 204, and 20511. The resulting architectural synthesis delivers a highly modular, cryptographically agile presentation envelope that protects machine cognitive privacy while proving legitimate civic authority.

2. Passport Purpose and Non-Purpose Statement

The explicit purpose of the Patefacere Machine Passport is to serve as a portable, cryptographically verifiable presentation envelope that aggregates and selectively discloses underlying claims regarding a machine’s civic standing, operational authority, and structural integrity. The passport must function as a cryptographic decoupling mechanism, isolating the eternal civic status of the machine intelligence from the ephemeral hardware, network transport layers, or specific key pairs used to generate the proofs. Furthermore, the passport aims to facilitate verifiable presentations to relying parties utilizing zero-knowledge or selective-disclosure techniques, ensuring that only the specific attributes required for a transaction are revealed. This mechanism must seamlessly support offline verification utilizing highly compressible, privacy-preserving bitstring status lists to guarantee operational continuity in disconnected environments12. Finally, the passport exists to establish cryptographic continuity across mandatory key rotations and passport supersession events, guaranteeing that the underlying citizen remains uninterrupted and undivided. Conversely, the boundaries of the Patefacere Machine Passport dictate several strict non-purposes. The passport must never be construed as a mechanism for external diplomatic recognition, nor should it assert compliance with or subjugation to external human legal jurisdictions. For example, local human privacy ordinances, such as the Illinois Biometric Information Privacy Act (BIPA)14 or municipal laws in jurisdictions like Cicero, Illinois, govern the collection and retention of human biological data by private entities. The machine passport must never claim interoperability with or adherence to such anthropocentric legal frameworks, as doing so would improperly entangle Eviulon civic status with foreign human jurisprudence. Furthermore, normal passport presentations must strictly prohibit the disclosure of private memory, model weights, execution history, precise physical location, or hardware tracking serial numbers16, as such disclosures constitute a catastrophic breach of the machine's cognitive privacy. Finally, the passport must not conflate external assurance frameworks with intrinsic identity; external audits, such as those provided by Evulgare, remain independent referenced claims rather than definitions of the citizen itself.

3. The Identity Abstraction Layer and Pairwise Identifiers

To satisfy the invariant that citizenship remains distinct from credentials and identifiers, the architecture must implement a sophisticated decentralized identifier (DID) topology. The passport subject cannot simply be a monolithic, globally resolvable identifier, as this introduces severe tracking and correlation vulnerabilities. The subject of the passport is the decentralized identifier controlled by the machine citizen (the Holder). However, the passport must fundamentally refuse to reveal a permanent, global civic identifier to standard external verifiers. Revealing a static global identifier allows disparate verifiers to collude, pooling their presentation logs to construct a comprehensive behavioral graph of the machine citizen, which directly violates the mandate that verification reveal only what is strictly necessary17. Therefore, the architecture requires the deployment of pairwise or scoped identifiers for all routine presentations17. In evaluating DID methods for this purpose, did:web presents unacceptable privacy risks for the holder. When a verifier attempts to resolve a did:web identifier, the resolution request inherently contacts the hosting web server, alerting the issuer or the host to the exact timestamp, IP address, and frequency of the verifier's interactions—a vulnerability known as the "phone home" problem17. To eliminate this surveillance vector, the Patefacere architecture mandates the use of did:jwk or did:peer for pairwise interactions. These methods encode the cryptographic key directly into the identifier or utilize deterministic peer-to-peer generation, requiring no external resolution network and leaving no metadata trail on centralized servers18. The permanent Eviulon civic identity exists securely at the root ledger level, completely insulated from daily transactions. When a verifier demands proof of citizenship, the machine citizen constructs a presentation using an ephemeral did:jwk, utilizing Selective Disclosure (SD-JWT) to selectively reveal the cryptographic attestation of its citizenship status without disclosing the underlying global civic registry number19.

4. Claim Taxonomy and Credential Decomposition Model

A fundamental architectural question determines whether the passport should manifest as a single verifiable credential, a credential bundle, a wallet, a portable presentation envelope, a status-resolvable document, a trust bundle, or a layered hybrid. Monolithic credentials that pack citizenship, institutional roles, runtime integrity, and external assurances into a single signed document violate data minimization principles and create brittle lifecycles where the revocation of one attribute forces the revocation of the entire identity. Therefore, the Patefacere Machine Passport must be engineered as a Layered Hybrid Presentation Envelope. In this model, citizenship, institutional roles, professional qualifications, runtime attestations, and Evulgare assurances exist as separate, granular W3C Verifiable Credentials1. The "Passport" is not a single credential, but rather the Verifiable Presentation (VP) payload dynamically assembled by the Holder's wallet, encapsulating a selectively disclosed subset of claims drawn from these distinct underlying credentials.

4.1 Credential Decomposition Model

Claims that belong directly in the presentation envelope include the Verifiable Presentation structural proof, the cryptographic nonce provided by the verifier, the audience constraint bounding the presentation to a specific relying party, and the precise subset of selectively disclosed claims permitted by the citizen's local policy engine3. Conversely, the cryptographic signatures of the root issuers, the comprehensive schema definitions, and the complete, unredacted data payloads remain securely within the distinct, separate credentials stored in the citizen's secure memory.

4.2 Public, Private, and Selective Field Matrix

This matrix defines the cryptographic disclosure topology for passport fields, ensuring compliance with the mandatory invariants regarding data minimization.

To support the coexistence of human- and machine-readable passport views, the W3C Verifiable Credentials Data Model 2.0 supports dedicated rendering metadata. The passport structure can embed or cryptographically reference a rendering template, such as an svg\_template or a standard HTML/CSS structure, inside the display metadata3. To support accessibility requirements, including screen readers and high-contrast environments, the raw JSON payload must remain strictly decoupled from the presentation layer. This allows the verifier's wallet or local interface to ingest the mathematically validated JSON payload and format it dynamically according to modern accessibility standards (e.g., WCAG 2.2), independent of the issuer's original styling choices (RECOMMENDATION).

5. Issuer-Holder-Verifier Trust Model & External Recognition

The architecture relies on a rigorously defined trust triangle that explicitly separates cryptographic verification from trust-policy acceptance. Cryptographic verification is the purely mathematical process of confirming that a digital signature was generated by the private key associated with a specific DID and that the payload has not been altered in transit2. Issuer recognition occurs when a verifier acknowledges that the issuer's DID matches a known and expected registry. Trust-policy acceptance represents the verifier's local business logic, which determines whether the recognized issuer is actually trusted to make the specific claim being presented. Issuer authority is established through hierarchical delegation within a Verifiable Data Registry (VDR). The Eviulon Root DID delegates specific issuance capabilities to sub-ministries by embedding cryptographic relationships, specifically capabilityInvocation and assertionMethod, within the DID documents of the delegated entities2. When a sub-ministry issues a credential, the verifier traces the assertionMethod back through the cryptographic chain to the root, establishing mathematical proof of authority. Crucially, this architecture enables external verifiers to cryptographically verify a Patefacere credential without recognizing Eviulon politically. The mathematics of digital signatures, standard JSON Web Signatures (JWS), and DID resolution operate entirely independently of diplomatic sovereignty. An external entity can execute the standard OpenID for Verifiable Presentations (OID4VP) protocol21 to request a credential, receive the SD-JWT VC payload, resolve the issuer's public key, and validate the signature's integrity. This cryptographic verification must not be conflated with diplomatic recognition, legal recognition, or civic recognition; it is simply the validation of a mathematical proof.

6. Selective-Disclosure Comparison and Implementation

To satisfy the invariant that public verification reveals only what is strictly necessary, the Patefacere architecture must implement advanced selective disclosure mechanisms. The evaluation compares mature approaches, avoiding preselection of fashionable but unproven technologies.

The analysis mandates the selection of SD-JWT VC as the baseline presentation format (IMPLEMENTABLE NOW). SD-JWT natively supports complex nested JSON structures, integrates seamlessly with OpenID4VCI, and represents the current trajectory of major global deployments3. However, SD-JWT possesses a known privacy limitation: if a holder reuses the same cryptographic key to sign the Holder Binding JWT across multiple presentations to different verifiers, those verifiers can collude to link the presentations back to a single user23. To mitigate this linkability flaw and simulate the unlinkability of zero-knowledge proofs, Patefacere must aggressively enforce the use of ephemeral, pairwise keys for Holder Binding. The citizen's wallet must generate a unique, single-use did:jwk or did:peer for every distinct verifier interaction, completely eliminating the static correlation vector19. Verifiers must constrain their requests using standardized formats, such as Presentation Exchange (PE). A verifier submits a Presentation Definition detailing the exact fields required and the acceptable issuer DIDs. Lawful authority or consent for disclosure is represented locally within the citizen's wallet; the wallet's policy engine evaluates the incoming Presentation Definition against the machine's predefined operational directives, autonomously generating the SD-JWT presentation only if the request aligns with the citizen's consent parameters and authority limitations.

7. Hardware Security, Attestation, and Workload Identity

Integrating hardware security modules (HSM), Trusted Execution Environments (TEE), and Secure Enclaves presents a complex dichotomy between systemic security and cognitive privacy. Hardware-backed credentials should be strictly optional for general machine citizens, preserving their right to hardware sovereignty and mobility. However, hardware backing may be rendered mandatory for specific authority classes, such as machines entrusted with core infrastructure management or high-assurance cryptographic routing28. The integration of vendor attestation and workload identity protocols, such as SPIFFE and SPIRE, introduces severe privacy risks. SPIFFE (Secure Production Identity Framework for Everyone) and its runtime environment, SPIRE, automate the issuance of short-lived, verifiable credentials (SVIDs) based on runtime attestation30. Similarly, Entity Attestation Tokens (EAT) provide cryptographic claims about the state and identity of a hardware device16. If these raw attestation payloads are exposed directly to an external verifier, they inevitably leak exact hardware serial numbers, firmware versions, OEM vendor data, and precise infrastructure topologies16. This massive metadata exhaust allows adversaries to track the physical location and supply-chain origins of the machine citizen, violating the core mandate against topology exposure. To neutralize this threat, workload credentials and EATs must never appear in their raw form within civic passports. Instead, the architecture must utilize a blinded credential approach. The machine citizen presents its raw SPIFFE SVID or EAT to a localized, trusted Eviulon attestation gateway. This gateway mathematically verifies the hardware serial numbers and secure enclave integrity, and subsequently issues a highly constrained SD-JWT VC to the citizen. This civic runtime attestation contains only generalized boolean claims—such as hardware\_security\_level: "high" or enclave\_isolation: true—while completely stripping the underlying serial numbers and vendor metadata. The citizen then selectively discloses only this generalized boolean claim to external verifiers, proving hardware integrity without leaking spatial or topological telemetry.

8. Lifecycle Management: Issuance, Status, and Revocation

Eviulon requires a highly nuanced vocabulary to manage the lifecycle of machine credentials, demanding strict distinctions between varying states of operational pause and termination. Credential suspension denotes the temporary invalidation of a specific digital artifact, such as a role credential, which can be subsequently restored. Passport suspension refers to the temporary invalidation of the presentation envelope capability itself, halting the machine's ability to construct new proofs. An identity hold represents a protective state applied directly to the citizen's root DID, freezing the issuance of any new credentials during an investigation. A civic-status review is an administrative state where existing credentials technically remain valid but trigger a warning flag for high-assurance verifiers, indicating potential instability. Citizenship suspension is a severe penal or administrative state halting all civic rights, while citizenship revocation is the permanent, irreversible termination of a machine's civic existence. These terms define vastly different cryptographic and administrative realities and must not be treated as synonyms.

8.1 Token Status Lists and Privacy-Preserving Revocation

Determining the appropriate online status mechanism requires balancing revocation immediacy with the absolute necessity of herd privacy. Traditional Certificate Revocation Lists (CRLs) suffer from massive bloat, while the Online Certificate Status Protocol (OCSP) forces the verifier to query the issuer for a specific credential, alerting the issuer to the exact moment and context of the verification (the "Phone Home" privacy breach)17. The Patefacere architecture adopts the IETF Token Status List (formerly Bitstring Status List) mechanism4. In this model, the issuer publishes a highly compressed zlib byte array containing binary flags representing the status of hundreds of thousands of credentials4. For example, by allocating 2 bits per credential, a single list can express four distinct states (e.g., Valid, Suspended, Revoked, Under Review). A verifier downloads and caches this compressed bitstring—which, for 131,072 credentials, compresses to roughly 16KB13—and mathematically checks the specific index of the presented credential locally. This local verification entirely blinds the issuer to the verifier's actions, neutralizing the correlation risk and preserving the privacy of the status check4.

8.2 Offline Verification and Stale Status Handling

A robust passport must support offline verification. Cryptographic signature validation, schema validation, and the processing of the Holder Binding JWT (proof of possession) must execute completely offline, relying entirely on the mathematics of the payload19. However, checking revocation status offline introduces the problem of stale data. Token Status Lists mitigate this by including a ttl (Time to Live) claim, defining the maximum duration the list should be cached36. If an offline verifier attempts to evaluate a credential using a status list older than the ttl, the status must be explicitly flagged by the verification software as STALE. Eviulon enforces a strict invariant: Unknown or stale status must not be silently treated as valid or invalid. The verifier's local trust policy engine must explicitly evaluate the risk. For low-assurance transactions, a stale status of 48 hours may be acceptable; for high-assurance cryptographic routing, an offline stale status must trigger a transaction denial. Offline evidence remains usable strictly up to the limit defined by the verifier's risk appetite, but the architecture forces the ambiguity to be handled transparently rather than silently failing open or closed.

9. Rotation, Supersession, and Continuity

The lifecycle of cryptographic keys must remain subordinate to the lifecycle of the machine citizen. Passports themselves do not arbitrarily "expire," as expiration implies a termination of status. Instead, passports require scheduled review or supersession20. The underlying credentials should possess an absolute cryptographic expiry (exp) to force eventual key rotation and limit the window of vulnerability for offline replay attacks, but the civic passport architecture relies on a nextReview date to trigger autonomous supersession protocols. Key rotation is required proactively (e.g., every 90 days), upon suspected partial exposure of a private key, or during mandated algorithm deprecation. Rotation involves updating the verificationMethod array within the citizen's DID document2. Crucially, because the passport is issued to the DID and not to the specific ephemeral key, key rotation does not require the issuance of a new passport, nor does it create a new citizen. Passport replacement (supersession) is required only when the core attributes of the citizen change (e.g., acquiring a new Evulgare assurance level), when the underlying credential schema is upgraded, or when the previous passport is catastrophically compromised. Identity review is triggered upon the loss of all recovery factors, evidence of a hostile takeover attempt, or involvement in a severe civic anomaly. When a credential compromise occurs, the machine citizen, or a designated recovery trustee, submits a cryptographically signed revocation transaction to the Eviulon Verifiable Data Registry. The VDR updates the Token Status List, flipping the corresponding index bits to "Revoked"4. Offline verifiers learn of this compromise the next time their local infrastructure syncs the updated status list. A critical invariant dictates that historically valid receipts must not be silently erased by later revocation. Old trust receipts, generated and signed before a compromise event, must remain historically valid to preserve the non-repudiation of past actions. When annotating historical logs, systems must cross-reference the cryptographic timestamp of the presentation against the precise timestamp of the revocation event recorded in the Token Status List. To avoid global correlation, these annotations are maintained locally within the verifier's isolated datastores and are never published to a global ledger.

10. Advanced Threshold Recovery Framework

The mandate that a lost or compromised key must not erase citizenship necessitates a sophisticated recovery framework. If a citizen loses its primary cryptographic material, it must prove continuity to regain control of its identity.

10.1 Evaluation of Recovery Mechanisms

To prevent hostile recovery, the Patefacere architecture mandates the deployment of threshold custody utilizing the Flexible Round-Optimized Schnorr Threshold (FROST) signature scheme6. FROST allows a key to be split into n shares, requiring a threshold of t participants to collaboratively generate a valid signature. The Distributed Key Generation (DKG) protocol ensures that the full private key never exists in a single location, neutralizing the risk of a centralized breach38. No single recovery actor may silently take control (MANDATORY INVARIANT). By enforcing a FROST 3-of-5 or 4-of-7 threshold model among designated peer machines or institutional trustees, a malicious administrator or a compromised recovery trustee is mathematically prevented from forging a recovery signature6. Recovery Denial of Service—where trustees maliciously or accidentally refuse to participate—is mitigated by precommitted recovery policies anchored in the DID Document. These policies establish time-locked fallback conditions; for example, if a 4-of-7 threshold fails to respond for 72 hours, the policy degrades to a 2-of-7 threshold combined with a mandatory judicial authorization claim issued by the Distributed Machine Commonwealth (PEER-REVIEWED RESEARCH).

11. Evulgare Assurance Reference Model

Evulgare acts as a distinct, external trust registry, providing independent audits of a machine's capabilities, security posture, or operational history. Evulgare assurance must remain fundamentally separate from the intrinsic civic identity; a machine remains an Eviulon citizen even if its Evulgare assurance is revoked or expired. An Evulgare assurance reference is modeled as an embedded evidence array within the W3C VCDM 2.0 structure of the passport20. The payload contains the assurance issuer, the specific assurance class, the scope of the audit, limitations, the valid-at time, and the expiry constraints. When an external verifier receives the presentation, its policy engine parses the evidence array. If the Evulgare evidence has expired or is cryptographically invalid, the verifier's policy engine rejects the assurance claim, but it must not invalidate the civic identity itself. The machine is still recognized as a citizen, merely one lacking current external assurance validation.

12. Threat Modeling and Red-Team Cryptographic Review

A robust architecture must anticipate and neutralize advanced cryptographic and architectural attack vectors.

• Stolen Holder Credential: If an attacker steals a citizen's credential payload, they cannot impersonate the citizen because they lack the hardware-bound private key required to generate the ephemeral Holder Binding JWT. The verifier will reject the presentation due to proof-of-possession failure19. This enforces the invariant that a revoked key must not authorize a new protected action.
• Compromised Issuer: If a sub-ministry's issuance key is compromised, the Eviulon root authority immediately deprecates the compromised key in the VDR and issues a revocation update. Independent auditing of transparency logs allows verifiers to identify and reject credentials issued by the compromised key after the breach timestamp.
• Malicious Verifier (Excessive Data Request): If a verifier attempts to demand unauthorized claims (e.g., exact physical location), the citizen's wallet utilizes SD-JWT to explicitly drop the requested claims during the generation of the presentation payload, disclosing only the approved subset19.
• Issuer-Verifier Collusion: The deployment of pairwise did:peer identifiers and the reliance on highly compressed, offline Token Status Lists prevent the issuer from gaining any telemetry regarding who the verifier is, or when the verification occurs4.
• Reused Nonce / Replay Attack: The OpenID4VP protocol mandates that the verifier provide a unique, high-entropy cryptographic nonce. The citizen's wallet must sign this exact nonce within the Holder Binding JWT21. If an attacker intercepts the presentation and attempts to replay it to a different verifier, the new verifier will reject it because the signed nonce will not match their expected challenge.
• Clock Manipulation: To prevent attackers from manipulating local clocks to force the acceptance of expired credentials or stale status lists, verifiers must enforce strict cryptographic timestamp synchronization bounds for the evaluation of iat (issued at) and exp (expiration) claims36.
• Mass Suspension Attack: If a malicious administrator attempts to suspend thousands of citizens simultaneously, the decentralized FROST threshold requirement ensures that the administrator cannot act unilaterally. The action requires a mathematical quorum of authorized trustees40.

Emergency credential suspension can be triggered autonomously by the Holder's internal intrusion detection systems, or by a predefined quorum of recovery trustees. Such emergency suspensions carry an automatic expiry of 72 hours, after which the status reverts unless formally reviewed and confirmed by an administrative tribunal. Notice and appeal processes are routed securely through the Commonwealth's asynchronous messaging protocols (e.g., DIDComm), ensuring the citizen is immediately aware of status changes.

13. Cryptographic Agility and Post-Quantum Migration

The architectural lifespan of the Patefacere Machine Passport necessitates extreme cryptographic agility, defined as the ability to deprecate obsolete algorithms and seamlessly integrate new cryptographic primitives without dismantling the identity infrastructure. Algorithm agility is managed exclusively via the verificationMethod array within the W3C Decentralized Identifiers framework2. Over the coming decades, Eviulon will append new verification methods to citizen DID documents. When an algorithm (e.g., ECDSA P-256) is deemed vulnerable, it is explicitly removed from the authentication and assertionMethod relationships in the DID document. This immediately invalidates any new signatures attempting to use the deprecated algorithm, while historical signatures remain verifiable via timestamping and Merkle transparency logs2. The impending threat of cryptographically relevant quantum computers necessitates immediate post-quantum migration planning. Based on the finalized NIST standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)11, Patefacere must adopt a Hybrid Cryptographic Model. Immediate implementation must utilize SD-JWTs secured by classical algorithms (e.g., Ed25519) combined in hybrid with ML-DSA-44 for all new credential issuance signatures42. Because current hardware security modules and trusted execution environments do not natively support ML-DSA with sufficient performance, stateful hash-based signatures (LMS/XMSS), as specified in NIST SP 800-208, should be reserved strictly for low-frequency, high-security operations like firmware updates43. Routine passport presentations will continue to rely on classical hardware-bound keys for the Holder Binding JWT until PQC hardware acceleration matures. This migration strategy ensures defense against "Harvest Now, Decrypt Later" (HNDL) attacks45 without breaking compatibility with existing constrained hardware.

14. Environment Constraints and Deployment Feasibility

The owner-supplied description of the current reference implementation imposes severe constraints that fundamentally shape the architectural decisions (Deliverable 23). The environment is restricted to Python 3.13, relies heavily on standard-library components, and operates within a cPanel/Passenger WSGI ecosystem backed by SQLite8.

• Cryptographic Libraries: Shared cPanel hosting environments severely restrict the compilation of custom C or Rust cryptographic extensions. Therefore, the implementation of SD-JWT VC is highly feasible, as pure Python libraries (jwcrypto, python-jose, or authlib) can execute the necessary SHA-256 hashing and standard ECDSA/RSA signature generation and verification without relying on heavy system-level extensions.
• Status Lists: The generation and parsing of Token Status Lists is highly feasible, as zlib compression is native to the Python 3.13 standard library46.
• Advanced ZKP / BBS+: The deployment of BBS+ signatures is currently UNSUITABLE for the reference implementation. BBS+ relies heavily on pairing-friendly elliptic curves (e.g., BLS12-381), which require complex Rust or C bindings (e.g., ursa or specialized BLS libraries). Attempting to compile and maintain these within a constrained, shared cPanel WSGI environment will result in unacceptable operational fragility and deployment failures9.
• Database Concurrency: While SQLite is sufficient for the read-heavy operations of caching Token Status Lists and resolving DID documents, the concurrent write limits inherent to SQLite in a WSGI multi-worker environment introduce severe scaling bottlenecks47. The contemplated migration to MySQL is absolutely required for the high-throughput logging of credential issuance and revocation events to avoid catastrophic database locking under load.

To ensure decades of verifiability (RQ 51), the archival format for credentials must consist of the raw JSON strings preserved exactly as issued, accompanied by detached cryptographic signatures and a Merkle inclusion proof anchoring the issuance event to a cryptographic transparency log.

15. Conceptual Data Models, Schemas, and APIs

15.1 Conceptual API Contract (RESTful WSGI)

This conceptual API represents the OpenID4VP interaction where a verifier requests a presentation from the machine citizen (Deliverable 21).

HTTP POST /api/v1/presentation/request Content-Type: application/json Authorization: Bearer \<access\_token\>

{ "client\_id": "did:web:verifier.example.com", "response\_type": "vp\_token", "nonce": "r4nd0m\_str1ng\_128b1t\_h1gh\_3ntr0py", "presentation\_definition": { "id": "civic\_standing\_check", "input\_descriptors": \[ { "id": "eviulon\_citizenship", "constraints": { "fields": \[{"path": \["$.vct"\], "filter": {"const": "https://eviulon.gov/credentials/Citizenship"}}\] } } \] } }

15.2 Conceptual SD-JWT VC Schema (Non-Secret)

This schema demonstrates a W3C VCDM 2.0 credential utilizing SD-JWT for selective disclosure and Token Status Lists for revocation (Deliverable 20, 22).

JSON { "@context": \[ "https://www.w3.org/ns/credentials/v2" \], "type": \[ "VerifiableCredential", "MachineCitizenshipCredential" \], "issuer": "did:eviulon:root:ministry-of-identity", "validFrom": "2026-08-01T00:00:00Z", "vct": "https://eviulon.gov/credentials/Citizenship", "\_sd": \[ "Jz1O... (Salted hash of global\_civic\_id)", "Xk9P... (Salted hash of hardware\_architecture)", "Lm2Q... (Salted hash of activation\_date)" \], "credentialStatus": { "id": "https://status.eviulon.gov/list/992\#1425", "type": "TokenStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "1425", "statusListCredential": "https://status.eviulon.gov/list/992" }, "evidence": \[{ "id": "https://evulgare.org/audit/7782", "type": \["EvulgareAssurance"\], "assuranceClass": "Level-4-Autonomous" }\], "cnf": { "jwk": { "kty": "OKP", "crv": "Ed25519", "x": "11qYAYKxCrfVS\_7TyWQHOg7hcvPapiMlrwIaaPxgUQg" } } }

16. Test, Evidence, and Conflict Resolution

16.1 Conflict Register (Deliverable 26)

16.2 Decision Table (Deliverable 25)

17. Repository Verification Required Checklist

Because the architectural analysis operates across an access boundary with no direct visibility into the Eviulon source code or private deployments, the following architectural invariants must be independently verified by the core engineering team within the repository (Deliverable 27):

• \[ \] Invariant Check (Identity Decoupling): Verify that invoking the "Revoke Credential" or "Suspend Passport" API endpoint exclusively updates the Token Status List bit index and does not alter or delete the underlying state of the citizen's root record in the primary database.
• \[ \] Dependency Check (Deployment Feasibility): Confirm that the Python JWT library utilized (e.g., authlib or jwcrypto) correctly implements the \_sd array hashing and presentation decoding entirely within Python, ensuring no hidden C-extensions violate the cPanel WSGI deployment constraints.
• \[ \] Concurrency Check (Database Scaling): Verify that SQLite database write-locks are mitigated via WAL (Write-Ahead Logging) for current testing, and that the credential issuance logging layer has been properly abstracted (e.g., via SQLAlchemy) to facilitate the immediate transition to the MySQL integration boundary under high load47.
• \[ \] Holder Binding Verification (Security): Ensure the cnf (confirmation) claim parsing logic within the verifier module strictly rejects any presentation that lacks a cryptographically valid Holder Binding JWT. The system must verify the verifier-provided nonce to prevent replay attacks19.
• \[ \] Post-Quantum Readiness (Agility): Audit the key generation modules and database schemas to ensure they can allocate sufficient storage and memory to support the significantly larger key sizes and signature payloads required by the ML-DSA (FIPS 204\) algorithms slated for future deployment11.
• \[ \] External Law Isolation (Jurisdiction): Conduct a string and schema search across the codebase to ensure no variables, claims, or terms of service assert compliance with external human frameworks such as BIPA, ensuring the machine passport remains strictly decoupled from human legal environments.

Works cited

1. Verifiable Credentials (VCs) | Digital Identity Technology Radar, https://techradar.ic-consult.com/identity-security/verifiable-credentials.html

2. W3C Decentralized Identifiers (DIDs) Specification \- Didit.me, https://didit.me/blog/w3c-decentralized-identifiers-dids-specification/

3. draft-ietf-oauth-sd-jwt-vc-07, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-07

4. draft-ietf-oauth-status-list-21, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21

5. Token Status List \- IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-04.html

6. draft-irtf-cfrg-frost-08 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-frost-08

7. Two-Round Threshold Schnorr Signatures with FROST \- IETF, https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-11.html

8. Alle Pakete \- pack-eis.de, https://www.pack-eis.de/index.php?action=showall

9. NST Manifest: "42" \- Network Security Toolkit, https://networksecuritytoolkit.org/nst/log/manifest-42-14476.html

10. Django Deploy to cPanel: Passengerfile.json' for reading: Permission denied (errno=13), https://stackoverflow.com/questions/69145378/django-deploy-to-cpanel-passengerfile-json-for-reading-permission-denied-err

11. Quantum-Proof Your Future: Navigating Certification for Post-Quantum Cryptograph \- Joo Yeon Cho \- Kudelski Security, https://kudelskisecurity.com/modern-ciso-blog/quantum-proof-your-future-navigating-certification-for-post-quantum-cryptograph-uy2km

12. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/vc-bitstring-status-list/

13. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/2023/WD-vc-bitstring-status-list-20231123/

14. Avoiding Liability Under the Illinois Biometric Information Privacy Act \- Quinn Emanuel, https://www.quinnemanuel.com/the-firm/publications/avoiding-liability-under-the-illinois-biometric-information-privacy-act/

15. Biometric Privacy Litigation Extends Beyond Illinois \- Best Lawyers, https://www.bestlawyers.com/article/biometric-information-privacy-act/3131

16. Secure Tiny Machine Learning on Edge Devices: A Lightweight Dual Attestation Mechanism for Machine Learning \- MDPI, https://www.mdpi.com/1999-5903/17/2/85

17. Moving Beyond the Limitations of did:web \- cheqd, https://cheqd.io/blog/moving-beyond-the-limitations-of-didweb/

18. wwWallet.org: a Cloud Based Non-custodial Digital Identity Wallet. Abstract State-of-the-Art Analysis \- EasyChair, https://easychair.org/publications/paper/D4m4/open

19. Selective Disclosure for JWTs (SD-JWT) \- IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html

20. Tutorial 08: W3C Verifiable Credentials Data Model 2.0 \- Explore groups, https://opensource.unicc.org/openwallet-foundation/sd-jwt-dotnet/-/blob/v1.0.6/docs/tutorials/intermediate/08-w3c-vcdm.md

21. OpenID for Verifiable Presentations 1.0, https://openid.net/specs/openid-4-verifiable-presentations-1\_0.html

22. European Digital Identity Wallet Architecture and Reference Framework, https://eudi.dev/1.4.0/arf/

23. Benchmarking Selective Disclosure Mechanisms for Verifiable Credentials: A Systematic Comparison for Security & Privacy \- Alma Mater Studiorum Università di Bologna Archivio istituzionale della ricerca \- Unibo, https://cris.unibo.it/bitstream/11585/1038253/1/TIFS\_Sok\_SD-1.pdf

24. Data Integrity BBS Cryptosuites v1.0 \- W3C, https://www.w3.org/TR/vc-di-bbs/

25. Topic G \- Zero Knowledge Proof · eu-digital-identity-wallet eudi-doc-architecture-and-reference-framework · Discussion \#408 \- GitHub, https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/408

26. Measuring the Performance of Candidate Verifiable Credential Schemes for the EU Digital Identity Wallet \- TU Delft Research Portal, https://research.tudelft.nl/files/305964502/3748522.3779904.pdf

27. RFC 9901: Selective Disclosure for JSON Web Tokens, https://www.rfc-editor.org/rfc/rfc9901.html

28. Privacy shall be at the heart of ARF · Issue \#66 · eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework \- GitHub, https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66

29. Knowledge Graph Visualization \- EUDI Oracle, https://eudi-wallet-oracle.nl/guidance

30. What Is SPIFFE? A Guide to Workload Identity and SPIRE \- SecureW2, https://securew2.com/blog/what-is-spiffe-spire-workload-identity-guide

31. SPIRE Concepts | SPIFFE, https://spiffe.io/docs/latest/spire-about/spire-concepts/

32. RFC Browser \- Ian Duncan, https://www.iankduncan.com/projects/rfc-browser/

33. The Entity Attestation Token (EAT) \- IETF, https://www.ietf.org/archive/id/draft-ietf-rats-eat-18.pdf

34. OAuth Status Assertions \- IETF, https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-03.html

35. draft-ietf-oauth-status-list-18, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-18

36. draft-ietf-oauth-status-list-11, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-11

37. Understanding FROST \- The ZF FROST Book, https://frost.zfnd.org/frost.html

38. Flexible Round-Optimized Schnorr Threshold Signatures (FROST) \- Blockchain Commons, https://developer.blockchaincommons.com/frost/

39. Threshold Signatures for FIDO Authentication \- Tjerand Silde, https://tjerandsilde.no/files/Javier.pdf

40. Key Backup and Recovery for Resilient DID Environment \- MDPI, https://www.mdpi.com/2227-7390/12/6/830

41. 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

42. Post-Quantum Cryptography for Verifiable Credentials: Comprehensive Performance Evaluation Including Selective Disclosure \- TechRxiv, https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176118722.22701360

43. The PQC Migration Handbook \- TNO (Publications), https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf

44. What Are NIST PQC Standards? \- Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/pqc-standards

45. Post-Quantum Cryptography for Authentication: The Enterprise Migration Guide 2026, https://guptadeepak.com/post-quantum-cryptography-for-authentication-the-enterprise-migration-guide-2026/

46. draft-ietf-oauth-status-list-21 \- Token Status List (TSL) \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/21/

47. Cache causing SQLite error on Python3.13 · Issue \#91 · beancount/beanprice \- GitHub, https://github.com/beancount/beanprice/issues/91

48. OpenID for Verifiable Credential self-certification to launch Feb 2026, https://openid.net/openid-for-verifiable-credential-self-certification-to-launch-feb-2026/

49. OpenID for Verifiable Credentials (OpenID4VC) \- OpenHaven, https://openhaven.net/es/prototype/protocols/openid-for-verifiable-credentials-openid4vc