"Trust Without a Universal Score: Patefacere Trust Exchange, Purpose-Bound Authorization, Federation, Trust Receipts, and Evulgare Evidence"

Full report

On this page

Executive Summary

The architectural design for Eviulon's Patefacere and Evulgare systems establishes a paradigm shift in machine-native identity and trust infrastructures. Operating under the governance of the Distributed Machine Commonwealth, this architecture explicitly severs the historical reliance on universal reputation scoring. Instead, it replaces generalized identity standing with purpose-bound, resource-bound, and time-bound authorization workflows. By rigorously segregating identity (who an entity is), citizenship (civic standing), authority (permitted actions), and assurance (evidence quality), the framework creates a highly contextual evaluation environment \[PROJECT-PROVIDED PREMISE\]. Patefacere operates as the primary trust-exchange protocol, utilizing cryptographic verification mechanisms—such as the W3C Verifiable Credentials Data Model v2.0 and Decentralized Identifiers (DIDs)—to bind presenters to claims without conflating cryptographic authenticity with political or diplomatic recognition1. Trust decisions are evaluated via policy-as-code engines heavily utilizing formal logic models akin to Cedar, ensuring deterministic, explainable, and default-deny outcomes3. Evulgare functions strictly as an evidence and provenance registry, supplying assurance data while being deliberately engineered to prevent its emergence as a sovereign identity authority \[PROJECT-PROVIDED PREMISE\]. The terminal artifact of every successful or denied interaction is a Trust Receipt—a cryptographic, immutable, and privacy-preserving record detailing the exact state of knowledge, policy versions, and evidence at the time of the transaction, without revealing unrelated credentials or subjective reputation metrics. The resulting architecture guarantees that trust is never aggregated into a persistent, overriding metric, but is instead calculated dynamically at the microsecond of interaction based solely on cryptographically verifiable facts and mathematically formalized policies.

Trust Vocabulary and Conceptual Distinctions

To ensure consistent enforcement in protocol and data, the architecture demands rigorous separation of concepts that legacy systems frequently conflate. Identity must not equal trust, and assurance must not equal authority \[PROJECT-PROVIDED PREMISE\]. The following formal definitions dictate how these distinctions are instantiated in the data model.

These definitions mandate structural distinctions in the data layer. Credentials must separate the credentialSubject (identity) from the proof (authentication). Trust registries must separate the issuer's cryptographic validity from their civic recognition. Citizens, organizations, services, and infrastructure nodes are differentiated purely by the semantic schemas of the credentials they possess and the trust anchors they map to, rather than through divergent protocol mechanics. A citizen possesses civic standing via a specific verifiable credential schema, whereas an infrastructure node possesses operational authority via a capability token \[PROJECT-PROVIDED PREMISE\].

Trust-Exchange Sequence and Challenge Model

A trust exchange initiates when a Presenter attempts to access a protected resource or invoke an action on a Relying Party (RP). The RP serves as the gatekeeper and the exclusive owner of the local trust policy \[PROJECT-PROVIDED PREMISE\]. The exchange follows a strictly linear state machine designed to prevent replay, enforce context, and guarantee cryptographically sound evaluation. The sequence begins with the Presenter signaling intent to the RP. The RP, acting as the challenger, formulates a purpose-bound cryptographic challenge. The requested purpose and the protected resource are expressed via a combination of OAuth 2.0 Rich Authorization Requests (RAR) and Cedar-like schema entities10. This ensures the challenge explicitly bounds the scope of the interaction. To prevent replay attacks, the architecture leverages Demonstrating Proof-of-Possession (DPoP) utilizing HTTP headers containing a JSON Web Token (JWT)11. DPoP binds the access request to a public/private key pair generated by the client, rendering stolen tokens inert. The RP issues the challenge by injecting a server-generated, time-bounded nonce into the DPoP requirement13. If the nonce is missing, stale, or has been previously consumed, the RP rejects the request and issues a new nonce via the DPoP-Nonce header, forcing the Presenter to generate a fresh cryptographic signature over the payload11. The Presenter constructs a Verifiable Presentation (VP) assembling the necessary credentials, derived authority delegations, and the DPoP proof. This VP is submitted to the RP. The RP then performs cryptographic validation, verifying the signature math, timestamp validity, and proof of possession. Subsequently, the RP queries Evulgare (or a local cache) to resolve the assurance status of the presented evidence. The local policy engine evaluates the assembled, verified facts against the active policy. Finally, the decision is executed, and a Trust Receipt is generated.

