When Patefacere Adds Value: A Comparative Interoperability and Alternatives Analysis

Full report

On this page

The enterprise and decentralized identity landscape of August 2026 represents a critical inflection point in cryptographic trust, workload authorization, and verifiable data provenance. Following the formal standardization of Selective Disclosure for JSON Web Tokens (SD-JWT) via RFC 9901 in late 20251, the maturation of Authentic Chained Data Containers (ACDC) v1.13, and the legal codification of smart contracts under frameworks such as the Illinois Blockchain Technology Act5, the architectural options for identity administration have grown vastly complex. This report provides an exhaustive architectural, operational, and interoperability analysis of thirteen identity and authorization paradigms. It treats Patefacere—a conceptual operational identity and civic-data architecture rooted in radical transparency, derived from the Latin etymology patefacere ("to open" or "to reveal")8—as a proposed architecture whose value must be rigorously demonstrated against established alternatives, identifying both its theoretical utility and its potentially irrational adoption cases.

The 13-Option Comparative Architectural Analysis

The following sections evaluate thirteen distinct identity and authorization architectures, assessing their utility, maturity, and relationship to the proposed Patefacere framework.

1. Local Keys and Custom Code

The deployment of local keys and custom authentication code represents the most rudimentary form of access control, typically involving hardcoded secrets, symmetric keys, or proprietary token-generation scripts embedded directly within application logic. This approach solves immediate, zero-infrastructure machine-to-machine (M2M) authentication within closed, monolithic systems, allowing disparate scripts to communicate without relying on external directories. However, it does not solve scalability, cryptographic key rotation, rapid revocation, cross-domain trust federation, or human identity binding. The technical maturity of this approach is paradoxically high yet inherently unstandardized, relying entirely on the competence of the individual developer. Operational complexity is initially extremely low, but it scales to computationally and administratively unmanageable levels as the system grows, eventually creating an unmaintainable web of secrets. Vendor dependence is entirely non-existent. The failure modes of this architecture are catastrophic; hardcoded keys are frequently leaked in code repositories, and the inability to rotate secrets without application downtime leads to prolonged vulnerabilities and the complete absence of centralized audit trails. Privacy is largely irrelevant for pure M2M interactions, but the architecture becomes highly problematic if custom logic attempts to handle personally identifiable information (PII) without standard protections. Recovery from a breach is a manual, out-of-band process requiring code deployments. The legal effect of custom local keys is minimal, lacking the non-repudiation and standardized cryptographic receipts required for regulatory compliance. The cost structure features negligible capital expenditure (CapEx) but poses the risk of catastrophic operational expenditure (OpEx) during security incidents. Local keys are only sufficient for isolated, ephemeral scripts, local development environments, or entirely air-gapped embedded systems with no external communication requirements. In these low-risk, stateless microservices where identity state is irrelevant, Patefacere would be entirely unnecessary. The leap from local keys to a radical civic-data transparency mesh is an irrational over-engineering failure; Patefacere would never add distinct value to a domain where simple local secrets suffice.

2. Enterprise IAM (Identity and Access Management)

Enterprise IAM systems form the backbone of modern corporate security perimeters, offering centralized user lifecycle management, single sign-on (SSO), and internal compliance auditing. This architecture solves the massive administrative burden of onboarding, authenticating, and offboarding human employees across hundreds of disparate SaaS applications. It does not, however, solve multi-party supply chain provenance, decentralized capability delegation, or offline verification, as it inherently requires a persistent connection to a centralized Identity Provider (IdP). The technical maturity of Enterprise IAM is extremely high, dominated by established protocols and platforms. Operational complexity is medium, requiring dedicated directory management, user group synchronization, and constant access policy refinement. Vendor dependence is exceptionally high, as vendor lock-in remains the industry norm; migrating between major IdPs requires significant engineering effort. Failure modes include centralized single points of failure (IdP outages blocking all corporate access), directory synchronization conflicts, and broad privilege escalation if administrative accounts are compromised. Privacy within an Enterprise IAM framework is weak by design, as the IdP possesses absolute, global visibility into all user authentications and access patterns. Recovery relies on administrator-driven password resets, account lockouts, and manual session termination. The legal effect of IAM records is robust for internal HR compliance, SOC 2 auditing, and standard business-to-business non-disclosure enforcement. Costs involve high, recurring per-user licensing fees. Enterprise IAM is entirely sufficient for internal corporate workforces, standard web application access, and bounded organizational perimeters. When an organization maintains absolute legal and operational control over all its users and relying parties, Patefacere would be profoundly unnecessary. Patefacere might only add distinct value if an enterprise explicitly seeks to dismantle internal private silos in favor of a universally transparent, unmasked corporate citizenship model—a paradigm shift that directly contradicts standard, privacy-preserving IAM design.

3. OAuth/OIDC (OpenID Connect)

OAuth 2.1 and OpenID Connect (OIDC) function as the universal standards for delegated authorization and federated single sign-on across the open web. This architecture solves the problem of granting third-party applications limited access to user resources without exposing credentials, streamlining consumer SSO and securing RESTful APIs. It does not solve holder-side scope attenuation, offline capability verification, or non-repudiable multi-hop data provenance, as tokens remain tightly coupled to the issuing authorization server10. Technical maturity is ubiquitous, forming the foundation of modern web authentication. Operational complexity ranges from low to medium, supported by universally available libraries and managed services. Vendor dependence is medium; while the protocols are standardized, implementations are often tied to specific authorization server vendors. Failure modes include token theft, authorization code interception, scoped access creep, and the inherent latency in opaque token revocation. Privacy is a vulnerability, as the central IdP tracks all cross-site logins unless pairwise pseudonymous identifiers are strictly enforced. Recovery mechanisms involve session revocation, refresh token cycling, and user-initiated consent withdrawal. The legal effect is generally accepted across the industry, though it relies more on accepted terms of service and access logs than on mathematically binding cryptographic non-repudiation. Cost scales from low (utilizing open-source servers) to medium (relying on managed SaaS providers). OIDC is sufficient for standard consumer-facing web architectures, basic API security, and mobile application authorization requiring synchronous token validation. In environments requiring standard authentication without complex multi-hop delegation, Patefacere would be entirely unnecessary. Patefacere might add distinct value only when authorization must transcend standard HTTP boundaries, requiring the embedding of continuous, offline civic accountability and absolute transparency that ephemeral OIDC bearer tokens cannot carry.

4. mTLS and PKI (Public Key Infrastructure)

