- From: Alan Karp <alanhkarp@gmail.com>
- Date: Thu, 2 Apr 2026 10:57:43 -0700
- To: dzagidulin@gmail.com
- Cc: Bob Wyman <bob@wyman.us>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANpA1Z27ksBC0TiantAXTQrdRxANk6SyLnfS-DRLmrpM-0C8ew@mail.gmail.com>
Another hard problem with expressing policy in the delegation certificate
comes with chaining. Company A supplies its policy when delegating to
Company B. Company B would like to express its policy when delegating to
its employees or to another company. I don't know if it's possible to
decide if those two policies are compatible when verifying if a resource
request is authorized.
Then there's the issue of allowing for policy violations. In my
experience, strictly enforcing enterprise policies often prevents you from
doing your job. For example, a service you need to use may not have the
credentials a policy requires, leaving you no choice but to share your own
with it. A prototype system we tested allowed you to explain why you were
violating the policy, but that required human-in-the-loop.
I believe all these issues can be addressed, but I'd like to get the basics
worked out first. (That wasn't my original opinion, but Dmitri convinced
me I was wrong.)
--------------
Alan Karp
On Thu, Apr 2, 2026 at 10:33 AM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:
> Hi Bob! :)
>
> Excellent point about how open-ended root zCaps are, and that the spec
> could use more details on caveats etc. I'd love to add an extension point
> property to zcaps, that one can use to link to (or embed) policy docs like
> Janssen <https://docs.jans.io/stable/>/Cedarling, ODRL, and others.
>
> On Thu, Apr 2, 2026 at 10:46 AM Bob Wyman <bob@wyman.us> wrote:
>
>> Dmitri,
>> I am pleased to see renewed interest in updating zCap. Over the years,
>> I've suggested several times that zCap should leverage the work done in the ODRL
>> community group <https://www.w3.org/community/odrl/>. I hope I'll have
>> another opportunity to do so. While I recognize that many will suggest a
>> "full-blown" ODRL implementation is too much to require in a standard
>> intended for cases where expressiveness of caveats is not required, I
>> suggest that a minimal profile ODRL can be easily defined to match the
>> semantics afforded by the current zCap caveat definition. Implementers
>> should then be free to define their own, potentially more expansive
>> profiles, as their use case or application requires. This allows zCap to
>> address a wide variety of requirements and avoids the current need to
>> define something outside of zCap when a rich rights expression language
>> like ODRL is necessary.
>>
>> Below I provide an example, based on old notes, illustrating the
>> difference between zCap, as currently defined, and what it could look like
>> and enable if it adopted at least a minimal profile of the ODRL Rights
>> Expression Language.
>> zcap examples: current spec vs. minimal ODRL caveat profile
>>
>> The scenario throughout: Acme Corp’s document management system. The
>> legal department owns a document collection. The IT department manages the
>> server. A senior lawyer delegates review authority to junior lawyers, who
>> may further delegate to paralegals.
>>
>> This scenario is chosen because the implicit delegation structure is
>> immediately visible: IT manages the server on behalf of Legal, which itself
>> operates within constraints set by Acme’s board.
>> ------------------------------
>> Example 1: Root zcap — current spec
>>
>> The root zcap identifies the senior lawyer as the controller of the legal
>> documents collection. The current spec requires that a root zcap have ONLY
>> four fields. No caveats are permitted.
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb1-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb1-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-5924348180814128079_m_4172614838933896567_cb1-3> "id": "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb1-4> "controller": "did:key:z6MkSeniorLawyer", <#m_-5924348180814128079_m_4172614838933896567_cb1-5> "invocationTarget": "https://docs.acme.example/legal" <#m_-5924348180814128079_m_4172614838933896567_cb1-6>}
>>
>> *The invisible problem.* The board granted the legal department
>> authority over legal documents subject to constraints: client documents may
>> never be shared outside the firm, and billing records require CFO
>> co-approval for access. These constraints exist in Acme’s policy documents
>> but are invisible in the root zcap. Nothing in the zcap chain prevents a
>> delegated zcap from granting an external party access to client documents —
>> the monotonicity invariant has nothing to enforce against, because the root
>> asserts unconstrained authority.
>> ------------------------------
>> Example 1 (revised): Root zcap — with ODRL minimal profile
>>
>> The root zcap now makes the board’s constraints explicit. The implicit
>> delegation — from Acme’s board to the legal department, subject to
>> confidentiality rules — is now visible in the root.
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb2-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb2-2> "@context": [ <#m_-5924348180814128079_m_4172614838933896567_cb2-3> "https://w3id.org/zcap/v1", <#m_-5924348180814128079_m_4172614838933896567_cb2-4> "https://www.w3.org/ns/odrl/2/" <#m_-5924348180814128079_m_4172614838933896567_cb2-5> ], <#m_-5924348180814128079_m_4172614838933896567_cb2-6> "id": "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb2-7> "controller": "did:key:z6MkSeniorLawyer", <#m_-5924348180814128079_m_4172614838933896567_cb2-8> "invocationTarget": "https://docs.acme.example/legal", <#m_-5924348180814128079_m_4172614838933896567_cb2-9> "caveat": [{ <#m_-5924348180814128079_m_4172614838933896567_cb2-10> "type": "odrl:Permission", <#m_-5924348180814128079_m_4172614838933896567_cb2-11> "odrl:action": ["odrl:read", "odrl:write", "odrl:delete"], <#m_-5924348180814128079_m_4172614838933896567_cb2-12> "odrl:constraint": [{ <#m_-5924348180814128079_m_4172614838933896567_cb2-13> "odrl:leftOperand": "odrl:recipient", <#m_-5924348180814128079_m_4172614838933896567_cb2-14> "odrl:operator": "odrl:isPartOf", <#m_-5924348180814128079_m_4172614838933896567_cb2-15> "odrl:rightOperand": { <#m_-5924348180814128079_m_4172614838933896567_cb2-16> "@value": "https://directory.acme.example/employees" <#m_-5924348180814128079_m_4172614838933896567_cb2-17> } <#m_-5924348180814128079_m_4172614838933896567_cb2-18> }] <#m_-5924348180814128079_m_4172614838933896567_cb2-19> }] <#m_-5924348180814128079_m_4172614838933896567_cb2-20>}
>>
>> Now any delegated zcap that attempts to grant access to a party outside
>> Acme’s employee directory is a detectable monotonicity violation. The
>> constraint that was invisible is now enforceable.
>> ------------------------------
>> Example 2: First delegation — current spec (URL-path attenuation)
>>
>> The senior lawyer delegates read authority to a junior lawyer, restricted
>> to the contracts subdirectory. Attenuation is expressed only by narrowing
>> the invocationTarget URL.
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb3-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb3-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-5924348180814128079_m_4172614838933896567_cb3-3> "id": "urn:uuid:b1c2d3e4-0001", <#m_-5924348180814128079_m_4172614838933896567_cb3-4> "parentCapability": <#m_-5924348180814128079_m_4172614838933896567_cb3-5> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb3-6> "controller": "did:key:z6MkJuniorLawyer", <#m_-5924348180814128079_m_4172614838933896567_cb3-7> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-5924348180814128079_m_4172614838933896567_cb3-8> "allowedAction": ["read"], <#m_-5924348180814128079_m_4172614838933896567_cb3-9> "expires": "2026-12-31T00:00:00Z", <#m_-5924348180814128079_m_4172614838933896567_cb3-10> "proof": { <#m_-5924348180814128079_m_4172614838933896567_cb3-11> "type": "Ed25519Signature2020", <#m_-5924348180814128079_m_4172614838933896567_cb3-12> "proofPurpose": "capabilityDelegation", <#m_-5924348180814128079_m_4172614838933896567_cb3-13> "capabilityChain": [ <#m_-5924348180814128079_m_4172614838933896567_cb3-14> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-5924348180814128079_m_4172614838933896567_cb3-15> ], <#m_-5924348180814128079_m_4172614838933896567_cb3-16> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-5924348180814128079_m_4172614838933896567_cb3-17> "proofValue": "z..." <#m_-5924348180814128079_m_4172614838933896567_cb3-18> } <#m_-5924348180814128079_m_4172614838933896567_cb3-19>}
>>
>> The restriction to the contracts subdirectory is implicit in the URL. The
>> allowedAction restricts to read. Nothing else is expressible — the
>> junior lawyer could be granted access to contracts from any client, active
>> or closed, with no way to constrain further without restructuring the URL
>> hierarchy.
>> ------------------------------
>> Example 2 (revised): First delegation — ODRL minimal profile
>>
>> The same delegation, but with an explicit ODRL constraint making the
>> attenuation readable and extensible. The minimal profile uses only
>> odrl:isPartOf — semantically identical to the URL prefix check, now
>> expressed in standard vocabulary.
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb4-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb4-2> "@context": [ <#m_-5924348180814128079_m_4172614838933896567_cb4-3> "https://w3id.org/zcap/v1", <#m_-5924348180814128079_m_4172614838933896567_cb4-4> "https://www.w3.org/ns/odrl/2/" <#m_-5924348180814128079_m_4172614838933896567_cb4-5> ], <#m_-5924348180814128079_m_4172614838933896567_cb4-6> "id": "urn:uuid:b1c2d3e4-0001", <#m_-5924348180814128079_m_4172614838933896567_cb4-7> "parentCapability": <#m_-5924348180814128079_m_4172614838933896567_cb4-8> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb4-9> "controller": "did:key:z6MkJuniorLawyer", <#m_-5924348180814128079_m_4172614838933896567_cb4-10> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-5924348180814128079_m_4172614838933896567_cb4-11> "allowedAction": ["read"], <#m_-5924348180814128079_m_4172614838933896567_cb4-12> "expires": "2026-12-31T00:00:00Z", <#m_-5924348180814128079_m_4172614838933896567_cb4-13> "caveat": [{ <#m_-5924348180814128079_m_4172614838933896567_cb4-14> "type": "odrl:Permission", <#m_-5924348180814128079_m_4172614838933896567_cb4-15> "odrl:action": ["odrl:read"], <#m_-5924348180814128079_m_4172614838933896567_cb4-16> "odrl:constraint": [{ <#m_-5924348180814128079_m_4172614838933896567_cb4-17> "odrl:leftOperand": "odrl:target", <#m_-5924348180814128079_m_4172614838933896567_cb4-18> "odrl:operator": "odrl:isPartOf", <#m_-5924348180814128079_m_4172614838933896567_cb4-19> "odrl:rightOperand": { <#m_-5924348180814128079_m_4172614838933896567_cb4-20> "@value": "https://docs.acme.example/legal/contracts" <#m_-5924348180814128079_m_4172614838933896567_cb4-21> } <#m_-5924348180814128079_m_4172614838933896567_cb4-22> }] <#m_-5924348180814128079_m_4172614838933896567_cb4-23> }], <#m_-5924348180814128079_m_4172614838933896567_cb4-24> "proof": { <#m_-5924348180814128079_m_4172614838933896567_cb4-25> "type": "Ed25519Signature2020", <#m_-5924348180814128079_m_4172614838933896567_cb4-26> "proofPurpose": "capabilityDelegation", <#m_-5924348180814128079_m_4172614838933896567_cb4-27> "capabilityChain": [ <#m_-5924348180814128079_m_4172614838933896567_cb4-28> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-5924348180814128079_m_4172614838933896567_cb4-29> ], <#m_-5924348180814128079_m_4172614838933896567_cb4-30> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-5924348180814128079_m_4172614838933896567_cb4-31> "proofValue": "z..." <#m_-5924348180814128079_m_4172614838933896567_cb4-32> } <#m_-5924348180814128079_m_4172614838933896567_cb4-33>}
>>
>> A verifier implementing only the minimal profile evaluates this exactly
>> as it evaluated the URL prefix before. Semantically identical; now explicit
>> and standard.
>> ------------------------------
>> Example 3: Second delegation — current spec
>>
>> The junior lawyer delegates to a paralegal, restricted to a single
>> client’s contracts folder.
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb5-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb5-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-5924348180814128079_m_4172614838933896567_cb5-3> "id": "urn:uuid:b1c2d3e4-0002", <#m_-5924348180814128079_m_4172614838933896567_cb5-4> "parentCapability": "urn:uuid:b1c2d3e4-0001", <#m_-5924348180814128079_m_4172614838933896567_cb5-5> "controller": "did:key:z6MkParalegal", <#m_-5924348180814128079_m_4172614838933896567_cb5-6> "invocationTarget": <#m_-5924348180814128079_m_4172614838933896567_cb5-7> "https://docs.acme.example/legal/contracts/client-xyz", <#m_-5924348180814128079_m_4172614838933896567_cb5-8> "allowedAction": ["read"], <#m_-5924348180814128079_m_4172614838933896567_cb5-9> "expires": "2026-06-30T00:00:00Z", <#m_-5924348180814128079_m_4172614838933896567_cb5-10> "proof": { <#m_-5924348180814128079_m_4172614838933896567_cb5-11> "type": "Ed25519Signature2020", <#m_-5924348180814128079_m_4172614838933896567_cb5-12> "proofPurpose": "capabilityDelegation", <#m_-5924348180814128079_m_4172614838933896567_cb5-13> "capabilityChain": [ <#m_-5924348180814128079_m_4172614838933896567_cb5-14> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb5-15> { "id": "urn:uuid:b1c2d3e4-0001", "...": "full zcap embedded" } <#m_-5924348180814128079_m_4172614838933896567_cb5-16> ], <#m_-5924348180814128079_m_4172614838933896567_cb5-17> "verificationMethod": "did:key:z6MkJuniorLawyer#key-1", <#m_-5924348180814128079_m_4172614838933896567_cb5-18> "proofValue": "z..." <#m_-5924348180814128079_m_4172614838933896567_cb5-19> } <#m_-5924348180814128079_m_4172614838933896567_cb5-20>}
>>
>> ------------------------------
>> Example 3 (revised): Second delegation — ODRL minimal profile
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb6-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb6-2> "@context": [ <#m_-5924348180814128079_m_4172614838933896567_cb6-3> "https://w3id.org/zcap/v1", <#m_-5924348180814128079_m_4172614838933896567_cb6-4> "https://www.w3.org/ns/odrl/2/" <#m_-5924348180814128079_m_4172614838933896567_cb6-5> ], <#m_-5924348180814128079_m_4172614838933896567_cb6-6> "id": "urn:uuid:b1c2d3e4-0002", <#m_-5924348180814128079_m_4172614838933896567_cb6-7> "parentCapability": "urn:uuid:b1c2d3e4-0001", <#m_-5924348180814128079_m_4172614838933896567_cb6-8> "controller": "did:key:z6MkParalegal", <#m_-5924348180814128079_m_4172614838933896567_cb6-9> "invocationTarget": <#m_-5924348180814128079_m_4172614838933896567_cb6-10> "https://docs.acme.example/legal/contracts/client-xyz", <#m_-5924348180814128079_m_4172614838933896567_cb6-11> "allowedAction": ["read"], <#m_-5924348180814128079_m_4172614838933896567_cb6-12> "expires": "2026-06-30T00:00:00Z", <#m_-5924348180814128079_m_4172614838933896567_cb6-13> "caveat": [{ <#m_-5924348180814128079_m_4172614838933896567_cb6-14> "type": "odrl:Permission", <#m_-5924348180814128079_m_4172614838933896567_cb6-15> "odrl:action": ["odrl:read"], <#m_-5924348180814128079_m_4172614838933896567_cb6-16> "odrl:constraint": [{ <#m_-5924348180814128079_m_4172614838933896567_cb6-17> "odrl:leftOperand": "odrl:target", <#m_-5924348180814128079_m_4172614838933896567_cb6-18> "odrl:operator": "odrl:eq", <#m_-5924348180814128079_m_4172614838933896567_cb6-19> "odrl:rightOperand": { <#m_-5924348180814128079_m_4172614838933896567_cb6-20> "@value": <#m_-5924348180814128079_m_4172614838933896567_cb6-21> "https://docs.acme.example/legal/contracts/client-xyz" <#m_-5924348180814128079_m_4172614838933896567_cb6-22> } <#m_-5924348180814128079_m_4172614838933896567_cb6-23> }] <#m_-5924348180814128079_m_4172614838933896567_cb6-24> }], <#m_-5924348180814128079_m_4172614838933896567_cb6-25> "proof": { <#m_-5924348180814128079_m_4172614838933896567_cb6-26> "type": "Ed25519Signature2020", <#m_-5924348180814128079_m_4172614838933896567_cb6-27> "proofPurpose": "capabilityDelegation", <#m_-5924348180814128079_m_4172614838933896567_cb6-28> "capabilityChain": [ <#m_-5924348180814128079_m_4172614838933896567_cb6-29> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb6-30> { "id": "urn:uuid:b1c2d3e4-0001", "...": "full zcap embedded" } <#m_-5924348180814128079_m_4172614838933896567_cb6-31> ], <#m_-5924348180814128079_m_4172614838933896567_cb6-32> "verificationMethod": "did:key:z6MkJuniorLawyer#key-1", <#m_-5924348180814128079_m_4172614838933896567_cb6-33> "proofValue": "z..." <#m_-5924348180814128079_m_4172614838933896567_cb6-34> } <#m_-5924348180814128079_m_4172614838933896567_cb6-35>}
>>
>> The constraint narrows from isPartOf /legal/contracts (parent) to eq
>> /legal/contracts/client-xyz (this delegation). A verifier checks
>> monotonicity: the satisfying set of eq client-xyz is a subset of the
>> satisfying set of isPartOf /legal/contracts. Monotonicity holds. The
>> check is a simple string containment, identical in cost to the URL prefix
>> check.
>> ------------------------------
>> Example 4: What ODRL enables beyond URL-path attenuation
>>
>> *Scenario:* The senior lawyer wants to grant a paralegal read access to
>> contracts for active clients only (not closed matters), during business
>> hours only, and no more than 20 documents per day. None of this is
>> expressible with URL path attenuation — the document’s status, the time of
>> day, and the access count are not properties of the URL.
>>
>> *Current spec:* Inexpressible. Three workarounds, all bad: (a) build
>> status, time, and count into the URL hierarchy and restructure the entire
>> API; (b) implement these constraints in application logic outside the zcap
>> chain, where they are invisible to delegatees and unauditable; (c) issue
>> separate zcaps for each case and manage their lifecycle manually.
>>
>> *With an extended ODRL profile:*
>>
>> <#m_-5924348180814128079_m_4172614838933896567_cb7-1>{ <#m_-5924348180814128079_m_4172614838933896567_cb7-2> "@context": [ <#m_-5924348180814128079_m_4172614838933896567_cb7-3> "https://w3id.org/zcap/v1", <#m_-5924348180814128079_m_4172614838933896567_cb7-4> "https://www.w3.org/ns/odrl/2/" <#m_-5924348180814128079_m_4172614838933896567_cb7-5> ], <#m_-5924348180814128079_m_4172614838933896567_cb7-6> "id": "urn:uuid:b1c2d3e4-0003", <#m_-5924348180814128079_m_4172614838933896567_cb7-7> "parentCapability": <#m_-5924348180814128079_m_4172614838933896567_cb7-8> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-5924348180814128079_m_4172614838933896567_cb7-9> "controller": "did:key:z6MkParalegal", <#m_-5924348180814128079_m_4172614838933896567_cb7-10> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-5924348180814128079_m_4172614838933896567_cb7-11> "allowedAction": ["read"], <#m_-5924348180814128079_m_4172614838933896567_cb7-12> "expires": "2026-12-31T00:00:00Z", <#m_-5924348180814128079_m_4172614838933896567_cb7-13> "caveat": [{ <#m_-5924348180814128079_m_4172614838933896567_cb7-14> "type": "odrl:Permission", <#m_-5924348180814128079_m_4172614838933896567_cb7-15> "odrl:action": ["odrl:read"], <#m_-5924348180814128079_m_4172614838933896567_cb7-16> "odrl:constraint": [{ <#m_-5924348180814128079_m_4172614838933896567_cb7-17> "odrl:and": [ <#m_-5924348180814128079_m_4172614838933896567_cb7-18> { <#m_-5924348180814128079_m_4172614838933896567_cb7-19> "odrl:leftOperand": "odrl:target", <#m_-5924348180814128079_m_4172614838933896567_cb7-20> "odrl:operator": "odrl:isPartOf", <#m_-5924348180814128079_m_4172614838933896567_cb7-21> "odrl:rightOperand": { <#m_-5924348180814128079_m_4172614838933896567_cb7-22> "@value": <#m_-5924348180814128079_m_4172614838933896567_cb7-23> "https://docs.acme.example/legal/contracts" <#m_-5924348180814128079_m_4172614838933896567_cb7-24> } <#m_-5924348180814128079_m_4172614838933896567_cb7-25> }, <#m_-5924348180814128079_m_4172614838933896567_cb7-26> { <#m_-5924348180814128079_m_4172614838933896567_cb7-27> "odrl:leftOperand": "odrl:status", <#m_-5924348180814128079_m_4172614838933896567_cb7-28> "odrl:operator": "odrl:eq", <#m_-5924348180814128079_m_4172614838933896567_cb7-29> "odrl:rightOperand": {"@value": "active"} <#m_-5924348180814128079_m_4172614838933896567_cb7-30> }, <#m_-5924348180814128079_m_4172614838933896567_cb7-31> { <#m_-5924348180814128079_m_4172614838933896567_cb7-32> "odrl:leftOperand": "odrl:timeInterval", <#m_-5924348180814128079_m_4172614838933896567_cb7-33> "odrl:operator": "odrl:isPartOf", <#m_-5924348180814128079_m_4172614838933896567_cb7-34> "odrl:rightOperand": {"@value": "09:00/17:00"} <#m_-5924348180814128079_m_4172614838933896567_cb7-35> }, <#m_-5924348180814128079_m_4172614838933896567_cb7-36> { <#m_-5924348180814128079_m_4172614838933896567_cb7-37> "odrl:leftOperand": "odrl:count", <#m_-5924348180814128079_m_4172614838933896567_cb7-38> "odrl:operator": "odrl:lteq", <#m_-5924348180814128079_m_4172614838933896567_cb7-39> "odrl:rightOperand": <#m_-5924348180814128079_m_4172614838933896567_cb7-40> {"@value": "20", "@type": "xsd:integer"}, <#m_-5924348180814128079_m_4172614838933896567_cb7-41> "odrl:unitOfCount": "odrl:perDay" <#m_-5924348180814128079_m_4172614838933896567_cb7-42> } <#m_-5924348180814128079_m_4172614838933896567_cb7-43> ] <#m_-5924348180814128079_m_4172614838933896567_cb7-44> }] <#m_-5924348180814128079_m_4172614838933896567_cb7-45> }], <#m_-5924348180814128079_m_4172614838933896567_cb7-46> "proof": { <#m_-5924348180814128079_m_4172614838933896567_cb7-47> "type": "Ed25519Signature2020", <#m_-5924348180814128079_m_4172614838933896567_cb7-48> "proofPurpose": "capabilityDelegation", <#m_-5924348180814128079_m_4172614838933896567_cb7-49> "capabilityChain": [ <#m_-5924348180814128079_m_4172614838933896567_cb7-50> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-5924348180814128079_m_4172614838933896567_cb7-51> ], <#m_-5924348180814128079_m_4172614838933896567_cb7-52> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-5924348180814128079_m_4172614838933896567_cb7-53> "proofValue": "z..." <#m_-5924348180814128079_m_4172614838933896567_cb7-54> } <#m_-5924348180814128079_m_4172614838933896567_cb7-55>}
>>
>> All four constraints are evaluated locally by the document management
>> server. No network calls. The evaluation is bounded and decidable. The
>> paralegal who receives this zcap can read the caveat and understand exactly
>> what authority they hold — which is itself a security property: authority
>> is legible, not hidden in server-side policy logic.
>> ------------------------------
>> Summary
>> Current spec Minimal ODRL profile Extended ODRL profile
>> Root caveats Not permitted Permitted Permitted
>> Implicit delegation visible No Yes Yes
>> Attenuation vocabulary URL prefix (implicit) odrl:isPartOf (explicit) Full
>> ODRL constraint set
>> Monotonicity enforcement URL string containment Constraint set
>> containment Constraint set containment
>> Backward compatible — Yes Opt-in per verifier
>> Verifier complexity String prefix check Same + ODRL parser ODRL
>> constraint evaluator
>> Legibility for delegatee Poor Good Good
>>
>> The minimal ODRL profile is a direct, backward-compatible replacement for
>> URL-path attenuation, with no additional security risk and improved
>> legibility. The extended profile enables use cases that are currently
>> inexpressible. Both require only that the root zcap’s MUST NOT restriction
>> be relaxed to permit caveat fields.
>>
>> On Wed, Apr 1, 2026 at 8:06 PM Dmitri Zagidulin <dzagidulin@gmail.com>
>> wrote:
>>
>>> Hi all,
>>> A few weeks ago on the CCG call discussing the various work items, I
>>> brought up the subject of zCaps (Authorization Capabilities), which is an
>>> existing (if somewhat dormant) CCG work item, at
>>> https://github.com/w3c-ccg/zcap-spec. And several people have expressed
>>> interest in working on that spec again.
>>>
>>> In parallel, the Delegated Authorization Task Force of the Trusted AI
>>> Agent WG at DIF has been evaluating various delegated authorization
>>> specifications (including zCaps, various OAuth-based specs, UCANs, GNAP,
>>> and many others), and has determined that there's not many authorization
>>> options out there with chained delegation ability (basically, zCaps
>>> (JSON-based) and UCANs (DAG-CBOR-based) are the only ones). This is
>>> especially relevant and timely due to all the momentum and activity behind
>>> agent-based development, and the lack of authorization and guardrails in
>>> that area.
>>>
>>> To that end, I'd like to restart work on the zCap spec here at the CCG.
>>> The current spec version is v0.3, but it's been out of sync with the way
>>> zcaps have been deployed to production by the TruAge project, Digital
>>> Bazaar, DCC, and others.
>>> So our first goal would be to just update the spec to v0.4, to match the
>>> existing implementations.
>>>
>>> It would be also great to start work on version v0.5, as several new use
>>> cases and feature requests have come up in the meantime.
>>>
>>> So, couple of questions of the group:
>>>
>>> 1. Would anyone like to help edit the spec?
>>>
>>> 2. Would folks be interested in a zCap task force call, either monthly
>>> or bi-weekly, to work on the spec?
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
Received on Thursday, 2 April 2026 17:58:01 UTC