]> Independent Researcher

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

Security Web Authorization Protocol agent audit JWT verifiable credentials This document requests registration of opr, an OPTIONAL, descriptive JWT claim that marks the operator of record, that is, whether a human or an agent operated a credential presentation or drove a decision. Its purpose is record integrity. Under agent operation a wallet key-binding proof is cryptographically indistinguishable from a human-operated one, and no presentation protocol marks the difference; opr records the distinction. A Policy Decision Point MUST ignore opr for the allow/deny decision; interpretation and any resulting authorization behavior are deployment-local and out of scope. This document defines representation only. It defines no remedy, adjudication, obligation, or authorization mandate. 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 A key-binding proof in a verifiable-credential presentation, the SD-JWT key-binding JWT , or the ISO mdoc deviceAuth (deviceSignature COSE_Sign1 or deviceMac COSE_Mac0), proves possession / control of the holder-bound key at presentation time. It is typically produced after a wallet-local unlock (PIN / biometric), and relying parties in practice treat it as evidence that a human saw and approved the specific disclosure, though no presentation protocol requires either. On the payments rail, an analogous human-awareness requirement is SCA "dynamic linking" (PSD2 RTS Article 5 of Commission Delegated Regulation (EU) 2018/389 ), under which the payer is made aware of amount and payee and the authentication code is specific to them. That payments rule is cited here only as an analogy for the human-inference pattern; it does not regulate wallet-presentation protocols. That inference is what agent operation breaks. An agent driving the wallet performs the same unlock and produces a cryptographically identical proof; the signed presentation therefore attests key control exactly as before, while the human comprehension-and-approval the relying party infers from it no longer occurred. No field in , SD-JWT-VC , or ISO 18013-5/-7 marks who operated (); the apparatus certifies where the key lives and nothing about who exercised it. opr supplies the missing marker so the record can state, honestly, that an agent operated. Marking the operator is a role decomposition with method-level precedent. Published wallet guidance decomposes the collapsed Holder role of into user and wallet application when the abstraction hid a governance-relevant distinction; business-wallet tracks already separate subject (legal person) from operator (authorised employee). This document performs the same decomposition for the natural-person, agent-operated case. The companion names the other missing party, whom a decision is about. The two roles compose and neither depends on the other.

Terminology Operator of record (opr): who actually operated a credential presentation or drove a decision at record time: a human, or a named agent. Origination: the fact of being human- versus agent-operated. Key-binding proof: a signed proof of control of the holder-bound key (SD-JWT KB-JWT; mdoc deviceAuth). It attests key control, not human presence or approval. Agent / actor (act, ). Auditor (, Section 4). 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 to mark opr SHOULD be marked whenever an agent operates a credential, or drives a decision, that a verifier or auditor could otherwise attribute to a human. Where a human operates directly, opr MAY be {"class":"human"} or omitted. Absence carries no assurance of human operation (). A deployment that relies on human operation for risk or liability purposes cannot safely infer it from a missing marker; a present, signed opr is the only origination assurance this document defines.

The claim is descriptive, not authorizing opr RECORDS who operated. A Policy Decision Point MUST ignore opr when rendering an allow/deny decision; it carries no authority and grants none. Interpretation of opr, and any resulting authorization behavior, are deployment-local and out of scope of this document. opr adds an origination fact to the record; it does not prescribe what any verifier does with that fact. Registration of this claim registers a name and semantics, not verifier conduct.

Container (which record carries it, and why not the access token) opr describes a per-action event, so it belongs in a per-action or post-hoc signed record, never in a per-session access token. Conformant containers: Audit records, PRIMARY. A SCITT signed statement / COSE Receipt ( / ), or an Action / Authorization-Transition record under . Integrity from the signature over the statement. Per-action assertions. A transaction token (), or, the exact place the human-inference breaks, alongside an SD-JWT-VC key-binding JWT. AuthZEN evaluation context. As a context attribute a PDP records without acting on (). The JWT Claims registration () governs JWT-encoded records. A parallel COSE registration for the ISO mdoc / CBOR path is noted as related work, out of scope here.

Privacy considerations opr names the operator, not a third party. A bare {"class":"agent"} marker discloses nothing about any natural person. Where opr carries an agent identifier it is not third-party personal data and composes with act (). Where it carries a human operator's identifier, that is the same party already authenticated in the ceremony, so there is no new third-party disclosure. opr therefore does not carry the third-party data-minimization burden that the companion decision-subject claim does.

Security considerations The threat is origination spoofing, an agent-operated action recorded (or left unmarked so as to read) as human-operated. Therefore: opr MUST be integrity-protected within the signed record whose origination it describes. An unsigned or separately-supplied opr MUST NOT be trusted. Absence is not human. Human operation cannot safely be inferred from a missing marker: a policy that depends on a marker cannot depend on the marker being supplied by a well-behaved party, the same anti-downgrade discipline as key-binding itself. Fail-safe use (non-normative guidance). Because interpretation is deployment-local (), the safe discipline is that consulting opr never enlarges authority: a deployment that consults it should reach a decision no more permissive than the one it would reach ignoring it. This keeps a false or hostile opr fail-safe.