Mutual Transport Layer Security (mTLS) backed by Public Key Infrastructure (PKI) represents the foundational standard for cryptographic network security. It solves the need for strong transport-layer encryption, mutual authentication between servers, and centralized trust anchored by Certificate Authorities (CAs). However, PKI does not solve fine-grained application-level authorization, user intent verification, or data-payload provenance, as it strictly authenticates the transport channel rather than the underlying message. Technical maturity is foundational and universally deployed. Operational complexity is notoriously high; certificate lifecycle management, revocation list (CRL/OCSP) infrastructure, and secure key distribution remain fragile operational pain points12. Vendor dependence is low in terms of software, though public trust relies entirely on an oligopoly of root CAs. Failure modes are well-documented and severe, predominantly involving expired certificates causing cascading infrastructure outages, compromised intermediate CAs, and CRL synchronization failures12. Privacy is generally poor; certificates explicitly identify workloads, domains, or users in plaintext Subject Alternative Names (SANs) with no capacity for selective disclosure. Recovery requires immediate certificate revocation, generation of new signing requests, and redeployment of the new certificates across the infrastructure. The legal effect is exceptionally high, as e-signatures and communications backed by regulated PKI carry strong statutory weight globally. The cost involves high operational expenditure for continuous lifecycle management. PKI and mTLS are completely sufficient for infrastructure-to-infrastructure security, encrypting transport layers, and enabling zero-trust network access (ZTNA) at the network perimeter. When the sole requirement is wire-level encryption between known servers, Patefacere would be unnecessary. Patefacere might add distinct value only when cryptographic trust must transition from the opaque transport layer to the semantic data layer, binding the intent of a payload to radical organizational transparency rather than simply securing the transmission wire.

5. SPIFFE/SPIRE

The Secure Production Identity Framework for Everyone (SPIFFE) and its runtime environment (SPIRE) provide a unified, secretless identity plane for dynamic, cloud-native workloads. This architecture solves the challenges of dynamic workload identity, automated cryptographic key rotation, and M2M authentication across highly heterogeneous environments (Kubernetes, VMs, serverless)10. It does not solve human identity authentication, long-lived off-network credentials, or verifiable multi-party data supply chains. Technical maturity is high, having achieved graduated status within the Cloud Native Computing Foundation (CNCF). Operational complexity is high, requiring dedicated SPIRE server and agent infrastructure, precise node attestation rules, and continuous trust bundle synchronization. Vendor dependence is low due to a robust open-source ecosystem. Failure modes revolve around node attestation failures (where a workload cannot prove its origin), trust bundle synchronization errors across federated domains, and SPIRE server network partitions preventing the issuance of short-lived verifiable identity documents (SVIDs). Privacy is inapplicable, as the system is explicitly designed for machine workloads rather than human actors. Recovery is automated through continuous, short-lived SVID rotation, ensuring compromised keys expire rapidly. The legal effect is non-existent outside of internal IT security and compliance policies; SVIDs hold no jurisdictional weight. Cost consists primarily of high engineering and infrastructure overhead, with zero licensing fees. SPIFFE/SPIRE is the definitive and sufficient solution for Kubernetes-to-VM workload authentication inside an enterprise or cloud boundary. When identity strictly involves ephemeral software agents within a controlled datacenter, deploying Patefacere would be an irrational addition of civic overhead. Patefacere might add distinct value only if internal workload identity must suddenly transition into legally binding, auditable actions carrying external jurisdictional weight, bridging the gap between microservices and civic accountability.

6. SCIM and Directory Systems

The System for Cross-domain Identity Management (SCIM) is a standardized protocol for automating the exchange of user identity information between identity domains or IT systems. It solves the operational bottleneck of automated user provisioning, de-provisioning, and cross-domain synchronization of user attributes. It does not solve authentication, runtime authorization, offline cryptographic trust, or user sovereignty over personal data. Technical maturity is high, widely adopted across all major SaaS platforms and IdPs. Operational complexity is medium, primarily involving attribute mapping, endpoint configuration, and conflict resolution during synchronization. Vendor dependence is high, as SCIM implementations are invariably tied to the capabilities and limitations of the primary directory ecosystems (e.g., Active Directory, Azure, Google Workspace). Failure modes include synchronization lag leading to unauthorized access, orphaned accounts remaining active post-termination, and schema mapping errors that corrupt directory data. Privacy is intrinsically low, as directory systems act as centralized honeypots of PII, freely syncing this data to downstream SaaS providers. Recovery involves overwriting stale or corrupted data via a forced IdP push. The legal effect is highly relevant for compliance auditing (e.g., Sarbanes-Oxley), proving that access was terminated promptly, but SCIM payloads lack inherent cryptographic signatures per attribute. Cost is medium, generally bundled into enterprise IAM licensing. SCIM is entirely sufficient for synchronizing employee databases to downstream SaaS applications to maintain internal corporate hygiene. For standard HR onboarding and offboarding flows, Patefacere would be entirely unnecessary. Patefacere might add distinct value only when the concept of "citizenship administration" supersedes mere "account provisioning," requiring persistent, self-certifying civic state that is publicly auditable, rather than a hidden synchronization between corporate servers.

7. W3C DIDs and Verifiable Credentials