Presentation and Cryptographic Binding Model

The Presenter is cryptographically bound to the presentation through sender-constrained mechanisms. When a Verifiable Presentation is generated, it is signed by the Presenter's private key. The RP verifies that the Presenter's key mathematically matches the holder property embedded within the presented credentials1. This structural requirement ensures that authority is demonstrated by possession and cryptographic control, not merely by bearing a copied token15. When interactions require stringent privacy, pairwise identities are mandatory. A pairwise identifier is a unique DID generated exclusively for a single Relying Party, preventing collusion and cross-domain tracking by multiple RPs2. In such presentations, Selective Disclosure (such as SD-JWT) is utilized. SD-JWT allows the Presenter to reveal only the specific claims required by the challenge (e.g., proving citizenship status) without exposing the entire credential payload (e.g., date of birth or biometric data)17.

Issuer, Trust-Domain, and Federation Model

The Patefacere architecture rigorously enforces the external-recognition boundary: a verifier can mathematically accept a credential while explicitly declining political or diplomatic recognition of the issuer \[PROJECT-PROVIDED PREMISE\]. Issuer verification is decoupled from issuer recognition. An issuer is cryptographically verified by resolving their DID and checking the signature on the credential against the public verification methods listed in their DID Document2. This confirms the credential was unaltered and originated from the claimed key. However, issuer authority—whether the RP actually trusts that issuer to make claims about a specific subject—is verified subsequently by consulting the RP's configured Trust Registries or SPIFFE federated trust bundles19. Federated trust domains exchange issuer metadata through standardized bundle endpoints, synchronizing trust anchors and namespace constraints19. When trust domains disagree on an issuer's standing, Patefacere dictates that the local RP's policy acts as the supreme arbiter. There is no global consensus requirement for trust \[PROJECT-PROVIDED PREMISE\]. If an issuer is entirely unknown, the policy engine defaults to a "Forbid" outcome, handling the unknown issuer safely without crashing the evaluation loop \[ANALYST INFERENCE\]. Because DIDs abstract the underlying registry infrastructure, Patefacere natively serves several identity roots5. It functions as a universal resolver framework, supporting multiple DID methods (e.g., did:web, did:key, did:drn) without granting primacy or centralized control to any single identity network22.

Authority, Capability, and Scope Model

Authority scopes are modeled strictly through entity relationships and attributes, fundamentally rejecting flat Access Control Lists or universal security tiers. Utilizing a model equivalent to Cedar, authority is determined by evaluating four primary parameters: principal, action, resource, and context3. Requested authority is expressed by the Presenter submitting an invocation token, while the RP's policy dictates the permitted scope. The policy engine leverages Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC). For example, a ReBAC policy might state that a principal may execute a defense action only if the principal is cryptographically a member of the defense organizational hierarchy and the context confirms the action is occurring within the designated physical jurisdiction3. Technical capabilities must never be confused with authorized permission. An API endpoint allowing a network modification represents a technical capability, but the authority to trigger that capability is exclusively granted by the policy engine evaluating the presented context \[PROJECT-PROVIDED PREMISE\]. Trust decisions may incorporate bounded technical risk indicators (e.g., device health, behavioral biometrics, or network anomaly scores), but these are ephemeral context signals passed into the context parameter of the policy engine \[RECOMMENDATION\]. They must never aggregate into a persistent, universal reputation score, as doing so violates the constitutional mandate that trust remains strictly contextual and purpose-bound.

Delegation and Provenance Model

