Web Authorization Protocol A. A. Aravind Internet-Draft Independent Researcher Intended status: Informational 19 July 2026 Expires: 20 January 2027 Decision-Subject Representation for Agent Authorization draft-aravind-oauth-decision-subject-00 Abstract This document defines dsub, an OPTIONAL, descriptive claim naming the *decision subject*, the party an automated agent's action is taken _upon_, as distinct from the acting agent (act) and the delegating principal (sub). Its purpose is *audit legibility*: letting a record name the party a decision concerns, which is the precondition for that record ever being made legible to them. The claim is privacy- minimizing by construction and is NOT an input to the authorization decision; a Policy Decision Point MUST ignore it. This document defines representation only. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-aravind-oauth-decision- subject/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. 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." Aravind Expires 20 January 2027 [Page 1] Internet-Draft decision-subject July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. When dsub applies (and when it MUST be omitted) . . . . . . . 4 4. The claim is descriptive, not authorizing . . . . . . . . . . 5 5. Container (which record carries it, and why not the access token) . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Privacy considerations (design premise, not a footnote) . . . 5 7. Security considerations . . . . . . . . . . . . . . . . . . . 6 8. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Claim syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Relationship to existing mechanisms . . . . . . . . . . . . . 8 11. Considered alternatives . . . . . . . . . . . . . . . . . . . 9 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Survey of existing mechanisms . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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. Aravind Expires 20 January 2027 [Page 2] Internet-Draft decision-subject July 2026 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 Aravind Expires 20 January 2027 [Page 3] Internet-Draft decision-subject July 2026 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. +==============================+=====================+==============+ | The party you mean | Name it with... | Already in | | is... | | the request? | +==============================+=====================+==============+ | the object the | resource ([RFC9396] | yes | | action reads/writes | / AuthZEN) | | +------------------------------+---------------------+--------------+ | the controller/owner | dereference from | yes | | of that object | resource | | +------------------------------+---------------------+--------------+ | the human the | *dsub* | *no (the | | decision is *about*, | | gap)* | | who may own nothing | | | +------------------------------+---------------------+--------------+ Table 1 *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. Aravind Expires 20 January 2027 [Page 4] Internet-Draft decision-subject July 2026 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: Aravind Expires 20 January 2027 [Page 5] Internet-Draft decision-subject July 2026 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; Aravind Expires 20 January 2027 [Page 6] Internet-Draft decision-subject July 2026 * *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):* Aravind Expires 20 January 2027 [Page 7] Internet-Draft decision-subject July 2026 { "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. Aravind Expires 20 January 2027 [Page 8] Internet-Draft decision-subject July 2026 * *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 +=======================+=====================================+ | Alternative | Why it does not cover dsub | +=======================+=====================================+ | [RFC9396] | An _authorization_ construct; | | authorization_details | contradicts Section 4; targets the | | (RAR) | resource, not a bystander subject. | +-----------------------+-------------------------------------+ | A nested / second sub | sub is the delegating principal | | | ([RFC7519] / [RFC8693]); | | | overloading it reintroduces | | | authorization semantics. | +-----------------------+-------------------------------------+ | resource indicator | Names the object acted on, not the | | ([RFC8707]) / AuthZEN | human the decision is about. | | resource | | +-----------------------+-------------------------------------+ | A private / vendor | No cross-boundary interop; the | | claim | reason to register one descriptive | | | claim. | +-----------------------+-------------------------------------+ Aravind Expires 20 January 2027 [Page 9] Internet-Draft decision-subject July 2026 | W3C VC | Scopes what a credential _asserts_ | | credentialSubject | and presents; says nothing about a | | ([VCDM20]) | decision made using it, or made | | | without any credential. May be the | | | same party as dsub, or not: dsub | | | names the party a decision _lands | | | on_, who may present nothing. | +-----------------------+-------------------------------------+ | "Data subject" (GDPR | A legal role keyed to personal-data | | Art. 4) | _processing_. dsub is a protocol | | | role keyed to a _decision and its | | | consequence_, not data processing; | | | putting the legal term on the wire | | | would import a regulatory model | | | this claim does not assert. | +-----------------------+-------------------------------------+ Table 2 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. +=======+======================+===================+===============+ | Claim | Claim Description | Change Controller | Specification | | Name | | | Document(s) | +=======+======================+===================+===============+ | dsub | Decision Subject: | Anivar A. | This document | | | the party an action | Aravind | | | | or decision is taken | (ping@anivar.net) | | | | upon; descriptive, | | | | | non-authorizing. | | | +-------+----------------------+-------------------+---------------+ Table 3 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Aravind Expires 20 January 2027 [Page 10] Internet-Draft decision-subject July 2026 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . 13.2. Informative References [ARAP] OpenID Foundation, "OpenID AuthZEN Access Request and Approval Profile 1.0", 17 July 2026, . [AuthZEN] OpenID Foundation, "Authorization API 1.0", 11 January 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-09, 6 July 2026, . [I-D.kuehlewind-audit-architecture] Kühlewind, M. and H. Birkholz, "An Architecture for Auditing AI Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit- architecture-00, 18 May 2026, . [I-D.mcguinness-oauth-actor-profile] McGuinness, K., "OAuth Actor Profile for Delegation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor- profile-00, 30 April 2026, . Aravind Expires 20 January 2027 [Page 11] Internet-Draft decision-subject July 2026 [I-D.niyikiza-oauth-attenuating-agent-tokens] Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, . [I-D.rampalli-cross-org-delegation-mapping] Karthik, R., "A Layered Requirements Mapping for Cross- Organization Agent Delegation", Work in Progress, Internet-Draft, draft-rampalli-cross-org-delegation- mapping-05, 6 July 2026, . [I-D.schrock-ep-action-evidence-graph] Schrock, I., "Action Evidence Graphs and Evidence Policy Replay for High-Risk Agent Actions (EP-AEG)", Work in Progress, Internet-Draft, draft-schrock-ep-action- evidence-graph-00, 3 July 2026, . [I-D.schrock-ep-authority-introduction] Schrock, I., "Authority Documents and Scoped Authority for Agent-Action Evidence", Work in Progress, Internet-Draft, draft-schrock-ep-authority-introduction-01, 19 July 2026, . [I-D.schrock-human-authorization-binding] Schrock, I., "Binding Named-Human Authorization Evidence into Agent-Action Records", Work in Progress, Internet- Draft, draft-schrock-human-authorization-binding-00, 3 July 2026, . [OPR] Aravind, A. A., "Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions", Work in Progress, Internet-Draft, draft-aravind-oauth-operator-of- record-00, 2026, . [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, . Aravind Expires 20 January 2027 [Page 12] Internet-Draft decision-subject July 2026 [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [VCDM20] World Wide Web Consortium, "Verifiable Credentials Data Model v2.0", 15 May 2025, . 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. Aravind Expires 20 January 2027 [Page 13] Internet-Draft decision-subject July 2026 +=======================+=============+=======================+ | Spec | Rev / date | Role it provides | +=======================+=============+=======================+ | RFC 8693 Sec. 4.1 / | Pub. Jan | act=actor, | | 1.1 | 2020 | sub=principal-acted- | | | | for | +-----------------------+-------------+-----------------------+ | draft-mcguinness- | -00, 30 Apr | act / actor | | oauth-actor-profile | 2026 | classification | +-----------------------+-------------+-----------------------+ | ARAP | OpenID | Access Request | | | AuthZEN WG | Endpoint | | | Draft 1, 17 | | | | Jul 2026 | | +-----------------------+-------------+-----------------------+ | draft-kuehlewind- | -00, 18 May | typed records; | | audit-architecture | 2026 | subject legibility | | | | OPEN | +-----------------------+-------------+-----------------------+ | draft-hardt-oauth- | -09, 4 Jul | person-accountable | | aauth-protocol | 2026 | framing | +-----------------------+-------------+-----------------------+ | draft-ietf-oauth- | -09, 6 Jul | per-action container | | transaction-tokens | 2026, WGLC | | +-----------------------+-------------+-----------------------+ | draft-niyikiza-oauth- | -01 | omits sub | | attenuating-agent- | | | | tokens | | | +-----------------------+-------------+-----------------------+ | SCITT | RFC 9943 + | audit container | | | RFC 9942, | | | | Jun 2026 | | +-----------------------+-------------+-----------------------+ | CAEP / signed SET | RFC 8417 | integrity-protected | | reasons | family | party surface | | | | precedent | +-----------------------+-------------+-----------------------+ | draft-rampalli-cross- | -05, 6 Jul | evidence-sufficiency: | | org-delegation- | 2026 | verified != accepted, | | mapping (+ EMILIA/EP | (WIMSE) | neither implies | | draft-schrock-*) | | sufficiency; no | | | | decision-subject role | +-----------------------+-------------+-----------------------+ Table 4 Author's Address Aravind Expires 20 January 2027 [Page 14] Internet-Draft decision-subject July 2026 Anivar A. Aravind Independent Researcher Email: ping@anivar.net URI: https://anivar.net Aravind Expires 20 January 2027 [Page 15]