The W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) data models provide a framework for self-sovereign identity and decentralized public key infrastructure (DPKI). This architecture solves the need for portable, cryptographic claims, decoupling the issuer from the verifier, and enabling users to hold their own credentials in digital wallets. It does not solve universal privacy (if legacy JSON-LD formats without zero-knowledge proofs are misused), seamless mainstream user experience, or offline multi-hop delegation loops11. Technical maturity is medium-high, with the W3C v2.0 standards achieving widespread institutional recognition by 2026\. Operational complexity is high, requiring the establishment of DID method resolution infrastructure, compatible wallet ecosystems, and trusted credential registries. Vendor dependence is theoretically low, though wallet fragmentation remains an issue. Failure modes include ledger unavailability for DID document resolution, catastrophic loss of private wallet keys, and format incompatibility between differing VC serialization methods. Privacy can be exceptionally high if paired with selective disclosure mechanisms or zero-knowledge proofs (ZKPs). Recovery is notoriously complex, often requiring social recovery mechanisms or multisig setups, frequently resulting in permanent credential loss if mismanaged. The legal effect is rapidly increasing, formally recognized under eIDAS 2.0 frameworks and emerging state-level digital asset laws6. Cost features a low variable cost per credential but a high initial CapEx for system integration. DID/VC ecosystems are sufficient for cross-border digital wallets, academic credentialing, and decentralized physical infrastructure networks (DePIN). When a simple, bilateral credential exchange (such as presenting a digital driver's license) is required without enforcing radical contextual transparency, Patefacere would be unnecessary. Patefacere might add distinct value when highly fragmented DID/VC ecosystems require a unified, transparent jurisdictional layer to assign civic consequence to the credentials, prioritizing objective public truth over sovereign isolation.

8. SD-JWT VC and Selective-Disclosure Systems

Standardized in November 2025 via RFC 9901, the Selective Disclosure for JSON Web Tokens (SD-JWT) framework allows issuers to create credentials where the holder can selectively reveal individual claims to a verifier1. This solves the privacy paradox of standard JWTs by enabling granular disclosure using salted hash commitments and decoy digests to prevent structural inference1. It does not solve multi-hop capability delegation, Datalog-style constrained execution, or systemic identity resolution10. Technical maturity is high, operating as an IETF Standards Track technology widely adopted in 20261. The dc+sd-jwt media type, formalized in Draft 18, ensures interoperability across digital credential ecosystems16. Operational complexity is medium, requiring precise cryptographic management of salts, \_sd arrays, and Key Binding JWTs (KB-JWT) to prove possession1. Vendor dependence is low, based on open standards. Failure modes include verifier failure to enforce key binding, or the reuse of salts by issuers, which enables rainbow table attacks against the blinded claims1. Privacy is exceptionally high, actively enforcing the principle of data minimization and minimizing over-sharing15. Recovery requires complete credential re-issuance by the original IdP if the SD-JWT or the associated device keys are lost. The legal effect is high, specifically serving as the mandated credential format for EU Digital Identity (EUDI) Wallet compliance19. Cost is low, leveraging existing JWT infrastructure. SD-JWT VCs are entirely sufficient for privacy-preserving digital identities, such as cryptographic age verification that explicitly hides the user's name and exact birthdate2. For consumer privacy use cases where hiding data is the explicit architectural goal, Patefacere would be unnecessary. Patefacere might add distinct value only when an ecosystem rejects privacy entirely; because Patefacere's etymological directive is "to open,"9 it fundamentally opposes SD-JWT's privacy-first obfuscation, adding value only where absolute, unmasked truth is the primary requirement.

9. KERI/ACDC (Key Event Receipt Infrastructure)

The Authentic Chained Data Containers (ACDC) specification, operating atop the Key Event Receipt Infrastructure (KERI), provides a framework for quantum-resilient M2M data provenance without relying on blockchain consensus3. This solves the problem of verifying multi-tier data supply chains, utilizing Self-Addressing Identifiers (SAID) and cryptographic pre-rotation of keys to establish trust independently of centralized registries3. It does not solve global standard consensus outside of specific consortiums (e.g., the GLEIF vLEI ecosystem)20. Technical maturity is medium, with the Trust Over IP (ToIP) specifications maturing significantly between 2024 and 20264. Operational complexity is high; implementing the Composable Event Streaming Representation (CESR) encoding and managing SAID derivations require specialized, emerging cryptographic libraries3. Vendor dependence is low. Failure modes include key pre-rotation desynchronization resulting in orphaned identifier chains, and complex CESR parsing faults. Privacy is high, natively supporting chain-link confidentiality and selective disclosure mechanisms without sacrificing graph integrity3. Recovery is cryptographically native, achieved via the key pre-rotation mechanisms embedded within the Key Event Log (KEL). The legal effect is high in specialized, regulated domains, notably as the foundation for the verifiable Legal Entity Identifier (vLEI) for corporate identity21. Cost is medium. KERI and ACDC are highly sufficient for multi-tier supply chain provenance, decentralized organizational identity, and mathematically auditable data chains. When deterministic mathematical provenance of data is sufficient without requiring a social or jurisdictional wrapper, Patefacere would be unnecessary. Patefacere might add distinct value by utilizing KERI as its underlying cryptographic plumbing; Patefacere could act as the civic governance layer that consumes ACDCs to administer visible "citizenship" or network exit protocols based on the cryptographic facts.

10. Capability Tokens and Macaroons (Biscuit, IBCTs)

Capability tokens, specifically modern iterations like Biscuit and Invocation-Bound Capability Tokens (IBCTs), fuse identity and attenuated authorization into a single, append-only token chain10. This architecture solves the need for offline, multi-hop delegation, allowing a holder to dynamically restrict the scope of a token before passing it to a downstream service, utilizing expressive Datalog policies and Ed25519 signatures10. It does not solve global identity resolution, human authentication, or session management. Technical maturity is medium, seeing rapid adoption for autonomous agentic AI (A2A protocols) and high-speed microservices throughout 2025 and 202625. Operational complexity is medium; while the cryptography is robust, authoring logic constraints in Datalog requires specialized syntax knowledge24. Vendor dependence is low. Failure modes include logic evaluation failures, infinite loops in poorly authored Datalog facts, and max-depth exhaustion in extensive delegation chains10. Privacy is inherently low, as the delegation chain explicitly exposes the entire path of capability transfer to the final verifier. Recovery is simplified by design; short-lived tokens negate the need for complex revocation infrastructure, relying instead on rapid time-to-live (TTL) expiration. The legal effect is unclear, as the policies are highly technical and lack human-readable intent. Cost is low. Capability tokens are perfectly sufficient for autonomous AI agent delegation, API authorization, and distributed resource control where calling a centralized server is impossible or too slow. For high-speed, ephemeral machine operations, Patefacere would be unnecessary. Patefacere might add distinct value if these autonomous machine agents require continuous behavioral audits governed by a human-jurisdictional overseer, enveloping the machine-speed Biscuit tokens within a broader civic accountability framework.

11. Offline Signed Manifests

Offline signed manifests, such as software bills of materials (SBOMs) managed via tools like Sigstore, provide an immutable, air-gapped distribution mechanism for trusted software or configurations. This architecture solves the requirement for static asset verification, ensuring that a binary or configuration file has not been tampered with since it was cryptographically signed by the developer. It does not solve real-time state checks, dynamic identity interactions, or instantaneous revocation. Technical maturity is very high, representing the industry standard for software supply chain security. Operational complexity is low, integrating seamlessly into CI/CD pipelines. Vendor dependence is entirely non-existent. Failure modes primarily involve the compromise of the developer's signing key, coupled with the inability to push rapid revocations to deeply air-gapped environments. Privacy is non-applicable, as manifests are designed to publicly identify the software components. Recovery involves out-of-band updates, deploying newly signed manifests alongside firmware patches. The legal effect is vital, directly satisfying software supply chain compliance requirements mandated by government procurement regulations. Cost is low. Signed manifests are entirely sufficient for firmware updates, container image verification, and static asset integrity checks. For basic software supply chain assurance, Patefacere would be completely unnecessary. Applying a complex civic identity and transparency framework to a static software manifest represents massive architectural bloat; Patefacere adds zero distinct value to this domain.

12. Human-Jurisdiction Corporate Wrappers

The traditional human-jurisdiction corporate wrapper (e.g., an LLC, C-Corp, or formalized Decentralized Autonomous Organization under state law) serves to tether digital and physical actions to real-world legal liability. This solves the fundamental problem of physical recourse, allowing entities to own physical assets, engage in fiat banking, and be sued in a court of law. It does not solve the cryptographic enforcement of rules, automation, or the speed of deterministic execution. Technical maturity is ancient, rooted in centuries of corporate law, though recently updated by frameworks like the Uniform Commercial Code (UCC) Article 12, which recognizes Controllable Electronic Records (CERs)6. Operational complexity is extremely high, requiring lawyers, courts, and continuous regulatory filings. Vendor dependence is tied to the specific state or sovereign jurisdiction. Failure modes include systemic fraud, bankruptcy, jurisdictional arbitrage, and slow judicial resolution. Privacy varies wildly based on the transparency laws of the specific corporate registry. Recovery requires judicial intervention and court orders. The legal effect is absolute within the sovereign domain of the state. Cost is very high, factoring in legal retainers, filing fees, and compliance costs. Corporate wrappers are absolutely sufficient for traditional commerce, high-stakes fiat transactions, and physical asset management. For standard physical business operations with no decentralized digital trust requirements, Patefacere would be unnecessary. Patefacere might add distinct value by serving as a bridge; blending the legal wrapper with cryptographic transparency systems to act as the interface between analog court systems and digital ledgers, effectively operationalizing laws like the Illinois Blockchain Technology Act by providing irrefutable, transparent digital evidence7.

13. Patefacere Concepts

The Patefacere concept operates on a radical philosophical directive: to open, to reveal, and to enforce absolute transparency. Drawing on the etymology of patefacere and Agamben's philosophical propositions regarding the exposure of the false to allow truth to "take place,"8 Patefacere proposes a civic-data architecture that fundamentally rejects obfuscation. It solves the need for an unmasked organizational identity where every actor's intent, origin, and nature is laid bare, enabling undeniable public accountability. It explicitly does not solve standard privacy requirements, zero-knowledge constraints, or ephemeral, low-stakes machine communications. Technical maturity is purely conceptual and proposed as of 2026\. Operational complexity would theoretically be massive, requiring a complete paradigm shift in how relying parties consume, store, and act upon identity data. Vendor dependence would be high if operated as a proprietary or tightly governed mesh. Failure modes are uniquely severe, primarily involving massive privacy violations, total civic excommunication without recourse, and un-attenuated data spillage. Privacy is inherently opposed and actively destroyed in favor of total transparency; the architecture views privacy as a mechanism that harbors "non-truth."8 Recovery relies on social consensus or civic tribunal appeal rather than simple cryptographic resets. The legal effect could be immensely high if the transparency mesh is legally recognized as a binding arbitration or governance framework. Cost would be exceptionally high. Patefacere is only sufficient—and justified—when an ecosystem demands absolute, non-repudiable visibility into the intent and nature of all actors, prioritizing systemic, objective truth over individual privacy. For 99% of conventional enterprise, consumer, and M2M architectures, Patefacere would be vastly unnecessary and dangerously exposing. Patefacere might add distinct value exclusively in high-stakes public interest infrastructure, decentralized autonomous organization (DAO) governance, and specific supply chains where obfuscation actively enables corruption or human rights abuses.

30-Capability by 13-Option Comparison Matrix

The following matrix evaluates the 13 architectures against 30 critical identity and authorization capabilities, providing a deterministic view of their functional reach. Scoring Legend: Native (N), Partial/Bolt-on (P), None/Inapplicable (X).

\*Note on Capabilities 6 and 30: Patefacere actively rejects Selective Disclosure and Zero-Knowledge Proofs, as cryptographic obfuscation contradicts its foundational architectural mandate of absolute transparency and the "taking-place of the false"8.

Architectural Thresholds

When Ordinary IAM Is Enough

Standard Enterprise IAM (coupled closely with OIDC and SCIM) remains entirely sufficient when the cryptographic trust boundary is congruent with the legal and operational boundary of the corporation. If an enterprise issues the paychecks, provisions the corporate devices, and controls the SaaS contracts, introducing decentralized identifiers, ACDC chains, or Patefacere is an irrational, costly boondoggle. Traditional IAM excels precisely because of its centralization: it allows for rapid employee provisioning, streamlined compliance reporting for frameworks like SOC 2, and immediate, centralized kill-switches upon employee termination. It fails only when trust must cross borders without a central arbiter. Therefore, for internal workforce management, Ordinary IAM is the terminal requirement.

When SPIFFE/SPIRE Is Enough

SPIFFE/SPIRE is the definitive solution for internal datacenter and cloud-native workload identity. When microservices, Kubernetes pods, and databases need to authenticate to one another securely without relying on hardcoded secrets or static IP addresses, SPIRE's automated SVID rotation and mTLS provisioning are unmatched. Attempting to use complex verifiable credentials or a Patefacere transparency mesh for ephemeral pod-to-pod communication introduces catastrophic latency and unnecessary philosophical overhead. If the entity demanding access is a piece of software executing within a controlled environment, SPIFFE/SPIRE is entirely enough.

When DID/VC Is Enough

W3C DIDs and VCs—specifically utilizing the SD-JWT VC format standardized under RFC 9901—are sufficient for scenarios demanding self-sovereign data exchange where user privacy is paramount1. Prime examples include the deployment of mobile driver's licenses, healthcare credentialing, and decentralized physical infrastructure networks (DePIN). These technologies elegantly solve the "phone-home" tracking problem, preventing issuing authorities from observing when and where credentials are presented. If the architectural goal is minimizing the user's data footprint while proving specific claims to a relying party, SD-JWT VCs fulfill the requirement completely.

What Patefacere Must Demonstrate to Justify Adoption

Patefacere operates on the strict philosophical directive of patefacere—to open, to reveal, and to give space to truth through the exposure of the false9. As a technical architecture, this vehemently opposes the prevailing enterprise trends of zero-knowledge, data minimization, and selective disclosure1. To justify its immense operational complexity and the deliberate destruction of cryptographic obfuscation, Patefacere must demonstrate three critical factors:

1. Systemic Corruption in the Status Quo: It must prove that existing obfuscated systems (such as SD-JWT or opaque corporate wrappers) are actively enabling fraud, systemic risk, or human rights abuses that only radical, public transparency can cure.

2. Legal Enforcement Integration: It must tie its transparency engine directly to real-world jurisdictions. For example, anchoring Patefacere records as admissible evidence under the Illinois Blockchain Technology Act ensures that "unmasking" an actor has actionable legal and financial consequences5.

3. Civic Adoption Velocity: It must prove that specific communities—such as high-stakes DAOs, heavily regulated supply chains, or civic institutions—actually desire radical openness and are willing to sacrifice privacy for absolute accountability.

If it cannot demonstrate these three pillars, Patefacere risks being categorized merely as a philosophical art project rather than a viable, operational enterprise architecture.

Standards-Currentness Table (As of August 2026)

To provide context for procurement and integration decisions, the following table tracks the maturity and core mechanisms of identity standards as of August 2026\.

Procurement Decision Tree

When architecting a system in 2026, enterprise architects and procurement analysts should follow this deterministic decision matrix to prevent over-engineering and irrational technology adoption.

1. Is the interaction purely Machine-to-Machine (M2M) within a secure, controlled network boundary?

• Yes: Procure and deploy SPIFFE/SPIRE for automated mTLS workload identity.
• No: Proceed to 2\.

2. Does the authorization model require multi-hop delegation without contacting a centralized authorization server?

• Yes: Utilize Biscuit tokens (IBCT) to leverage Datalog-driven holder-side attenuation10.
• No: Proceed to 3\.

3. Is the primary requirement managing human employees accessing internal and external SaaS applications?

• Yes: Procure standard Enterprise IAM (e.g., Okta, Entra ID) integrated with OIDC and SCIM. Do not reinvent the wheel.
• No: Proceed to 4\.

4. Are you issuing digital credentials to consumers who require high privacy and minimal disclosure?

• Yes: Implement SD-JWT VC (RFC 9901\) to allow selective disclosure, utilizing decoy digests to prevent tracking and structural inference2.
• No: Proceed to 5\.

5. Do you require multi-party, quantum-resilient, verifiable data provenance chains (e.g., a hardware supply chain)?

• Yes: Architect the solution using KERI and ACDC to establish a verifiable data graph4.
• No: Proceed to 6\.

6. Does the system demand absolute, radical civic transparency where actors must be fully unmasked and accountable to an objective public truth?

• Yes: Patefacere adds distinct value and should be explored as the foundational governance layer.
• No: The use case falls into traditional identity management; adopting Patefacere would be disastrously complex and unnecessary.

Maturity Model: Identity Architecture

This maturity model maps the evolution of identity architectures from static silos to autonomous, verifiable transparency meshes.

1. Level 1: Siloed & Static. Characterized by local keys, hardcoded credentials, and fragmented directories. Presents a high risk of catastrophic breach with manual, error-prone recovery processes.

2. Level 2: Federated & Centralized. Characterized by Enterprise IAM, OIDC, and SCIM. Centralized trust is established, and SSO is enabled, but this introduces severe vendor lock-in, privacy vulnerabilities, and singular points of failure.

3. Level 3: Dynamic & Automated. Characterized by SPIFFE/SPIRE for workloads and dynamic OAuth scopes. Operates on zero-trust network principles utilizing secretless architectures and automated, short-lived tokens.

4. Level 4: Verifiable & Sovereign. Characterized by SD-JWT VCs, KERI, and W3C DIDs. Trust is decentralized, cryptographic provenance is established, and privacy is preserved through selective disclosure mechanisms1.

5. Level 5: Autonomous & Transparent. Characterized by Biscuit multi-hop agent delegation10 converging with Patefacere civic meshes. High-speed AI delegation is matched with radical human-jurisdictional transparency and self-executing legal wrappers, eliminating obfuscation in favor of absolute accountability.

60 Deterministic Interoperability Scenarios

The following table details 60 precise interoperability interactions across the evaluated identity domains, mapping source architectures to targets and defining the deterministic outcome of their interaction.

24 Package-Exchange Scenarios

The following scenarios outline the technical transformation and exchange of identity data packages between differing serialization formats and protocols.

24 Migration and Downgrade Scenarios

System architecture frequently requires falling back to less complex, legacy, or stripped-down states. These scenarios map the architectural impact of migrations and downgrades.

Primary-Source Literature Review

To ground the architectural assertions in this report, the following core specifications and legal frameworks from 2025–2026 are deterministically referenced throughout the analysis. This review synthesizes the primary research shaping the current identity landscape:

• RFC 9901 (Selective Disclosure for JWTs): Finalized in November 2025 by the IETF OAuth Working Group, this specification establishes the standard for salted hash commitments and array-element disclosures in JSON payloads, allowing holders to disclose claims selectively without relying on heavy Zero-Knowledge Proofs1.
• draft-ietf-oauth-sd-jwt-vc (Verifiable Digital Credentials): Advancing to Draft 18 in late 2026, this specification pivoted the typ header from vc+sd-jwt to dc+sd-jwt to prevent collision with W3C standards, while precisely defining Key Binding JWT (KB-JWT) integration16.
• Authentic Chained Data Containers (ACDC): Maturing to v1.1 under the Trust Over IP (ToIP) Foundation, this specification utilizes CESR (Composable Event Streaming Representation) and SAIDs (Self-Addressing Identifiers) to enable quantum-resilient, blockchain-free M2M data provenance3.
• Biscuit / IBCT (Invocation-Bound Capability Tokens): Formalizing Datalog-based multi-hop delegation for Agent-to-Agent (A2A) interactions in 2026, this framework natively supports holder-side scope attenuation without requiring external server calls10.
• Illinois Blockchain Technology Act (BTA) & UCC Article 12: These legal frameworks establish the statutory validity of controllable electronic records and blockchain-verified evidence, bridging the gap between cryptographic execution (smart contracts) and traditional state law5.
• Agamben's Philosophical Framework: The etymological and philosophical foundation of the proposed Patefacere architecture, drawing heavily on the concept of the "coming community" and the absolute exposure of the false to allow truth to "take place," fundamentally rejecting obfuscation8.

Forty FAQs

1\. What is the fundamental difference between SD-JWT and ACDC? SD-JWT (RFC 9901\) focuses entirely on privacy-preserving, selective disclosure of flat or nested JSON data for human-centric identity1. ACDC focuses on cryptographically verifiable, multi-hop data provenance graphs for organizational and supply chain trust20. 2\. Why was vc+sd-jwt changed to dc+sd-jwt in 2026? The IETF changed the media type to avoid namespace collisions with the W3C Verifiable Credentials Data Model, reflecting a broader scope for Verifiable Digital Credentials17. 3\. How does Biscuit achieve offline delegation? Biscuit uses Ed25519 signatures to append new cryptographic blocks to a token. Each block contains Datalog facts that can only attenuate (restrict) the previous scopes. The verifier checks the signature chain and evaluates the logic entirely locally10. 4\. What is the Illinois Blockchain Technology Act (BTA)? A state law enacted to explicitly prohibit courts from denying legal effect to a smart contract, electronic record, or signature solely because it resides on a blockchain or distributed ledger5. 5\. Does the BTA mean "code is law"? No. A smart contract must still satisfy traditional common law elements (offer, acceptance, consideration). Code executes autonomously, but the law strictly governs enforceability and recourse6. 6\. What is Patefacere's core thesis? Rooted in the etymology "to open," it argues that truth is established not by verifying isolated facts, but by exposing absolute context, stripping away anonymity, and embracing radical accountability8. 7\. Can Patefacere comply with GDPR? It is highly unlikely, as radical transparency and immutable public tracking inherently conflict with the right to be forgotten and data minimization principles mandated by European law. 8\. How do decoy digests work in RFC 9901? An issuer injects random, cryptographically meaningless hashes into the \_sd array alongside real claim hashes. This prevents an attacker from guessing how many undisclosed claims exist in the credential1. 9\. What is Key Binding in SD-JWT? Key Binding ensures the presenter of the SD-JWT is the legitimate holder by requiring them to sign a transaction payload (KB-JWT) using a private key linked in the credential1. 10\. How does SPIFFE attest a workload? SPIRE agents interrogate the local operating system kernel (e.g., checking cgroups, namespaces) to verify the exact binary running before issuing an SVID to that workload. 11\. Why use KERI over W3C DIDs? KERI relies entirely on cryptographic event logs and self-addressing identifiers, avoiding the governance, performance, and centralization issues inherent in blockchain-based DID registries4. 12\. What happens if a KERI key is stolen? Because KERI utilizes key pre-rotation (publishing the hash of the next key before it is used), an attacker who steals the current key cannot control the identifier if the owner rotates to the pre-committed key first. 13\. How does SCIM handle identity? SCIM strictly handles the automated synchronization of user identity attributes (Name, Title, Group) between a central directory and downstream applications; it does not handle authentication. 14\. Are capability tokens (Biscuit/Macaroons) bearer tokens? Yes, but unlike OAuth bearer tokens, they carry their own verifiable attenuation logic, making them vastly safer if intercepted and repurposed outside their constrained context10. 15\. Can an Enterprise IAM provider implement Patefacere? Theoretically, yes, but it would require completely flipping their access paradigm from "deny all, hide all" to "allow all visibility, audit everything." 16\. What is a SAID? A Self-Addressing Identifier is generated by computing the cryptographic digest of a data block where the identifier itself is embedded, creating a deterministic, tamper-evident lock3. 17\. Why is CESR used in ACDC? CESR (Composable Event Streaming Representation) allows for text-binary dual encoding, which is highly efficient for streaming cryptographic events over both web and constrained IoT networks4. 18\. How does the EUDI Wallet utilize SD-JWT? The EU Digital Identity Wallet mandates SD-JWT VC for credential formats to ensure GDPR-compliant selective disclosure across all member states19. 19\. What is a Controllable Electronic Record (CER) under UCC Article 12? A legal designation giving digital assets (like tokens or smart contracts) defined property rights, allowing them to be used as collateral in secured lending6. 20\. Does Patefacere replace PKI? No. Patefacere is a civic/governance architecture. It would still rely on cryptographic primitives like PKI, KERI, or Ed25519 for underlying mathematical proof of its transparency mesh. 21\. How do you revoke an offline signed manifest? You cannot directly revoke an air-gapped manifest. The receiving system must periodically sync with a centralized CRL or transparency log to verify trust. 22\. What is an IBCT? Invocation-Bound Capability Tokens fuse identity, authorization, and provenance into a single token chain, primarily used in multi-agent AI ecosystems (A2A)10. 23\. Can OAuth handle AI agent delegation? Poorly. OAuth tokens lack native holder-side scope attenuation, meaning an AI agent cannot dynamically restrict a token's permissions before passing it to a sub-agent without hitting the auth server10. 24\. What is the standard failure mode of mTLS? Certificate expiration. Because mTLS relies heavily on centralized lifecycle management, expired certs frequently cause devastating infrastructure outages. 25\. How do you achieve interoperability between DID systems? Usually through centralized mediators or universal resolvers, which somewhat defeats the fundamental purpose of decentralization. 26\. Why would an organization downgrade from ACDC to SD-JWT? To interface with legacy consumer wallets that do not have the sophisticated cryptographic libraries to parse CESR or traverse multi-hop provenance graphs22. 27\. What is a Trust Receipt? A cryptographically verifiable record proving that a specific entity authorized or executed a specific action at a specific time, serving as an undeniable audit log. 28\. How does Patefacere handle "Citizenship administration"? By mapping physical and organizational affiliations into a public transparency mesh, making one's civic status mathematically undeniable and completely public. 29\. What is the role of a Corporate Wrapper? To absorb legal liability. Cryptography cannot go to jail or pay fiat fines; human-jurisdiction wrappers bridge the gap between digital actions and physical consequences6. 30\. Can SD-JWT be used for offline verification? Yes. Since the issuer's signature covers the \_sd hashes, a verifier with the issuer's public key can verify the disclosures entirely offline1. 31\. What is the BIPA impact in 2026? The Illinois Biometric Information Privacy Act (BIPA) enforces severe financial penalties for mishandling biometrics33. Identity systems using biometrics must avoid Patefacere's transparency and strictly utilize SD-JWT or local enclaves. 32\. Is Patefacere mature? No, it remains a conceptual philosophy and proposed architecture9. 33\. How do you migrate from Enterprise IAM to W3C DIDs? By transitioning the enterprise from an Identity Provider (IdP) to a Credential Issuer, granting employees portable VCs stored in enterprise-managed wallets. 34\. Does JSON-LD support selective disclosure? Only when paired with highly complex zero-knowledge cryptography like BBS+ signatures, which are computationally heavy compared to SD-JWT's salted hashes14. 35\. What is the primary vulnerability of local keys? They are invariably hardcoded into source code or config files, leading to mass exposure when repositories are breached. 36\. Can Biscuit tokens prevent replay attacks? Yes, by embedding strict nonces, TTLs, and binding the token execution to specific transport-layer contexts within the Datalog policy10. 37\. How does Patefacere align with Agamben's philosophy? It operationalizes the "coming community"—a singularity without identity, where absolute exposure of the false allows true proper being to take place8. 38\. What is the \_sd\_alg claim? A claim in an SD-JWT indicating the cryptographic hash algorithm (e.g., sha-256) used to compute the digests in the \_sd array15. 39\. Can SPIRE authenticate a human? No, SPIRE explicitly attests the properties of a running software process or workload, not the human who initiated it. 40\. Are smart contracts legally immune if they say "code is law"? No. As demonstrated in SEC actions and Fifth Circuit rulings, human actors designing and deploying smart contracts remain subject to criminal and civil law regardless of code6.

Twenty-Five Direct Answers

1. Does RFC 9901 support array element disclosure? Yes, SD-JWT natively supports selectively disclosing individual elements within a JSON array1.

2. Can Patefacere operate privately? No, its foundational architectural principle is radical openness; privacy mechanisms defeat its entire purpose8.

3. Is SPIFFE suitable for human identity? No, SPIFFE is strictly designed for workload and machine identity.

4. Do Biscuit tokens require a central server to verify delegation? No, verification is done entirely locally using Ed25519 public keys and Datalog evaluation10.

5. What replaces the vc+sd-jwt header in 2026? The dc+sd-jwt (Digital Credential) media type, as explicitly defined in Draft 1817.

6. Does KERI require a blockchain? No, KERI relies entirely on self-addressing identifiers and key pre-rotation logs, bypassing global consensus ledgers4.

7. Are smart contracts legally enforceable in Illinois? Yes, under the Illinois Blockchain Technology Act (BTA), provided standard common-law contract elements exist5.

8. Can SD-JWT hide the total number of claims? Yes, by strategically utilizing Decoy Digests1.

9. What is a SAID? A Self-Addressing Identifier, deterministically generated directly from the digest of the content it references3.

10. Does OAuth 2.1 support offline scope attenuation by the client? No, scope attenuation requires a round-trip to the authorization server, unlike Biscuit or Macaroons10.

11. What is CESR? Composable Event Streaming Representation, a dual text/binary encoding format optimized specifically for KERI4.

12. Can Enterprise IAM handle multi-party supply chain trust? No, IAM is inherently siloed to the operating organization's legal boundary.

13. What binds an SD-JWT to a specific holder? A Key Binding JWT (KB-JWT) that proves cryptographic possession of the private key associated with the credential1.

14. Is Patefacere compatible with zero-knowledge proofs? Philosophically and architecturally, no. ZKPs obscure the truth; Patefacere demands total revelation9.

15. What is an ACDC? An Authentic Chained Data Container, used for building verifiable data supply chains3.

16. Can local M2M keys rotate automatically? No, local keys require custom orchestration or manual intervention, often leading to operational outages.

17. Does UCC Article 12 cover smart contracts? Yes, it provides the comprehensive legal framework for "controllable electronic records"6.

18. What prevents rainbow table attacks in SD-JWT? High-entropy, cryptographically secure random salts included in every single disclosure1.

19. Can SCIM authenticate a user? No, SCIM is strictly a provisioning protocol, not an authentication protocol.

20. What limits delegation depth in Biscuit? The max\_depth parameter strictly enforced by the local Datalog evaluator10.

21. Does KERI support key recovery? KERI assumes key loss is catastrophic; it relies on pre-rotation to secure the next key, but lost active keys cannot be recovered4.

22. Are W3C DIDs mandatory for Verifiable Credentials? No, RFC 9901 SD-JWTs can securely use standard X.509 chains or HTTPS metadata resolution17.

23. What is an IBCT? Invocation-Bound Capability Token, fusing identity and attenuated authorization for agentic AI10.

24. Can offline signed manifests revoke access in real-time? No, air-gapped manifests cannot receive real-time CRL/OCSP updates.

25. When does Patefacere fail? When implemented in systems requiring low-latency M2M communication or strict consumer privacy regulations (like GDPR or BIPA)33.

70-Term Glossary

1\. ACDC (Authentic Chained Data Containers): A standard for verifiable provenance graphs.2\. Attenuation: The restriction of capabilities by a token holder before delegating to a downstream party.3\. BBS+: A digital signature scheme supporting zero-knowledge proofs.4\. BIPA: Biometric Information Privacy Act (Illinois) regulating biometric data handling.5\. Biscuit: A capability token format using Ed25519 and Datalog for offline attenuation.6\. CapEx: Capital expenditures.7\. OpEx: Operational expenditures.8\. Capability Token: A token granting the bearer specific, localized rights rather than global identity.9\. CER (Controllable Electronic Record): Digital property defined under UCC Article 12\.10\. CESR: Composable Event Streaming Representation; KERI's text/binary encoding.11\. CNCF: Cloud Native Computing Foundation (hosts SPIFFE/SPIRE).12\. Datalog: A declarative logic programming language used for Biscuit token policies.13\. Decoy Digest: A random hash in an SD-JWT used to hide the true number of claims.14\. DID (Decentralized Identifier): A globally unique, cryptographically verifiable identifier.15\. DID Method: The specific registry or mechanism for resolving a DID (e.g., did:web, did:keri).16\. DPoP (Demonstrating Proof-of-Possession): Binding a token to a client's cryptographic key.17\. eIDAS 2.0: European identity framework mandating EUDI wallets.18\. Entity: The human, organization, or machine engaging in an identity transaction.19\. EUDI Wallet: European Digital Identity Wallet.20\. Federation: Establishing trust across distinct identity domains (e.g., SAML, OIDC).21\. IBCT: Invocation-Bound Capability Token, used for multi-agent delegation.22\. IdP (Identity Provider): A centralized authority issuing identities (e.g., Okta).23\. IETF: Internet Engineering Task Force.24\. Illinois BTA: Illinois Blockchain Technology Act.25\. IPEX: KERI's protocol for exchanging verifiable data.26\. Issuer: The entity generating and signing a verifiable credential or token.27\. JSON-LD: JSON for Linking Data; provides semantic web context for VCs.28\. JWK (JSON Web Key): A JSON data structure representing a cryptographic key.29\. JWS (JSON Web Signature): The standard mechanism for signing JWTs.30\. JWT (JSON Web Token): A compact, URL-safe means of representing claims.31\. KB-JWT: Key Binding JWT; proves holder possession of an SD-JWT.32\. KEL (Key Event Log): An append-only cryptographic ledger of key rotations in KERI.33\. KERI: Key Event Receipt Infrastructure; a decentralized key management system.34\. Local Keys: Static, hardcoded cryptographic secrets used for basic authentication.35\. M2M: Machine-to-Machine communication.36\. Macaroons: Predecessors to Biscuit; capability tokens using nested HMACs.37\. Manifest: A digitally signed list of software components or configurations.38\. mTLS (Mutual TLS): Transport layer security where both client and server authenticate.39\. Node Attestation: SPIRE's process of verifying the identity of the host server.40\. OIDC (OpenID Connect): An identity layer built on top of the OAuth 2.0 protocol.41\. OOBI: Out-Of-Band Introduction; used in KERI to bootstrap trust.42\. Patefacere: Concept derived from Latin "to open"; an identity architecture of absolute transparency.43\. PKCE: Proof Key for Code Exchange; prevents authorization code interception in OAuth.44\. PKI (Public Key Infrastructure): Centralized system for managing X.509 certificates.45\. Pre-rotation: Cryptographically committing to a future key before it becomes active.46\. Principal: The entity requesting authorization.47\. Provenance: The verifiable origin and history of a piece of data.48\. Rainbow Table: Precomputed tables of hashes used to crack salts or passwords.49\. Relying Party (RP): The service consuming an identity token or credential.50\. RFC 9901: The IETF standard for Selective Disclosure JWTs.51\. SAID (Self-Addressing Identifier): An identifier derived directly from the content it secures.52\. Salt: Random data added to a claim before hashing to ensure cryptographic entropy.53\. SAML: Security Assertion Markup Language; legacy XML-based identity federation.54\. SCIM: System for Cross-domain Identity Management; standard for user provisioning.55\. SD-JWT: Selective Disclosure JSON Web Token.56\. SD-JWT VC: Verifiable Credential formatted as an SD-JWT.57\. Selective Disclosure: Revealing only a subset of data to a verifier while proving authenticity.58\. Smart Contract: Self-executing code residing on a ledger.59\. SPIFFE: Secure Production Identity Framework for Everyone.60\. SPIRE: The reference implementation of the SPIFFE standard.61\. SSO: Single Sign-On.62\. SVID: SPIFFE Verifiable Identity Document; typically an X.509 cert or JWT.63\. UCC Article 12: Uniform Commercial Code rules governing digital assets.64\. VC (Verifiable Credential): A tamper-evident credential whose authorship can be cryptographically verified.65\. vLEI: Verifiable Legal Entity Identifier; standard based on KERI/ACDC.66\. W3C: World Wide Web Consortium.67\. Workload Identity: Authentication specifically tied to running software processes.68\. Wyoming DAO Law: Legal framework wrapping decentralized autonomous organizations in LLC protections.69\. X.509: The standard format for public key certificates.70\. Zero-Knowledge Proof (ZKP): Proving a statement is true without revealing the underlying data.

Works cited

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

2. RFC 9901 \- Selective Disclosure for JSON Web Tokens \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9901/

3. Authentic Chained Data Containers (ACDC) \- GitHub Pages, https://trustoverip.github.io/kswg-acdc-specification/

4. Authentic Chained Data Containers (ACDC) Task Force Announces Public Review, https://trustoverip.org/blog/2024/03/21/authentic-chained-data-containers-acdc-task-force-announces-public-review/

5. BALANCING CODE AND LAW: \- AWS, https://fsi9-prod.s3.us-west-1.amazonaws.com/s3fs-public/2026-05/blockchain\_report\_finaldigital2.pdf

6. Smart Contract Legal Enforceability: When Code Isn't Law | Astraea Counsel, https://astraea.law/insights/smart-contract-legal-enforceability-code-isnt-law

7. Illinois Embraces Smart Contracts with New Blockchain Legislation, https://www.blockchainandthelaw.com/2020/01/illinois-embraces-smart-contracts-with-new-blockchain-legislation/

8. Agamben “The Coming Community” | konspektid \- WordPress.com, https://konspektikaust.wordpress.com/2011/05/25/agamben-the-coming-community/

9. The coming community \- cooltexts, https://cooltexts.github.io/sources/agamben.pdf

10. AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A \- arXiv, https://arxiv.org/html/2603.24775v1

11. AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A \- arXiv, https://arxiv.org/pdf/2603.24775

12. specs/draft-ietf-oauth-status-list-18.txt · v1.0.0 · OpenWallet Foundation / sd-jwt-dotnet, https://opensource.unicc.org/openwallet-foundation/sd-jwt-dotnet/-/blob/v1.0.0/specs/draft-ietf-oauth-status-list-18.txt?ref\_type=tags

13. SD-JWT Programming \- Medium, https://darutk.medium.com/sd-jwt-programming-df1e43560aa9

14. Verifiable Intent: Design Rationale, https://verifiableintent.dev/spec/design-rationale/

15. Your JWTs Are Now Outdated — Meet Selective Disclosure (RFC 9901\) | MojoAuth Blog \- Passwordless Authentication & Identity Solutions, https://mojoauth.com/blog/jwts-are-now-outdated-meet-selective-disclosure-rfc-9901

16. SD-JWT-based Verifiable Credentials (SD-JWT VC) \- IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-10.html

17. SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) \- IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-18.html