Non-goals This document does NOT define or mandate: any authorization behavior (deployment-local, ); remedy, adjudication, or obligation; a reachability / resolution mechanism; a requestable-denial or escalation mechanism; a transport binding; mandatory presence of the claim (except the conditional "require opr" a human-operation-reliant deployment adopts for itself, ).

Claim syntax opr is an operator-of-record object: Field Type Required Description class string REQUIRED "human" or "agent"; other values reserved id string OPTIONAL operator identifier. Where an act () claim is also present, opr.id SHOULD equal act.sub A bare string "human" / "agent" is permitted as shorthand for {"class": ...}. Scope note (non-normative). Where act is present, opr largely overlaps it except in carrying the human/agent class. opr's uniquely non-redundant use is the wallet-presentation case, where there is no token-exchange act and the presentation is cryptographically identical to a human one. Implementers who register only for that case MAY treat this document as scoped to presentation-time origination. Decision-record use remains conformant. Normative example (agent-operated eligibility decision, SCITT-style signed statement):

Presentation-time example (no act; the unique non-redundant case):

Relationship to existing mechanisms RFC 8693 (act). act () is the delegated actor in a token chain. opr marks origination in a presentation / decision record, including the wallet case where there is no act and the human/agent distinction is otherwise unrecoverable. Where both appear, opr.id SHOULD equal act.sub. OpenID4VP; SD-JWT-VC (RFC 9901 KB-JWT + draft-ietf-oauth-sd-jwt-vc); ISO 18013-5/-7 mdoc. Each of , SD-JWT-VC ( KB-JWT plus ), and mdoc carries a holder-key-binding proof and no origination field (). opr is the missing marker that lets the record distinguish agent from human operation. Decision-subject (companion), . Names the party a decision is about; independent of, and composes with, opr. SCITT ( / ); transaction tokens. Signed containers for opr. SCA dynamic linking (PSD2 RTS Art. 5, Reg (EU) 2018/389 ). Cited as an analogy only, not a regulatory overlap: SCA requires that the payer is made aware of amount and payee, and that the authentication code is specific to them (Art. 5(1)(a)-(c)). The wallet key-binding proof is the credential-layer analogue whose human inference agent operation breaks. SCA governs payment service providers, not wallet-presentation protocols. Actor Profile (). Classifies the actor's type; opr marks operation modality, not actor type. They compose.

Considered alternatives Alternative Why it does not cover opr RFC 8693 act Token-chain delegation; absent in a pure wallet presentation; carries no human/agent class. Mark origination in the app / UI layer Unsigned, and in a layer that wallet standards place out of scope; does not survive the integrity requirement. opr lives in the signed record. amr / acr (authentication method / context) Describe how the human authenticated; do not distinguish a human operator from an agent driving the same ceremony. A private / vendor claim No cross-boundary interop; the reason to register one descriptive claim.

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 (see , Section 10.1). The Designated Experts review requests on the jwt-reg-review@ietf.org list over a three-week period. Claim Name Claim Description Change Controller Specification Document(s) opr Operator of Record: the class of operator, human or agent, at record time. Descriptive, non-authorizing. Anivar A. Aravind (ping@anivar.net) This document Containers for opr are described in ; it is not an access-token claim. A parallel COSE registration for the ISO mdoc path is noted as related work and is out of scope here.

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. 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. 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. Independent Researcher World Wide Web Consortium OpenID Foundation International Organization for Standardization European Commission European Commission This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. 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.

Survey of presentation and payment mechanisms Each mechanism below was checked against its current published version. No credential-presentation protocol marks who operated; the payments-rail rule is included only as the human-inference analogy. Spec Rev / date Field it provides Finding OpenID4VP 1.0 final (+1.1 draft) acr / amr; user_verification / user_presence none of these marks operator modality; SIOPv2 authenticates identity, not operator class SD-JWT / KB-JWT RFC 9901 (Nov 2025) KB-JWT = iat/aud/nonce/sd_hash; proves key control no operator/origination field SD-JWT-VC draft-ietf-oauth-sd-jwt-vc-17 (6 Jul 2026) cnf = key binding only no origination field ISO 18013-5/-7 mdoc current deviceAuth proves device-key control deviceAuth proves key possession only; key possession is not human presence W3C VCDM 2.0 Recommendation 15 May 2025 credential data model no operator field EUDI ARF trust model v2.5-2.9 X.509 + national Trusted Lists as trust anchors defines wallet trust anchors; no operator / origination field SCA dynamic linking PSD2 RTS Art. 5, Reg (EU) 2018/389 payer aware of amount+payee; auth code specific to amount+payee; accepted code matches analogy only (); Art. 5(1)(a)-(c) requires payer awareness of amount and payee