# Proposal: Delegated Subject Context

This proposal records the future model for acting on behalf of another subject.
It is intentionally out of scope for the selected
[Session-Bound Invocation Context](session-bound-invocation-context-proposal.md)
milestone.

The selected milestone should first implement the simpler rule:

```text
capability = authority to invoke
calling process session = who invokes
```

Cross-session capability transfer may delegate authority to invoke when the
capability's transfer policy permits it. That is not subject delegation.

## Problem

Some workflows legitimately need a process to act on behalf of a different
subject:

- a user asks an agent process to send a chat message for them;
- an operator grants a support session bounded access to perform one action;
- a service account performs a maintenance action for a tenant;
- an approval flow lets a worker complete a task in another principal's name.

The system must support this without making the receiving process "become" the
source subject. The caller's own process session remains the invoker for audit,
resource accounting, and privacy. The represented subject is separate,
explicit, scoped, and revocable.

## Design

Use a delegated-subject capability:

```text
SubjectDelegation {
    source_subject,
    delegate_subject_or_session,
    target_service,
    allowed_methods_or_purpose,
    disclosure_scope,
    expires_at,
}
```

The exact ABI may be a `SubjectDelegation` interface, a broker result cap, or a
service-specific delegation cap. The invariant is stable:

```text
invoked service cap = authority to call
calling process session = invoker
SubjectDelegation = represented subject context
```

Holding a `SubjectDelegation` is not enough to call a service. The caller must
also hold the service capability being invoked.

## Example

```text
Bob process session = Bob
Bob holds ChatRoot
Bob holds SubjectDelegation(Alice -> Bob, target_service = ChatRoot, scope = post)

ChatRoot.post(channel = "ops", text = "...", represented = AliceDelegation)
```

The service records:

```text
invoker = Bob session reference
represented_subject = Alice, through bounded delegation
authority_to_call = ChatRoot
```

Bob has not become Alice. Audit and abuse handling can still identify Bob as
the actor while showing that Alice delegated a bounded representation.

## Privacy

A delegated-subject capability must not disclose all source-subject facts. It
should carry or vend only the facts the issuer allowed for the target service,
such as:

- per-service display name;
- guest/operator class;
- a per-service audit pseudonym;
- a narrow claim such as "may approve invoice 123".

It should not expose account-store records, external IdP claim bags, credential
identifiers, global principal ids, or unrelated profile attributes by default.

## Relationship To Capability Transfer

Capability transfer and subject delegation are different operations:

```text
cap transfer only:
    receiver gets authority to invoke;
    receiver invokes as its own process session.

delegated subject context only:
    receiver may present a represented subject;
    no service method is callable unless receiver also holds a service cap.

cap transfer + delegated subject context:
    receiver invokes the cap as its own process session;
    service also sees the represented subject through explicit delegation.
```

The first implementation path should not depend on this proposal. Implement
session-bound invocation context, transfer scopes, and shared-service migration
first; add delegated subject context only after those rules are observable and
reviewed.

## Open Questions

- Whether the kernel should validate generic delegation metadata such as
  `target_service` and expiry, or whether services should validate the
  delegation cap through a method call.
- Whether delegated-subject caps are broker-owned, service-owned, or both.
- How revocation of delegated subject context composes with ordinary cap
  revoke/lease behavior.
- Whether the disclosure scope should be encoded as schema-specific facets or
  as a common metadata envelope.