18. reports/rfc9901-gap-analysis.md · v1.0.0 · OpenWallet Foundation / sd-jwt-dotnet · GitLab, https://opensource.unicc.org/openwallet-foundation/sd-jwt-dotnet/-/blob/v1.0.0/reports/rfc9901-gap-analysis.md

19. IETF SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) draft-ietf-oauth-sd-jwt-vc-16 · Issue \#9 · eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications \- GitHub, https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/issues/9

20. Authentic Chained Data Containers (ACDC) \- IETF, https://www.ietf.org/archive/id/draft-ssmith-acdc-02.html

21. verifiable LEI (vLEI) Ecosystem Governance Framework v4.0 Technical Requirements Part 3: vLEI Credential Schema Registry \- GLEIF, https://www.gleif.org/organizational-identity/become-a-vlei-issuer-qvi/vlei-ecosystem-governance-framework/2026-03-25\_vlei-egf-v4.0-technical-requirements-part-3-vlei-credential-schema-registry\_v1.2\_final.pdf

22. Securing Verifiable Credentials using Authentic Chained Data Containers., https://weboftrust.github.io/vc-acdc/

23. draft-smith-satp-vlei-binding-00, https://datatracker.ietf.org/doc/html/draft-smith-satp-vlei-binding-00

24. Ask HN: What Are You Working On? (Nov 2025\) \- Hacker News, https://news.ycombinator.com/item?id=45869146

