Decision-Subject Representation for Agent Authorization
draft-aravind-oauth-decision-subject-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Anivar A Aravind | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-aravind-oauth-decision-subject-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
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,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8693>.
13.2. Informative References
[ARAP] OpenID Foundation, "OpenID AuthZEN Access Request and
Approval Profile 1.0", 17 July 2026,
<https://openid.net/specs/authzen-access-request-approval-
profile-1_0.html>.
[AuthZEN] OpenID Foundation, "Authorization API 1.0", 11 January
2026, <https://openid.net/specs/authorization-api-
1_0-final.html>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-09>.
[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,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
audit-architecture-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mcguinness-
oauth-actor-profile-00>.
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, <https://datatracker.ietf.org/doc/html/draft-
niyikiza-oauth-attenuating-agent-tokens-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-rampalli-
cross-org-delegation-mapping-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-schrock-ep-
action-evidence-graph-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-schrock-ep-
authority-introduction-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-
schrock-human-authorization-binding-00>.
[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, <https://datatracker.ietf.org/doc/html/
draft-aravind-oauth-operator-of-record-00>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/rfc/rfc8417>.
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, <https://www.rfc-editor.org/rfc/rfc8707>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
[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,
<https://www.rfc-editor.org/rfc/rfc9942>.
[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,
<https://www.rfc-editor.org/rfc/rfc9943>.
[VCDM20] World Wide Web Consortium, "Verifiable Credentials Data
Model v2.0", 15 May 2025,
<https://www.w3.org/TR/vc-data-model-2.0/>.
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]