]> Independent Researcher

ping@anivar.net https://anivar.net

sec Web Authorization Protocol agent audit JWT 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. Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at .

Introduction and the agent-authorization profiles built on it model who acts (act) and who delegated (sub, ). 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 .

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, / ). Agent / actor (act, ). Resource / resource owner ( / AuthZEN). Decision-subject handle: a pseudonymous, purpose-bound reference to the decision subject (). Auditor: the reader of audit records (Section 4 of ); dsub is written for this reader. Not the authorization subject. In OAuth (sub), 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 () 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 (). 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 when, and only when, they appear in all capitals, as shown here.

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 is... Name it with... Already in the request? the object the action reads/writes resource ( / AuthZEN) yes the controller/owner of that object dereference from resource yes the human the decision is about, who may own nothing dsub no (the gap) 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.

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.

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: Audit records (PRIMARY). A SCITT signed statement / COSE Receipt ( / ), or a typed record under . Integrity from the signature over the statement. 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. Transaction token (OPTIONAL). (per-action container).

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: 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). It SHOULD be a per-purpose pairwise pseudonym, so the same natural person is not linkable across purposes or deployments without authorized resolution. It SHOULD be resolvable only by parties authorized to act on the subject's behalf. Resolution itself is out of scope (). 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.

Security considerations Because the claim is non-authorizing (), 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 by construction.

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.

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 (), dsub is omitted. AuthZEN evaluation-context encoding (RECOMMENDED):

JWT / SCITT-style signed statement encoding:

Relationship to existing mechanisms (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 . Classifies the actor's identity/type; dsub is the object of the action, not the actor. They compose. 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 ; SCITT ( / ). Conformant per-action / signed containers giving dsub its integrity. Attenuating agent tokens . Omits sub; dsub remains independently expressible. 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 (, , ), mapped in , 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, ). Precedent that an integrity-protected party-facing surface belongs in a signed record. Operator of record (companion). Marks who operated; independent of, and composes with, dsub.

Considered alternatives Alternative Why it does not cover dsub authorization_details (RAR) An authorization construct; contradicts ; targets the resource, not a bystander subject. A nested / second sub sub is the delegating principal ( / ); overloading it reintroduces authorization semantics. resource indicator () / AuthZEN resource Names the object acted on, not the human the decision is about. A private / vendor claim No cross-boundary interop; the reason to register one descriptive claim. W3C VC credentialSubject () Scopes what a credential asserts and presents; says nothing about a 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 Art. 4) A legal role keyed to personal-data 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.

IANA considerations This document requests registration of one entry in the JSON Web Token Claims registry established by . The registration policy for that registry is Specification Required (Section 10.1 of ). Registration proceeds through a three-week review on the jwt-reg-review@ietf.org list. Claim Name Claim Description Change Controller Specification Document(s) dsub Decision Subject: the party an action or decision is taken upon; descriptive, non-authorizing. Anivar A. Aravind (ping@anivar.net) This document

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Independent Researcher World Wide Web Consortium OpenID Foundation OpenID Foundation This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additonal logging for transparency. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Independent OAuth deployments increasingly involve agents and workloads acting on behalf of human users across organizational boundaries. Existing specifications provide relevant building blocks (notably the act claim from RFC 8693 Token Exchange) but do not define a consistent profile for representing delegated actor relationships across JWT assertion grants (RFC 7523), JWT access tokens (RFC 9068), and Transaction Tokens, nor for classifying actor entity types or signaling support between authorization servers and resource servers. The result is inconsistent actor representation and actor- representation interoperability gaps that force deployments to rely on proprietary conventions. This document defines the OAuth Actor Profile for Delegation. It specifies a common act claim structure extended with sub_profile for entity-type classification, processing rules for authorization servers and resource servers across the three token families and their Token Exchange inputs, and OAuth discovery metadata parameters for advertising actor-profile support. The profile applies uniformly across token types and integrates with existing sender-constraint mechanisms (DPoP, mTLS). It does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject; those decisions remain deployment-specific. Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. EMILIA Protocol, Inc. A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" - an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference - and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification. EMILIA Protocol, Inc. The standards landscape now produces many signed artifacts about an AI agent's action: workload identity credentials, delegation and grant tokens, call-chain transaction tokens, runtime attestation results, pre-execution policy permits, named-human authorization receipts, post-execution action records, and transparency-log inclusion receipts. No specification defines how a relying party decides whether a collection of such artifacts is SUFFICIENT to rely on for a given purpose: releasing a payment, honoring a trade, satisfying an auditor, or paying an insurance claim. This document defines three things that together fill that layer: the Action Evidence Graph (EP-AEG), a portable, content-addressed graph of references to signed artifacts about one action, whose identity is independent of how much of it is disclosed; Evidence Policy Replay, a deterministic, offline evaluation of a graph against a RELYING-PARTY- supplied evidence policy, yielding one of five closed verdicts (admissible, missing_evidence, stale, conflicted, unverifiable) with a replay digest that lets any third party recompute the decision; and the Reliance Result (EP-RELIANCE-RESULT), the verdict as a signed artifact, making the reliance decision itself auditable evidence. Six policy packs profile the mechanism for concrete irreversible action classes. A verdict is evidence of sufficiency under a stated policy; it is not adjudication, and the graph never carries its own sufficiency bar. EMILIA Protocol, Inc. Signature verification answers whether a key produced an artifact. It does not answer why a relying party accepts that key, or whether the key holder had authority for the action. This document specifies two composable artifacts. An Authority Document introduces and rotates an organization's evidence-issuing keys through a signed, hash-chained sequence. A Scoped Authority Proof records the authority held by a subject at a registry snapshot, including role, action scope, material limits, policy binding, validity, and revocation status. A relying party evaluates both artifacts under its own pinned trust inputs and policy. The design does not make a self-presented key authoritative, does not turn log inclusion or domain control into automatic trust, and does not equate a valid signature with permission to act. Glyphzero, Inc. This document records a comparative mapping of two evidence layers for cross-organization AI agent delegation: a per-hop delegation chain (PEDIGREE) and a named-human authorization root (the EMILIA Protocol binding and evidence-graph drafts), evaluated against the nine requirements of draft-reece-wimse-cross-org-delegation under a no-shared-operator assumption. It also records a verifier-facing composition model in which key possession, delegated authority, and pre-execution human authorization are diagnostically separate inputs with independent failure behavior, joined by action digest. The mapping was developed on the WIMSE mailing list; corrections continue there. This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

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. Spec Rev / date Role it provides RFC 8693 Sec. 4.1 / 1.1 Pub. Jan 2020 act=actor, sub=principal-acted-for draft-mcguinness-oauth-actor-profile -00, 30 Apr 2026 act / actor classification ARAP OpenID AuthZEN WG Draft 1, 17 Jul 2026 Access Request Endpoint draft-kuehlewind-audit-architecture -00, 18 May 2026 typed records; subject legibility OPEN draft-hardt-oauth-aauth-protocol -09, 4 Jul 2026 person-accountable framing draft-ietf-oauth-transaction-tokens -09, 6 Jul 2026, WGLC per-action container draft-niyikiza-oauth-attenuating-agent-tokens -01 omits sub SCITT RFC 9943 + RFC 9942, Jun 2026 audit container CAEP / signed SET reasons RFC 8417 family integrity-protected party surface precedent draft-rampalli-cross-org-delegation-mapping (+ EMILIA/EP draft-schrock-*) -05, 6 Jul 2026 (WIMSE) evidence-sufficiency: verified != accepted, neither implies sufficiency; no decision-subject role