[UC] Scoped Delegation Chains with Enforced Authority Narrowing Across Multi-Hop Agent Workflows

### Summary

When a human delegates authority to an agent, and that agent further delegates to sub-agents, each link in the chain must enforce that authority can only narrow — never widen. This must be cryptographic enforcement at the credential level, not policy enforcement at the platform level.

### Driving User Story

**As an enterprise security architect deploying AI agents via MCP,**
**I want delegation chains where each sub-agent's scope is mathematically constrained to a subset of its parent's scope,**
**With cryptographic proof that no agent in the chain can exceed its delegated authority,**
**So that I can deploy multi-hop agent workflows without risking privilege escalation at any delegation boundary.**

## Context

* I have looked for similar use cases and feel this issue is a distinct use case, rather than best encoded as a variant of an existing one.

This use case addresses **authority attenuation in synchronous multi-hop delegation** — a complement to #24's focus on capability continuity across asynchronous boundaries. Where #24 asks "does the capability survive the transport?", this use case asks "does the capability narrow correctly at each delegation hop?"

The distinction matters because scope narrowing is a DAG traversal problem with different verification semantics than capability survival. At each hop:
- Child scope = set intersection of (parent scope, requested child scope)
- Child TTL ≤ parent TTL
- Revocation of any node cascades to all descendants

These constraints must be enforced cryptographically (at the credential layer) rather than by policy (at the platform layer), because agents may cross organizational and platform boundaries where no single policy engine has authority.

## Actors
- **Human principal** — Alice, Senior Buyer at Acme Corp
- **Primary agent** — ShoppingBot, delegated purchasing authority
- **Sub-agent** — PriceChecker, delegated browse-only authority
- **Verifying service** — MCP server requiring authenticated, scoped access

## Scenario

1. Alice authenticates via enterprise IdP (Okta) and receives a W3C Verifiable Credential attesting her organizational role and purchasing authority.

2. Alice delegates to ShoppingBot via a DelegationCredential: `scope = [browse_products, add_to_cart, purchase]`, `max_amount = $500`, `TTL = 60 minutes`.

3. ShoppingBot delegates to PriceChecker: `scope = [browse_products]`, `max_amount = $500`, `TTL = 60 minutes`.

4. PriceChecker attempts to delegate to ComparisonEngine with `scope = [browse_products, purchase]`. **This MUST fail** — PriceChecker only has `[browse_products]` and cannot grant `[purchase]`.

5. PriceChecker accesses an MCP server. The server verifies the full delegation chain: Alice → ShoppingBot → PriceChecker. At each hop, scope is the set intersection of parent and child. The server confirms PriceChecker can only browse, not purchase.

6. Alice revokes ShoppingBot's delegation. This **cascades**: PriceChecker and any of its sub-agents are also revoked, regardless of where they're operating.

## Requirements

- **Scope narrowing enforcement:** Child scope ⊆ parent scope, verified cryptographically via set intersection at each chain hop
- **TTL binding:** Child credential TTL ≤ parent credential TTL
- **Cascade revocation:** Revoking any node invalidates all descendants
- **Depth limits:** Maximum chain depth is configurable and enforced
- **Cross-boundary verification:** A verifier with no prior relationship to the issuer can verify the full chain using W3C DIDs and VCs
- **Auditability:** Every delegation and every action taken under delegation is logged with the full identity chain

## Relevant Standards
- W3C Decentralized Identifiers (DIDs)
- W3C Verifiable Credentials Data Model v2
- W3C Bitstring Status List (for revocation)

## Related Use Cases
- **#24** — Causal capability across async boundaries. Complementary: #24 addresses where capability survives, this addresses how capability narrows.
- **#36** — Persistent identity across restarts. Complementary: trust continuity for long-running agents is a precondition for meaningful delegation chains in production.

## Open Questions

1. Should scope narrowing use strict set intersection or a more flexible capability attenuation model (e.g., UCAN-style invocations)?
2. How should cascade revocation propagate across organizational boundaries where the revoking party has no direct connection to downstream agents?
3. What is a reasonable maximum chain depth for production deployments?
4. How does this model compose with #24's causal capability tokens — could a delegation chain be expressed as a sequence of causally-linked capability attenuations?

## Reference Implementation

We have a working implementation of this pattern in Pramana Protocol (187 tests) using set intersection for scope narrowing, cascade revocation through depth 15, and an MCP gateway that verifies the full chain per-request. Happy to share details with the WG.