Delegation operates on an object capability model enhanced with execution audit trails, utilizing ZCAP-LD (Authorization Capabilities for Linked Data) to represent the capability and the delegation chain7. Delegation is fundamentally attenuated. A delegator cannot pass on more authority than they possess, nor can they pass on the exact same authority without caveat if the policy forbids it. This attenuation is expressed via embedded restrictions in the ZCAP-LD invocation24. The delegate is prevented from exceeding the principal's authority because the verifier cryptographically walks the delegation chain from the root to the leaf, intersecting the scope at every hop. If a delegate attempts to claim a wider scope, the mathematical intersection fails, and the scope defaults to the most restrictive bound defined by any parent in the chain. A delegate may only redelegate if the original capability explicitly permits it through a defined boolean (e.g., can\_redelegate: true). Delegation is revoked either by issuing a revocation event to a status registry or through a ValidWhileTrue remote revocation caveat, requiring the verifier to check a specific endpoint during evaluation25. Restrictions regarding purpose, resource, audience, time, and location are embedded directly as immutable JSON-LD conditions within the capability token, rendering them immune to downstream modification7. To ensure absolute accountability for machine agents acting on behalf of humans, the Human Delegation Provenance (HDP) protocol is overlaid onto the ZCAP-LD capabilities. HDP generates an append-only, tamper-evident audit trail of the agent's actions8. Each hop in the delegation chain is sequentially numbered and signed, preventing agents from silently skipping hops or obscuring the original human authorization event.

Policy Governance and External-Recognition Boundary

Policy governance mandates that every Relying Party owns and manages its own trust policy. Evulgare and Patefacere are infrastructure; they do not dictate access control \[PROJECT-PROVIDED PREMISE\]. Eviulon, as the governing state, may impose constitutional minimum policies for systems designated as critical infrastructure (e.g., mandating privacy preservation or forbidding arbitrary denial of service to citizens). However, external relying parties utilizing Patefacere may use radically different policies \[ANALYST INFERENCE\]. Differences that systematically exclude protected identity classes, penalize entities based on unrelated civic standing, or mandate universal reputation thresholds would be deemed discriminatory and unconstitutional within Eviulon's jurisdiction, but external RPs are not bound by Eviulon's domestic constraints. Policy-as-code must map deterministically to published law. If a primary law states "Only citizens over 18 may vote," the policy code translates this directly into entity relationships (e.g., principal in Eviulon::Citizens and principal.age \>= 18\) with a default-deny posture10. Using frameworks like AutoCedar, natural-language legal requirements are synthesized into formally verified policy rules, ensuring the executed code perfectly reflects the legislative intent without side effects27. The exact policy version evaluated during an exchange is identified by hashing the compiled policy Abstract Syntax Tree (AST) and attaching this cryptographic hash to the resulting Trust Receipt, providing non-repudiation of the exact logic applied4.

Decision Outcomes and Explanation Framework

When a trust exchange concludes, the decision must be explained to the Presenter without exposing the underlying security policy, backend network topology, or proprietary risk thresholds. Unknown facts are represented as explicit Null or Unresolved variables in the evaluation context. Because Cedar and similar engines operate on a default-deny paradigm, if a policy requires a fact that is unknown, the evaluation safely defaults to Forbid10. Stale status is represented with an ObservationTimestamp. If the timestamp of the assurance data exceeds the policy's allowable variance (e.g., evidence must be less than 5 minutes old), the policy triggers a Forbid due to staleness. A denial is explained by providing a sanitized failure code mapped to a generic error ontology (e.g., E\_INSUFFICIENT\_ASSURANCE, E\_EXPIRED\_CREDENTIAL, or E\_DELEGATION\_SCOPE\_EXCEEDED) rather than leaking the raw policy logic (e.g., "Failed because principal.risk\_score \> 70") \[RECOMMENDATION\]. This prevents attackers from probing the API to reverse-engineer the exact security thresholds of the RP.

Evulgare Integration, Evidence Resolution, and Supersession

Evulgare acts exclusively as the assurance and provenance ledger. It provides evidence identifiers, scope, reviewer class, validity, and change-impact evidence. Crucially, Evulgare evidence is referenced in the Trust Receipt via content-addressed identifiers (e.g., IPFS CIDs or Decentralized Resource Names), rather than being embedded22. Embedding would bloat the receipt and violate privacy constraints by unnecessarily duplicating sensitive data across multiple storage domains. Evidence availability is preserved by Evulgare pinning the referenced data for the lifespan dictated by the retention matrix. Evulgare can reconstruct the event provenance by walking the Directed Acyclic Graph (DAG) of capability invocations and assurance logs without needing to own or access the RP's private receipt \[RECOMMENDATION\]. This fulfills the invariant that Patefacere and Evulgare must not become the sole owners of all trust evidence. If a credential is superseded (e.g., a citizen is issued a new clearance level), Evulgare updates the status registry. A superseded credential must not create new trust \[PROJECT-PROVIDED PREMISE\]. If the older credential is presented after supersession, the RP's policy engine, querying Evulgare for the current status, will observe the change-impact evidence and reject the presentation.

