- From: Alan Karp <alanhkarp@gmail.com>
- Date: Thu, 2 Apr 2026 10:28:47 -0700
- To: Bob Wyman <bob@wyman.us>
- Cc: dzagidulin@gmail.com, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANpA1Z3RkWHnXXSDPVPb08GoMw=gucaST6CDZGfy0YPmoO32dg@mail.gmail.com>
If we're in a crowded room, and I whisper something in your ear, you know
that I've told you a secret. I can't keep you from blabbing it around, but
at least you know my policy. That's something that would be nice to be
able to communicate along with a delegation.
There are enough questions with how to communicate policy that we decided
for now we'll leave that communication out of band. ORDL solves part of
the problem, but there are still issues. I'm most concerned about
ontology. How do you express an organization specific policy in a way that
another organization can understand? Say, for example, that you are
delegating a report from the Research department that you don't want people
in the Sales department to see. Maybe the other company calls its research
department Advanced Development and its sales department Marketing.
I'm sure these problems can be solved, but we might be better off focusing
on the basics first.
--------------
Alan Karp
On Thu, Apr 2, 2026 at 7:49 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_-1452600974320842809_cb1-1>{ <#m_-1452600974320842809_cb1-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-1452600974320842809_cb1-3> "id": "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb1-4> "controller": "did:key:z6MkSeniorLawyer", <#m_-1452600974320842809_cb1-5> "invocationTarget": "https://docs.acme.example/legal" <#m_-1452600974320842809_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_-1452600974320842809_cb2-1>{ <#m_-1452600974320842809_cb2-2> "@context": [ <#m_-1452600974320842809_cb2-3> "https://w3id.org/zcap/v1", <#m_-1452600974320842809_cb2-4> "https://www.w3.org/ns/odrl/2/" <#m_-1452600974320842809_cb2-5> ], <#m_-1452600974320842809_cb2-6> "id": "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb2-7> "controller": "did:key:z6MkSeniorLawyer", <#m_-1452600974320842809_cb2-8> "invocationTarget": "https://docs.acme.example/legal", <#m_-1452600974320842809_cb2-9> "caveat": [{ <#m_-1452600974320842809_cb2-10> "type": "odrl:Permission", <#m_-1452600974320842809_cb2-11> "odrl:action": ["odrl:read", "odrl:write", "odrl:delete"], <#m_-1452600974320842809_cb2-12> "odrl:constraint": [{ <#m_-1452600974320842809_cb2-13> "odrl:leftOperand": "odrl:recipient", <#m_-1452600974320842809_cb2-14> "odrl:operator": "odrl:isPartOf", <#m_-1452600974320842809_cb2-15> "odrl:rightOperand": { <#m_-1452600974320842809_cb2-16> "@value": "https://directory.acme.example/employees" <#m_-1452600974320842809_cb2-17> } <#m_-1452600974320842809_cb2-18> }] <#m_-1452600974320842809_cb2-19> }] <#m_-1452600974320842809_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_-1452600974320842809_cb3-1>{ <#m_-1452600974320842809_cb3-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-1452600974320842809_cb3-3> "id": "urn:uuid:b1c2d3e4-0001", <#m_-1452600974320842809_cb3-4> "parentCapability": <#m_-1452600974320842809_cb3-5> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb3-6> "controller": "did:key:z6MkJuniorLawyer", <#m_-1452600974320842809_cb3-7> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-1452600974320842809_cb3-8> "allowedAction": ["read"], <#m_-1452600974320842809_cb3-9> "expires": "2026-12-31T00:00:00Z", <#m_-1452600974320842809_cb3-10> "proof": { <#m_-1452600974320842809_cb3-11> "type": "Ed25519Signature2020", <#m_-1452600974320842809_cb3-12> "proofPurpose": "capabilityDelegation", <#m_-1452600974320842809_cb3-13> "capabilityChain": [ <#m_-1452600974320842809_cb3-14> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-1452600974320842809_cb3-15> ], <#m_-1452600974320842809_cb3-16> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-1452600974320842809_cb3-17> "proofValue": "z..." <#m_-1452600974320842809_cb3-18> } <#m_-1452600974320842809_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_-1452600974320842809_cb4-1>{ <#m_-1452600974320842809_cb4-2> "@context": [ <#m_-1452600974320842809_cb4-3> "https://w3id.org/zcap/v1", <#m_-1452600974320842809_cb4-4> "https://www.w3.org/ns/odrl/2/" <#m_-1452600974320842809_cb4-5> ], <#m_-1452600974320842809_cb4-6> "id": "urn:uuid:b1c2d3e4-0001", <#m_-1452600974320842809_cb4-7> "parentCapability": <#m_-1452600974320842809_cb4-8> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb4-9> "controller": "did:key:z6MkJuniorLawyer", <#m_-1452600974320842809_cb4-10> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-1452600974320842809_cb4-11> "allowedAction": ["read"], <#m_-1452600974320842809_cb4-12> "expires": "2026-12-31T00:00:00Z", <#m_-1452600974320842809_cb4-13> "caveat": [{ <#m_-1452600974320842809_cb4-14> "type": "odrl:Permission", <#m_-1452600974320842809_cb4-15> "odrl:action": ["odrl:read"], <#m_-1452600974320842809_cb4-16> "odrl:constraint": [{ <#m_-1452600974320842809_cb4-17> "odrl:leftOperand": "odrl:target", <#m_-1452600974320842809_cb4-18> "odrl:operator": "odrl:isPartOf", <#m_-1452600974320842809_cb4-19> "odrl:rightOperand": { <#m_-1452600974320842809_cb4-20> "@value": "https://docs.acme.example/legal/contracts" <#m_-1452600974320842809_cb4-21> } <#m_-1452600974320842809_cb4-22> }] <#m_-1452600974320842809_cb4-23> }], <#m_-1452600974320842809_cb4-24> "proof": { <#m_-1452600974320842809_cb4-25> "type": "Ed25519Signature2020", <#m_-1452600974320842809_cb4-26> "proofPurpose": "capabilityDelegation", <#m_-1452600974320842809_cb4-27> "capabilityChain": [ <#m_-1452600974320842809_cb4-28> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-1452600974320842809_cb4-29> ], <#m_-1452600974320842809_cb4-30> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-1452600974320842809_cb4-31> "proofValue": "z..." <#m_-1452600974320842809_cb4-32> } <#m_-1452600974320842809_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_-1452600974320842809_cb5-1>{ <#m_-1452600974320842809_cb5-2> "@context": ["https://w3id.org/zcap/v1"], <#m_-1452600974320842809_cb5-3> "id": "urn:uuid:b1c2d3e4-0002", <#m_-1452600974320842809_cb5-4> "parentCapability": "urn:uuid:b1c2d3e4-0001", <#m_-1452600974320842809_cb5-5> "controller": "did:key:z6MkParalegal", <#m_-1452600974320842809_cb5-6> "invocationTarget": <#m_-1452600974320842809_cb5-7> "https://docs.acme.example/legal/contracts/client-xyz", <#m_-1452600974320842809_cb5-8> "allowedAction": ["read"], <#m_-1452600974320842809_cb5-9> "expires": "2026-06-30T00:00:00Z", <#m_-1452600974320842809_cb5-10> "proof": { <#m_-1452600974320842809_cb5-11> "type": "Ed25519Signature2020", <#m_-1452600974320842809_cb5-12> "proofPurpose": "capabilityDelegation", <#m_-1452600974320842809_cb5-13> "capabilityChain": [ <#m_-1452600974320842809_cb5-14> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb5-15> { "id": "urn:uuid:b1c2d3e4-0001", "...": "full zcap embedded" } <#m_-1452600974320842809_cb5-16> ], <#m_-1452600974320842809_cb5-17> "verificationMethod": "did:key:z6MkJuniorLawyer#key-1", <#m_-1452600974320842809_cb5-18> "proofValue": "z..." <#m_-1452600974320842809_cb5-19> } <#m_-1452600974320842809_cb5-20>}
>
> ------------------------------
> Example 3 (revised): Second delegation — ODRL minimal profile
>
> <#m_-1452600974320842809_cb6-1>{ <#m_-1452600974320842809_cb6-2> "@context": [ <#m_-1452600974320842809_cb6-3> "https://w3id.org/zcap/v1", <#m_-1452600974320842809_cb6-4> "https://www.w3.org/ns/odrl/2/" <#m_-1452600974320842809_cb6-5> ], <#m_-1452600974320842809_cb6-6> "id": "urn:uuid:b1c2d3e4-0002", <#m_-1452600974320842809_cb6-7> "parentCapability": "urn:uuid:b1c2d3e4-0001", <#m_-1452600974320842809_cb6-8> "controller": "did:key:z6MkParalegal", <#m_-1452600974320842809_cb6-9> "invocationTarget": <#m_-1452600974320842809_cb6-10> "https://docs.acme.example/legal/contracts/client-xyz", <#m_-1452600974320842809_cb6-11> "allowedAction": ["read"], <#m_-1452600974320842809_cb6-12> "expires": "2026-06-30T00:00:00Z", <#m_-1452600974320842809_cb6-13> "caveat": [{ <#m_-1452600974320842809_cb6-14> "type": "odrl:Permission", <#m_-1452600974320842809_cb6-15> "odrl:action": ["odrl:read"], <#m_-1452600974320842809_cb6-16> "odrl:constraint": [{ <#m_-1452600974320842809_cb6-17> "odrl:leftOperand": "odrl:target", <#m_-1452600974320842809_cb6-18> "odrl:operator": "odrl:eq", <#m_-1452600974320842809_cb6-19> "odrl:rightOperand": { <#m_-1452600974320842809_cb6-20> "@value": <#m_-1452600974320842809_cb6-21> "https://docs.acme.example/legal/contracts/client-xyz" <#m_-1452600974320842809_cb6-22> } <#m_-1452600974320842809_cb6-23> }] <#m_-1452600974320842809_cb6-24> }], <#m_-1452600974320842809_cb6-25> "proof": { <#m_-1452600974320842809_cb6-26> "type": "Ed25519Signature2020", <#m_-1452600974320842809_cb6-27> "proofPurpose": "capabilityDelegation", <#m_-1452600974320842809_cb6-28> "capabilityChain": [ <#m_-1452600974320842809_cb6-29> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb6-30> { "id": "urn:uuid:b1c2d3e4-0001", "...": "full zcap embedded" } <#m_-1452600974320842809_cb6-31> ], <#m_-1452600974320842809_cb6-32> "verificationMethod": "did:key:z6MkJuniorLawyer#key-1", <#m_-1452600974320842809_cb6-33> "proofValue": "z..." <#m_-1452600974320842809_cb6-34> } <#m_-1452600974320842809_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_-1452600974320842809_cb7-1>{ <#m_-1452600974320842809_cb7-2> "@context": [ <#m_-1452600974320842809_cb7-3> "https://w3id.org/zcap/v1", <#m_-1452600974320842809_cb7-4> "https://www.w3.org/ns/odrl/2/" <#m_-1452600974320842809_cb7-5> ], <#m_-1452600974320842809_cb7-6> "id": "urn:uuid:b1c2d3e4-0003", <#m_-1452600974320842809_cb7-7> "parentCapability": <#m_-1452600974320842809_cb7-8> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal", <#m_-1452600974320842809_cb7-9> "controller": "did:key:z6MkParalegal", <#m_-1452600974320842809_cb7-10> "invocationTarget": "https://docs.acme.example/legal/contracts", <#m_-1452600974320842809_cb7-11> "allowedAction": ["read"], <#m_-1452600974320842809_cb7-12> "expires": "2026-12-31T00:00:00Z", <#m_-1452600974320842809_cb7-13> "caveat": [{ <#m_-1452600974320842809_cb7-14> "type": "odrl:Permission", <#m_-1452600974320842809_cb7-15> "odrl:action": ["odrl:read"], <#m_-1452600974320842809_cb7-16> "odrl:constraint": [{ <#m_-1452600974320842809_cb7-17> "odrl:and": [ <#m_-1452600974320842809_cb7-18> { <#m_-1452600974320842809_cb7-19> "odrl:leftOperand": "odrl:target", <#m_-1452600974320842809_cb7-20> "odrl:operator": "odrl:isPartOf", <#m_-1452600974320842809_cb7-21> "odrl:rightOperand": { <#m_-1452600974320842809_cb7-22> "@value": <#m_-1452600974320842809_cb7-23> "https://docs.acme.example/legal/contracts" <#m_-1452600974320842809_cb7-24> } <#m_-1452600974320842809_cb7-25> }, <#m_-1452600974320842809_cb7-26> { <#m_-1452600974320842809_cb7-27> "odrl:leftOperand": "odrl:status", <#m_-1452600974320842809_cb7-28> "odrl:operator": "odrl:eq", <#m_-1452600974320842809_cb7-29> "odrl:rightOperand": {"@value": "active"} <#m_-1452600974320842809_cb7-30> }, <#m_-1452600974320842809_cb7-31> { <#m_-1452600974320842809_cb7-32> "odrl:leftOperand": "odrl:timeInterval", <#m_-1452600974320842809_cb7-33> "odrl:operator": "odrl:isPartOf", <#m_-1452600974320842809_cb7-34> "odrl:rightOperand": {"@value": "09:00/17:00"} <#m_-1452600974320842809_cb7-35> }, <#m_-1452600974320842809_cb7-36> { <#m_-1452600974320842809_cb7-37> "odrl:leftOperand": "odrl:count", <#m_-1452600974320842809_cb7-38> "odrl:operator": "odrl:lteq", <#m_-1452600974320842809_cb7-39> "odrl:rightOperand": <#m_-1452600974320842809_cb7-40> {"@value": "20", "@type": "xsd:integer"}, <#m_-1452600974320842809_cb7-41> "odrl:unitOfCount": "odrl:perDay" <#m_-1452600974320842809_cb7-42> } <#m_-1452600974320842809_cb7-43> ] <#m_-1452600974320842809_cb7-44> }] <#m_-1452600974320842809_cb7-45> }], <#m_-1452600974320842809_cb7-46> "proof": { <#m_-1452600974320842809_cb7-47> "type": "Ed25519Signature2020", <#m_-1452600974320842809_cb7-48> "proofPurpose": "capabilityDelegation", <#m_-1452600974320842809_cb7-49> "capabilityChain": [ <#m_-1452600974320842809_cb7-50> "urn:zcap:root:https%3A%2F%2Fdocs.acme.example%2Flegal" <#m_-1452600974320842809_cb7-51> ], <#m_-1452600974320842809_cb7-52> "verificationMethod": "did:key:z6MkSeniorLawyer#key-1", <#m_-1452600974320842809_cb7-53> "proofValue": "z..." <#m_-1452600974320842809_cb7-54> } <#m_-1452600974320842809_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:29:03 UTC