AuthZEN Actor Delegation Profile - Draft 1

Table of Contents

1. Introduction

This companion to the AuthZEN Access Request and Approval Profile [ARAP] defines the client.actor and client.source members of an Access Request submission, the delegation model they express, and the verification an Access Request Service applies to a claimed actor chain. The base profile's rules that reference these members remain there: the PEP preserves the actor identity when it submits, the Access Request Service does not treat unverified actor content as authorization input, and structural comparison excludes subject.properties.act because the PEP may carry the actor here instead.¶

2. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The terms PEP, PDP, Subject, Resource, Action, Context, Access Request, and Access Request Service are used as defined by [ARAP].¶

3. Delegation and Acting Parties

A PEP often acts for upstream principals: an application for a user, an Authorization Server for a client and user, an agent runtime for an agent and user, or a Security Token Service for an upstream caller.¶

This profile does not define a new Subject shape for actor delegation. Implementations SHOULD follow the conventions defined in [I-D.mcguinness-oauth-actor-profile], which standardizes an act claim representing the immediate actor with required sub and iss members and a RECOMMENDED sub_profile member (taking values such as ai_agent, service, or user). Nested act objects represent multi-hop delegation chains. The canonical actor identifier is the (iss, sub) pair regardless of which carrier expresses it.¶

Under this profile:¶

• The AuthZEN Authorization API subject carries the principal on whose behalf the operation is performed.¶

• client.actor (defined in Section 3.1) carries the immediate actor and MAY include a nested act claim that walks the delegation chain from the immediate actor outward toward the Subject.¶

Approval routing at the Access Request Service MAY consider any identity in the chain (for example, routing approval to the principal's owner, the agent's deployment owner, or a delegated approver). This profile otherwise leaves routing policy unconstrained; it requires that the necessary identities be representable in the submission and verifiable by the service before routing decisions are taken.¶

Cross-implementation interoperability for delegated flows depends on adoption of a common actor convention. Deployments and profiles that depend on a specific actor convention SHOULD document the Subject shape, the actor convention used, and the credential format the Access Request Service accepts as proof of the chain.¶

4. Interaction with the Base Profile

The base profile states three rules that reference the members defined here; this profile does not restate them.¶

• A PEP preserves the actor identity conveyed in the denied evaluation's Subject, either in the submission's subject or normalized to client.actor (Construct the Submission).¶

• An Access Request Service does not rely on client.actor or client.source as authorization input unless it has independently verified them (Submission Processing).¶

• Structural comparison for denial binding and approval scope excludes subject.properties.act (Structural Comparison).¶

5. Security Considerations

PEP acting on behalf of the Subject. Accepting unverified actor claims would let a PEP assert authority it cannot demonstrate. Section 3.2 governs chain verification; the base profile's endpoint protection requires caller authorization to submit or view the request for the supplied Subject, Resource, and Action.¶

The identity-binding questions the base profile records for the caller, requester, and client apply to the acting party as well; this profile does not resolve them.¶

6. Privacy Considerations

The privacy considerations of [ARAP] apply. client.source identifiers (session_id, external_url, integration_id) can link an Access Request to a conversation, application session, or external record; deployments populate them where audit policy requires and protect them as they protect approver and workflow details.¶

7. IANA Considerations

This specification makes no requests of IANA.¶

8. OpenID Foundation Registry Considerations

9. References

Appendix A. Examples

POST /access/v1/requests HTTP/1.1
Host: pdp.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Content-Type: application/json
Idempotency-Key: 9c1f5d12-2a18-4cba-8a5e-e0e8e2b6b5c7

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "tool",
    "id": "crm.search_accounts"
  },
  "action": {
    "name": "invoke"
  },
  "context": {
    "business_justification": "Assembling Q2 renewal report for customer ACME-1042"
  },
  "requested_access": {
    "requested_until": "2026-05-19T15:00:00Z"
  },
  "client": {
    "id": "renewal_assistant",
    "actor": {
      "id": "agent_renewal_assistant_v3",
      "issuer": "https://agents.example.com",
      "type": "ai_agent"
    },
    "source": {
      "session_id": "session_01HX69WJ8Q0K7P4F0V0K9D6Z7N"
    }
  },
  "denial": {
    "evaluation_id": "eval_01HX6A9D2M7N0F4G3K2T9P1B8X",
    "evaluated_at": "2026-05-12T15:00:00Z",
    "expires_at": "2026-05-12T15:10:00Z",
    "reason": "agent_authority_missing",
    "binding_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0.eyJldmFsdWF0aW9uX2lkIjoiZXZhbF8wMUhYNkE5RDJNN04wRjRHM0syVDlQMUI4WCIsImNsYXNzIjoiY3JtX3Rvb2xzIn0.aGFzaA",
    "template": "agent_tool_class_approval"
  }
}

Appendix B. Document History

-00¶

• Extracted actor delegation, the client.actor and client.source members, and actor-chain verification from the AuthZEN Access Request and Approval Profile without changing their force or conditions.¶

Author's Address