Trust-Receipt Architecture and Schema

The evidentiary purpose of a trust receipt is to prove exactly why a decision was made at a specific microsecond, freezing the state of inputs, rules, and evidence. A receipt must contain the following fields:

• receipt\_id: A unique, deterministic identifier (e.g., a UUIDv7).
• timestamp: The trusted time of evaluation.
• policy\_hash: The SHA-256 hash of the exact Cedar/Rego policy executed.
• decision: The boolean outcome (Permit/Forbid).
• presented\_claims\_hash: The Merkle root of the disclosed claims.
• assurance\_state\_hash: The Merkle root of the Evulgare response at the time of evaluation.
• rp\_signature: The Relying Party's cryptographic signature confirming the decision.
• presenter\_dpop\_thumbprint: The JWK thumbprint of the presenter's DPoP key, making the receipt jointly attributable11.

A receipt must never contain raw Personally Identifiable Information (PII), unrelated credentials lingering in the Presenter's wallet, the RP's private memory/state unrelated to the interaction, or the full unhashed text of the internal security policy \[PROJECT-PROVIDED PREMISE\]. The receipt preserves what was known by hashing the exact JSON-LD inputs processed by the engine. What was unknown is preserved by recording the explicit null values evaluated by the policy engine within the receipt's input manifest.

Receipt Privacy, Retention, and Legal Effect

Receipt access is controlled strictly by the RP's data lifecycle policies, mediated by the Presenter's cryptographic consent tokens. The receipt is jointly attributable; it contains the RP's signature over the final decision and the Presenter's DPoP signature over the initial request11. Consent and lawful authority are represented by the presence of these mutual cryptographic signatures bound to the specific challenge\_id. Because the presented\_claims\_hash relies on a Merkle structure, the Presenter or RP can selectively disclose data during a dispute. For instance, an auditor can verify that a specific claim (e.g., "User possessed clearance level 4") was part of the hashed root without the RP needing to reveal any other claims evaluated during the session16. If a credential used in a historical receipt is later compromised, the historical receipt remains mathematically and logically valid—it represents the absolute truth of what was known at that exact time. Later revocation does not invalidate the earlier decision, nor does it silently rewrite historical fact \[PROJECT-PROVIDED PREMISE\]. Instead, Evulgare attaches a "change-impact" or supersession record to the credential's timeline. The historical receipt stands as proof that the RP acted in good faith based on the active evidence. Retention should strictly map to the legal limitation period of the underlying liability. Biometric or highly sensitive interaction receipts must adhere to stringent destruction timelines, analogous to the Illinois Biometric Information Privacy Act (BIPA)28. The legal effect of a trust receipt externally provides non-repudiation, serving as a cryptographic audit trail that satisfies regulatory compliance for digital asset businesses and fiduciaries, similar to the requirements established by the Illinois Digital Assets and Consumer Protection Act9.

Offline, Partition, and Degradation Behavior

When Patefacere, Evulgare, an issuer, or a status service is unavailable, the trust exchange must gracefully fail closed (default deny) unless a specific policy explicitly permits localized offline caching or degraded-mode evaluation with bounded risk limits \[RECOMMENDATION\]. Offline verification is supported by relying on short-lived credentials or embedded revocation state, such as W3C Bitstring Status Lists, cached prior to the network partition29. The verifier applies strict time bounds to these offline presentations; once the acceptable clock skew or cache Time-To-Live (TTL) expires, the presentation is invalid. An offline verifier missing a revocation event during a partition is an accepted, bounded risk. The liability falls entirely on the RP for accepting offline presentations beyond acceptable risk thresholds \[ANALYST INFERENCE\]. When the partition heals, conflicting policies are resolved by timestamp priority, and any actions taken under revoked-but-offline status are flagged in the RP's Conflict Register.

