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 milestone.

The selected milestone should first implement the simpler rule:

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:

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:

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

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:

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:

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.

Keyboard shortcuts