25. From Specification to Deployment: Empirical Evidence from a W3C VC \+ DID Trust Infrastructure for Autonomous Agents \- arXiv, https://arxiv.org/html/2605.06738v1

26. From Specification to Deployment: Empirical Evidence from a W3C VC \+ DID Trust Infrastructure for Autonomous Agents \- MolTrust, https://moltrust.ch/arxiv-preprint-v1.9.pdf

27. Verify SD-JWT-based Verifiable Credentials (x509 x5c) \- Vidos, https://vidos.id/docs/guides/services/verifier/verify/ietf-oauth-sd-jwt-vc-x5c/

28. Authentic Chained Data Containers \- GitHub, https://github.com/trustoverip/TSS0033-technology-stack-acdc/blob/main/docs/index.md

29. History for rfc9901 \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9901/history/

30. 50-State Review of Cryptocurrency and Blockchain Regulation, https://finance-pillar.wharton.upenn.edu/digital-assets-at-wharton/50-state-review-cryptocurrency-blockchain-regulation/

31. draft-ssmith-acdc-03 \- Authentic Chained Data Containers (ACDC) \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ssmith-acdc/

32. Daily Papers \- Hugging Face, https://huggingface.co/papers?q=A2A%20protocol

33. Seventh Circuit Holds that BIPA Amendment Applies Retroactively | Global Policy Watch, https://www.globalpolicywatch.com/2026/04/seventh-circuit-holds-that-bipa-amendment-applies-retroactively/