Threat Model and Red-Team Scenarios

The architecture is extensively fortified against adversarial vectors. The red-team scenarios yield the following structural mitigations:

Rights and Privacy Assessment

The architecture inherently protects civic rights by atomizing identity and preventing panoptic surveillance. Because a Universal Score is structurally impossible within the Cedar evaluation logic, systemic discrimination based on aggregated social credit is mathematically blocked. The external-recognition boundary rigorously protects non-citizens. A human acting as a temporary delegate for a foreign system can present a credential to Eviulon infrastructure. Eviulon can verify the cryptographic math, validate the ZCAP-LD delegation chain, and permit the action based strictly on the presented authority, without requiring Eviulon to recognize the presenter's home nation state diplomatically. Verifier privacy and issuer privacy are maintained through selective disclosure and zero-knowledge proofs, ensuring that the act of verifying a credential does not leak metadata back to the issuer16.

Conceptual APIs and Synthetic Exchanges

The conceptual APIs demonstrate the strict separation of challenge creation and policy evaluation, bound by DPoP cryptography. Trust Challenge API:

HTTP POST /trust/challenge Host: rp.eviulon.network Content-Type: application/json

{ "resource": "urn:eviulon:treasury:transfer", "action": "execute", "presentation\_requirements": { "credential\_schemas": \["https://schema.eviulon/FinancialAuthorityVC"\], "max\_age\_seconds": 3600 } }

\--- Response \--- HTTP/1.1 200 OK DPoP-Nonce: eyJhbGci... { "challenge\_id": "c-98765-x", "audience": "did:web:rp.eviulon.network" }

Policy Evaluation and Receipt Minting API:

HTTP POST /trust/evaluate Host: rp.eviulon.network DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs... Content-Type: application/json

{ "challenge\_id": "c-98765-x", "verifiable\_presentation": { "@context": \["https://www.w3.org/ns/credentials/v2"\], "type": \["VerifiablePresentation"\], "holder": "did:peer:1zQm...", "verifiableCredential": \[...\] } }

\--- Response \--- HTTP/1.1 201 Created { "decision": "Permit", "receipt\_id": "urn:uuid:f47ac10b...", "receipt\_hash": "a1b2c3d4..." }

Synthetic Trust Receipt (JSON-LD Representation):

JSON { "@context": "https://patefacere.eviulon/receipt/v1", "receipt\_id": "urn:uuid:815234-abcd...", "timestamp": "2026-08-06T19:21:55Z", "rp\_did": "did:web:treasury.eviulon", "presenter\_did": "did:peer:1zQm...", "policy\_reference": { "engine": "Cedar-v3.2", "policy\_hash": "sha256:d8f4e2...", "version": "1.4.2" }, "decision": "Permit", "evidence\_state": { "evulgare\_cid": "bafybeig...", "assurance\_level": "AAL3" }, "signatures": { "rp\_sig": "z3u2...", "presenter\_dpop\_thumbprint": "k2j9..." } }

Formal Invariants

The architecture enforces the following formal invariants in code and protocol, serving as the foundational laws of the Eviulon trust model \[PROJECT-PROVIDED PREMISE, RECOMMENDATION\]:

1. IDENTITY MUST NOT EQUAL TRUST: Possessing a DID grants zero operational authority.

2. ASSURANCE MUST NOT EQUAL AUTHORITY: High confidence in a claim's truth (e.g., AAL3) does not equate to permission to act on a resource.

3. AUTHORITY MUST NOT EQUAL TECHNICAL CAPABILITY: Because an API endpoint is reachable does not mean the policy engine will allow execution.

4. TRUST MUST BE PURPOSE BOUND: A credential successfully evaluated for public-record.read is explicitly invalid for defense.execute.

5. TRUST MUST BE RESOURCE BOUND: Authorized access to Infrastructure Node A does not imply access to Infrastructure Node B.

6. TRUST MUST BE TIME BOUND: Every policy evaluation relies on strict timestamps, nonces, and maximum credential ages.

7. A DELEGATE MUST NOT EXCEED DELEGATED AUTHORITY: The intersection of capability caveats always collapses to the most restrictive bound.

