proposal: Design DID Capability / zcap Authorization and capability_chain

[jolestar]

Proposal Details

Background

• Rooch plans to deprecate the legacy session_key scope model.
• We want to enforce on-chain authorization through DID capabilityInvocation together with zcap (object capabilities), as described in docs/dev-guide/did-capabilities-and-zcap.md.

Goals

1. Model revocable on-chain Capability objects that bind (account, vm_fragment) pairs, support default pointers, and allow building capability chains (delegation).
2. Extend did_validator so that:
   • The signing VM must appear in the DID document capabilityInvocation array.
   • Each transaction either provides an explicit capability_id or falls back to the per-VM default pointer.
   • The validator resolves the capability chain, verifies delegation links, ensures no capability in the chain is revoked, and checks that the target matches the invoked module/function.
   • Only explicit revocation is supported for now (no expiry or usage counters).
3. Update CLI / SDK tooling to issue, delegate, revoke capabilities, manage default pointers, and attach capability_id when submitting transactions.
4. Provide Move-side and end-to-end tests, including a Cap0→Cap1 delegation example and failure paths after revocation.

Suggested Task Breakdown

1. Implement a new rooch_framework::capability module:
   • Capability, Capabilities, RevokedCaps, DefaultCaps data structures.
   • APIs for issuing root capabilities, delegating, revoking, and target matching (aligned with the existing session scope semantics).
2. Extend did_validator:
   • Parse optional capability_id (or derive from default pointer).
   • Load the capability chain (either from on-chain storage or inline payload), verify delegation links, revocation state, VM binding, and target match.
   • Maintain backward-compatible behavior during the migration phase.
3. Enhance CLI / SDK:
   • Commands for capability issuance / delegation / revocation.
   • Support for configuring default capabilities per VM.
   • Transaction flow that attaches capability_id when required.
4. Testing & documentation: