Decision-Subject Representation for Agent Authorization

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC8693] and the agent-authorization profiles built on it model who acts (act) and who delegated (sub, [RFC7519]). A growing class of agent actions are decisions made about a third party who is neither the agent nor the delegator, and in the bystander case not the owner of the resource the action touches either. For these there is no way to name the party the action concerns; the concrete consequence is that an audit record cannot be addressed to it.¶

The gap is practical, not merely theoretical. In guardianship and delegated-operation cases, where one person operates a wallet that holds credentials for others, the presentation names the credential subject, but no independent record, one that records what was disclosed on their behalf, is addressed to the represented party. More generally, any pipeline that records denials, rankings, or eligibility outcomes as successful operator outputs leaves the party the outcome landed on unnamed. The party the record most concerns is often the party the record leaves out.¶

Legal and institutional systems sometimes know that party (liability clauses, remedy schedules). Technology-layer records frequently do not. This document supplies a minimal name for the role so that technology-layer records can carry it.¶

This document is orthogonal to the actor/principal work, not a correction of it: the Actor Profile describes the acting chain; dsub names the object of the action. Where the decision subject is the delegating principal (an agent acting on the user's own resources), dsub is absent. Naming who operated is a distinct companion gap, addressed in the separate operator-of-record draft [OPR].¶

2. Terminology

• Decision subject (dsub): the party an action is taken upon (sometimes called the affected party in accountability literature). The wire claim is dsub.¶

• Delegating principal (sub, [RFC7519] / [RFC8693]).¶

• Agent / actor (act, [RFC8693]).¶

• Resource / resource owner ([RFC9396] / AuthZEN).¶

• Decision-subject handle: a pseudonymous, purpose-bound reference to the decision subject (Section 6).¶

• Auditor: the reader of audit records (Section 4 of [I-D.kuehlewind-audit-architecture]); dsub is written for this reader.¶

Not the authorization subject. In OAuth (sub), AuthZEN [AuthZEN], and XACML, "subject" is the party making or authorized for a request: the acting side. The decision subject is the party a request is about. In the AuthZEN encoding (Section 9) the authorization subject is the agent and the decision subject appears only under context; a reader who maps "decision subject" onto the authorization subject has inverted the role. More broadly, the decision subject is an independent role, defined by the decision and its consequence rather than by credential contents, authorization, or data processing: it may coincide with the credential subject, the delegating principal, or the resource owner in the simple case (a party acting on itself), and remains a distinct semantic role in every case, though the claim is omitted on the wire whenever that party is already named by sub or the resource (Section 3).¶

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

3. When dsub applies (and when it MUST be omitted)

• dsub MUST be omitted when the decision subject is the delegating principal (sub) OR is already identifiable as the owner of the named resource. It MUST be included ONLY when a distinct third party is the subject of the action or decision.¶

Worked example (bystander). An agent posts a statement about Carol on Dave's timeline, on behalf of user U. sub = U; resource = Dave's timeline; owner = Dave; dsub = Carol, neither the resource nor its owner. Without dsub, Carol is unnameable on the record.¶

Worked example (eligibility). An agent screens applicant A for product P on behalf of lender L. sub = L; resource = P (or the application object); dsub = A. The decision is about A even when A never holds a token in the exchange.¶

In every case where the subject coincides with sub or the resource owner, dsub adds nothing and MUST be omitted, which is what keeps it from being the resource owner, re-labelled.¶

4. The claim is descriptive, not authorizing

A Policy Decision Point MUST ignore dsub when rendering allow/deny. The claim carries no authority and grants none; its sole function is audit legibility: naming the party a decision is about. dsub adds a role to the record without adding any path to privilege.¶

Readership is bound to the Auditor role. dsub is written to appear in audit records and, at most, in the decision-time context an Auditor later reads, never as a decision input. Deployments that key authorization on dsub are non-conformant with this document.¶

5. Container (which record carries it, and why not the access token)

The decision subject is determined per action. An OAuth access token is per-session, minted before target selection, and flows to a party that is not the subject: the wrong container on timing and privacy grounds. This document does not define dsub as an access-token claim.¶

Conformant containers, in preference order:¶

1. Audit records (PRIMARY). A SCITT signed statement / COSE Receipt ([RFC9943] / [RFC9942]), or a typed record under [I-D.kuehlewind-audit-architecture]. Integrity from the signature over the statement.¶

2. AuthZEN evaluation-context attribute (RECOMMENDED for live PEPs). Carried as context.decision_subject, the single AuthZEN context key defined for this claim (a JWT-encoded context uses the registered name dsub), recorded by the PDP shell without being passed to the decision engine.¶

3. Transaction token (OPTIONAL). [I-D.ietf-oauth-transaction-tokens] (per-action container).¶

6. Privacy considerations (design premise, not a footnote)

The decision subject is frequently a data subject not party to the exchange. Data minimization is the design premise:¶

1. The handle MUST be a pseudonymous, purpose-bound reference. It MUST NOT be a re-identifiable global identifier (no raw email, national ID number, account number, or stable cross-context subject identifier).¶

2. It SHOULD be a per-purpose pairwise pseudonym, so the same natural person is not linkable across purposes or deployments without authorized resolution.¶

3. It SHOULD be resolvable only by parties authorized to act on the subject's behalf. Resolution itself is out of scope (Section 8).¶

4. Addressability is not visibility. The role is defined to be invocable by the party against the record, not legible on the artefact. Where publishing the marker itself would cause harm, the record carries only the pseudonymous handle and routes any resolution through governed back-end attributes.¶

This document enables expression of a role often already present in unstructured form. It does not authorize any new collection of personal data.¶

7. Security considerations

Because the claim is non-authorizing (Section 4), a forged dsub cannot escalate privilege. Integrity derives from the signature over its container.¶

• An unsigned dsub MUST NOT be trusted to identify or address a party.¶

• The residual risk is mis-addressing, bounded by the handle's resolution authority (out of scope).¶

• Implementations that strip dsub (or context.decision_subject) from the evaluation input before the decision engine runs are conformant with Section 4 by construction.¶

8. Non-goals

This document does NOT define:¶

• remedy or adjudication;¶

• consent or its capture;¶

• any obligation owed to the decision subject;¶

• reachability / a resolution mechanism for the handle (deferred to a resolver draft);¶

• a requestable-denial / escalation / contestation mechanism (subject-side challenge / ARAP domain);¶

• a transport binding;¶

• mandatory presence of the claim;¶

• use as an authorization input;¶

• any new personal-data collection.¶

Naming is the precondition for later reachability work. It is not that work.¶

9. Claim syntax

dsub is a decision-subject reference, or an array of them (an action MAY concern several subjects). A reference is either:¶

• a string, a bare pseudonymous handle; or¶

• an object with:¶

  • handle (string, REQUIRED)¶

  • scheme (string, OPTIONAL): handle namespace / resolution scheme¶

  • purpose (string, OPTIONAL): purpose binding for pairwise isolation¶

No endpoint, URI, or contact field is defined here (deferred addressability work). Absent a distinct third-party subject (Section 3), dsub is omitted.¶

AuthZEN evaluation-context encoding (RECOMMENDED):¶

{
  "subject":  { "type": "Agent", "id": "agent-7f3a" },
  "action":   { "name": "Screen" },
  "resource": { "type": "Application", "id": "app-42" },
  "context":  {
    "decision_subject": {
      "handle": "ppid:9c1e...a4",
      "scheme": "pairwise-sha256",
      "purpose": "eligibility-audit"
    }
  }
}

JWT / SCITT-style signed statement encoding:¶

{
  "iss": "https://issuer.example",
  "iat": 1751000000,
  "sub": "lender-L",
  "act": { "sub": "agent-7f3a" },
  "dsub": {
    "handle": "ppid:9c1e...a4",
    "scheme": "pairwise-sha256",
    "purpose": "eligibility-audit"
  }
}

10. Relationship to existing mechanisms

• [RFC8693] (act / sub / may_act). Names the actor and the delegating principal. dsub adds an orthogonal role: the party acted upon. No semantic overlap.¶

• Actor Profile [I-D.mcguinness-oauth-actor-profile]. Classifies the actor's identity/type; dsub is the object of the action, not the actor. They compose.¶

• ARAP [ARAP] (OpenID AuthZEN Access Request and Approval Profile). Access Request Endpoint + approver routing; a denial stays a denial. dsub names a party and supplies no mechanism. A future subject-side challenge profile that makes notice/correction reachable by the subject would reference dsub.¶

• Transaction tokens [I-D.ietf-oauth-transaction-tokens]; SCITT ([RFC9943] / [RFC9942]). Conformant per-action / signed containers giving dsub its integrity.¶

• Attenuating agent tokens [I-D.niyikiza-oauth-attenuating-agent-tokens]. Omits sub; dsub remains independently expressible.¶

• Audit architecture [I-D.kuehlewind-audit-architecture]. Typed Auditor-facing records; subject legibility remains an open gap that dsub unblocks by naming the party.¶

• EMILIA Protocol (EP) + cross-org delegation mapping (WIMSE, Jul 2026). The EP drafts ([I-D.schrock-human-authorization-binding], [I-D.schrock-ep-action-evidence-graph], [I-D.schrock-ep-authority-introduction]), mapped in [I-D.rampalli-cross-org-delegation-mapping], bind evidence to the action digest and the named principal and hold that verified and accepted are separate results; neither implies sufficiency. dsub is orthogonal: it names the party a decision is about (a role EP does not model) and composes with, rather than competes with, that evidence-sufficiency work.¶

• CAEP reason_admin / reason_user (signed SETs, [RFC8417]). Precedent that an integrity-protected party-facing surface belongs in a signed record.¶

• Operator of record [OPR] (companion). Marks who operated; independent of, and composes with, dsub.¶

11. Considered alternatives

12. IANA considerations

This document requests registration of one entry in the JSON Web Token Claims registry established by [RFC7519]. The registration policy for that registry is Specification Required (Section 10.1 of [RFC7519]). Registration proceeds through a three-week review on the jwt-reg-review@ietf.org list.¶

13. References

Appendix A. Survey of existing mechanisms

Each mechanism below was checked against its current published version; none carries a role naming the party a decision is about, which is the gap dsub fills.¶

Author's Address