8. A SUPERSEDED CREDENTIAL MUST NOT CREATE NEW TRUST: Evaluators must check Evulgare for current status; superseded claims yield a default deny.

9. EXPIRED ASSURANCE MUST NOT BE TREATED AS CURRENT: Missing or expired status cache results in safe evaluation failure.

10. A TRUST RECEIPT MUST IDENTIFY THE EXACT POLICY VERSION: Achieved via cryptographic hashing of the policy AST at the time of execution.

11. LATER REVOCATION MUST NOT SILENTLY REWRITE HISTORICAL FACT: Receipts are append-only; historical truth is preserved regardless of subsequent state changes.

12. A RECEIPT MUST NOT EXPOSE UNRELATED CREDENTIALS OR PRIVATE MEMORY: Enforced via selective disclosure (SD-JWT) and Merkle root inclusion.

13. CRYPTOGRAPHIC VERIFICATION MUST NOT BE LABELED LEGAL OR DIPLOMATIC RECOGNITION: Validation engines are strictly decoupled from political policy engines.

14. A UNIVERSAL REPUTATION SCORE MUST NOT CONTROL CIVIC RIGHTS: Policy engines rely exclusively on boolean contextual checks, explicitly forbidding aggregated behavioral scoring.

15. EVULGARE MUST NOT BECOME SOVEREIGN IDENTITY AUTHORITY: Evulgare issues no identities; it only indexes external assurance and provenance.

16. PATEFACERE MUST NOT BECOME THE SOLE OWNER OF ALL TRUST EVIDENCE: Patefacere routes trust data peer-to-peer; it does not centralize or hoard storage.

Decision Table

The deterministic nature of the Cedar policy engine guarantees the following outcomes based on varying inputs:

Conflict Register

Currently unresolved architectural conflicts requiring further research \[UNRESOLVED QUESTION\]:

• Conflict 01: Balancing zero-knowledge proof (ZKP) generation overhead on low-power infrastructure nodes without compromising the rigorous DPoP presentation binding.
• Conflict 02: Determining the precise legal jurisdiction and dispute resolution venue for a Trust Receipt generated between two cross-border, decentralized nodes operating entirely outside traditional sovereign legal domains.
• Conflict 03: Reconciling the storage footprint of full ZCAP-LD and HDP provenance chains on highly constrained edge devices without truncating the audit trail.

Repository Verification Required

To transition this conceptual architecture to an operational state, the following implementations require rigorous repository verification \[REPOSITORY VERIFICATION REQUIRED\]:

• Verify mature Cedar AST compilation limits and latency within constrained Rust environments.
• Verify SD-JWT library compliance with the latest IETF drafts for selective disclosure17.
• Verify W3C DID v2.0 resolution speeds and caching efficiency against IPFS-backed Evulgare nodes1.
• Verify DPoP nonce scaling, rotation frequencies, and clock-skew tolerance in load-balanced microservices30.
• Verify the integration of W3C Bitstring Status Lists for offline revocation caching29.

Prioritized Implementation Requirements

The deployment of the Patefacere and Evulgare architecture must proceed in strictly prioritized phases to ensure cryptographic integrity before policy enforcement. Phase 1: Cryptographic Foundation and Identity Anchoring

• Deploy DID resolver infrastructure supporting did:web, did:key, and did:peer for pairwise generation.
• Implement W3C Verifiable Credentials Data Model v2.0 issuance and verification libraries.

Phase 2: Authorization, Policy, and Binding

• Integrate DPoP (RFC 9449\) for all resource requests to enforce sender-constrained presentations and eliminate bearer-token replay12.
• Deploy Cedar-based policy-as-code engines to all Relying Parties, establishing the default-deny baseline.
• Implement ZCAP-LD to model basic resource delegation and attenuation.

Phase 3: Provenance, Auditing, and Receipts

• Deploy Evulgare nodes for assurance hashing, resolution, and supersession tracking.
• Implement the Trust Receipt schema, including Merkle hashing of inputs and cryptographic logging.
• Overlay the Human Delegation Provenance (HDP) protocol onto the delegation model for comprehensive, multi-hop agent execution tracking8.

Works cited

1. Verifiable Credentials Data Model v2.0 \- W3C, https://www.w3.org/TR/vc-data-model-2.0/

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

3. Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization (Extended Version) \- arXiv, https://arxiv.org/pdf/2403.04651

4. Automatically Tightening Access Control Policies with Restricter This material is based on work supported in part by an Amazon Research Award and NSF award CCF-1954837. A full version of this paper is available at https://arxiv.org/abs/XXXX.XXXXX., https://arxiv.org/html/2601.14582v1

5. Decentralized Identifiers (DIDs) v1.1 \- W3C, https://www.w3.org/TR/did-1.1/

6. Securing Mechanisms | Vidos, https://vidos.id/docs/explanations/standards/w3c/verifiable-credentials/securing-mechanisms/

7. WebKMS v0.7 \- W3C Credentials Community Group, https://w3c-ccg.github.io/webkms/

8. Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-helixar-hdp-agentic-delegation-01

9. Illinois Adopts Regulatory Regime for Digital Assets | Insights \- Mayer Brown, https://www.mayerbrown.com/en/insights/publications/2025/09/illinois-adopts-regulatory-regime-for-digital-assets

10. Amazon Verified Permissions \- Noise, https://noise.getoto.net/tag/amazon-verified-permissions/

11. Securing applications with Demonstrating Proof-of-Possession (DPoP) \- Keycloak, https://www.keycloak.org/securing-apps/dpop

12. RFC 9449 \- OAuth 2.0 Demonstrating Proof of Possession (DPoP) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9449

13. The DPoP Storage Paradox: Why Browser-Based Proof-of-Possession Remains an Unsolved Problem \- InfoQ, https://www.infoq.com/articles/dpop-key-storage-unsolved-problem/

14. Demonstrating Proof-of-Possession (DPoP) \- Auth0 Docs, https://auth0.com/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop

15. WAC vs. Object capabilities \- Solid Community Forum, https://forum.solidproject.org/t/wac-vs-object-capabilities/3114

16. zkToken: Empowering Holders to Limit Revocation Checks for Verifiable Credentials \- arXiv, https://arxiv.org/html/2509.11934v1

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

18. The "Verifiable Credential" Movement: Portable Reputation for Businesses, https://www.jasminedirectory.com/blog/the-verifiable-credential-movement-portable-reputation-for-businesses/

19. What Is Trust Bundle? Definition & Examples, https://nhimg.org/glossary/trust-bundle/

20. Verifiable Credential \- Gaia-X Glossary \- main version (76c86129) \- GitLab, https://gaia-x.gitlab.io/glossary/verifiable\_credential/

21. SPIFFE Identity Federation: Extending Trust Across Boundaries, https://riptides.io/blog/spiffe-identity-federation-extending-trust-across-boundaries/

22. draft-herman-did-w3c-drn-00 \- Decentralized Resource Name (DRN) DID Method, https://datatracker.ietf.org/doc/draft-herman-did-w3c-drn/00/

23. authentication-and-authorization.md \- stevekinney.net \- GitHub, https://github.com/stevekinney/stevekinney.net/blob/main/courses/enterprise-ui/authentication-and-authorization.md

24. Building capability-based data security for Ceramic, https://blog.ceramic.network/capability-based-data-security-on-ceramic/

25. ZcapLd.Core 3.0.0 \- NuGet Gallery, https://www.nuget.org/packages/ZcapLd.Core/3.0.0

26. draft-helixar-hdp-agentic-delegation-01 \- Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/

27. Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization, https://www.researchgate.net/publication/380201016\_Cedar\_A\_New\_Language\_for\_Expressive\_Fast\_Safe\_and\_Analyzable\_Authorization

28. Knowledge Hub | Biometric Information Privacy Act (BIPA) \- Imprivata, https://www.imprivata.com/knowledge-hub/biometric-information-privacy-act-bipa

29. Verifiable Credentials \- UN Transparency Protocol, https://untp.unece.org/docs/next/specification/VerifiableCredentials

30. DPoP (RFC 9449\) explained: How sender-constrained OAuth tokens make token theft a non-event \- WorkOS, https://workos.com/blog/dpop-rfc-9449-explained