Web Authorization Protocol A. A. Aravind Internet-Draft Independent Researcher Intended status: Informational 19 July 2026 Expires: 20 January 2027 Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions draft-aravind-oauth-operator-of-record-00 Abstract 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. 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-operator-of- record/. 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/. Aravind Expires 20 January 2027 [Page 1] Internet-Draft operator-of-record July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. When to mark . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The claim is descriptive, not authorizing . . . . . . . . . . 4 5. Container (which record carries it, and why not the access token) . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Privacy considerations . . . . . . . . . . . . . . . . . . . 5 7. Security considerations . . . . . . . . . . . . . . . . . . . 5 8. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Claim syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Relationship to existing mechanisms . . . . . . . . . . . . . 7 11. Considered alternatives . . . . . . . . . . . . . . . . . . . 8 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Survey of presentation and payment mechanisms . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Aravind Expires 20 January 2027 [Page 2] Internet-Draft operator-of-record July 2026 1. Introduction A key-binding proof in a verifiable-credential presentation, the SD- JWT key-binding JWT [RFC9901], 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 [EU2018389]), 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 [OpenID4VP], SD-JWT-VC [I-D.ietf-oauth-sd-jwt-vc], or ISO 18013-5/-7 [ISO18013] marks who operated (Appendix A); 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 [VCDM20] 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 [DECISION-SUBJECT] names the other missing party, whom a decision is _about_. The two roles compose and neither depends on the other. 2. 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. Aravind Expires 20 January 2027 [Page 3] Internet-Draft operator-of-record July 2026 * *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, [RFC8693]). * *Auditor* ([I-D.kuehlewind-audit-architecture], 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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* (Section 7). 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. 4. 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. 5. 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: Aravind Expires 20 January 2027 [Page 4] Internet-Draft operator-of-record July 2026 1. *Audit records, PRIMARY.* A SCITT signed statement / COSE Receipt ([RFC9943] / [RFC9942]), or an Action / Authorization-Transition record under [I-D.kuehlewind-audit-architecture]. Integrity from the signature over the statement. 2. *Per-action assertions.* A transaction token ([I-D.ietf-oauth-transaction-tokens]), or, the exact place the human-inference breaks, alongside an SD-JWT-VC key-binding JWT. 3. *AuthZEN evaluation context.* As a context attribute a PDP records without acting on (Section 4). The JWT Claims registration (Section 12) governs JWT-encoded records. A parallel COSE registration for the ISO mdoc / CBOR path is noted as related work, out of scope here. 6. 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 ([RFC8693]). * 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. 7. Security considerations The threat is *origination spoofing*, an agent-operated action recorded (or left unmarked so as to read) as human-operated. Therefore: 1. opr MUST be integrity-protected within the signed record whose origination it describes. An unsigned or separately-supplied opr MUST NOT be trusted. 2. *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. Aravind Expires 20 January 2027 [Page 5] Internet-Draft operator-of-record July 2026 3. *Fail-safe use (non-normative guidance).* Because interpretation is deployment-local (Section 4), 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. 8. Non-goals This document does NOT define or mandate: * any authorization behavior (deployment-local, Section 4); * 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, Section 7). 9. 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 | | | | | ([RFC8693]) claim is also present, | | | | | opr.id SHOULD equal act.sub | +-------+--------+----------+------------------------------------+ Table 1 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 Aravind Expires 20 January 2027 [Page 6] Internet-Draft operator-of-record July 2026 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): { "iss": "https://issuer.example", "iat": 1751000000, "sub": "lender-L", "act": { "sub": "agent-7f3a" }, "opr": { "class": "agent", "id": "agent-7f3a" } } *Presentation-time example* (no act; the unique non-redundant case): { "iss": "https://wallet.example", "iat": 1751000000, "sub": "holder-device-9", "opr": { "class": "agent", "id": "agent-7f3a" } } 10. Relationship to existing mechanisms * *RFC 8693 (act).* act ([RFC8693]) 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 [OpenID4VP], SD-JWT-VC ([RFC9901] KB-JWT plus [I-D.ietf-oauth-sd-jwt-vc]), and [ISO18013] mdoc carries a holder-key-binding proof and *no origination field* (Appendix A). opr is the missing marker that lets the record distinguish agent from human operation. * *Decision-subject (companion), [DECISION-SUBJECT].* Names the party a decision is _about_; independent of, and composes with, opr. * *SCITT ([RFC9943] / [RFC9942]); transaction tokens.* Signed containers for opr. Aravind Expires 20 January 2027 [Page 7] Internet-Draft operator-of-record July 2026 * *SCA dynamic linking (PSD2 RTS Art. 5, Reg (EU) 2018/389 [EU2018389]).* 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 ([I-D.mcguinness-oauth-actor-profile]).* Classifies the actor's type; opr marks operation modality, not actor type. They compose. 11. 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 | Unsigned, and in a layer that wallet | | in the app / UI | standards place out of scope; does not | | layer* | survive the Section 7 integrity requirement. | | | opr lives in the signed record. | +-------------------+----------------------------------------------+ | *amr / acr | Describe how the _human_ authenticated; do | | (authentication | not distinguish a human operator from an | | method / | agent driving the same ceremony. | | context)* | | +-------------------+----------------------------------------------+ | A private / | No cross-boundary interop; the reason to | | vendor claim | register one descriptive claim. | +-------------------+----------------------------------------------+ 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 (see [RFC7519], Section 10.1). The Designated Experts review requests on the jwt- reg-review@ietf.org list over a three-week period. Aravind Expires 20 January 2027 [Page 8] Internet-Draft operator-of-record July 2026 +=======+=====================+===================+===============+ | Claim | Claim Description | Change Controller | Specification | | Name | | | Document(s) | +=======+=====================+===================+===============+ | opr | Operator of Record: | Anivar A. | This document | | | the class of | Aravind | | | | operator, human or | (ping@anivar.net) | | | | agent, at record | | | | | time. Descriptive, | | | | | non-authorizing. | | | +-------+---------------------+-------------------+---------------+ Table 3 Containers for opr are described in Section 5; 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. 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, . [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 [DECISION-SUBJECT] Aravind, A. A., "Decision-Subject Representation for Agent Authorization", Work in Progress, Internet-Draft, draft- aravind-oauth-decision-subject-00, 2026, . Aravind Expires 20 January 2027 [Page 9] Internet-Draft operator-of-record July 2026 [EU2018389] European Commission, "Commission Delegated Regulation (EU) 2018/389 on regulatory technical standards for strong customer authentication", 2018, . [EUDI-ARF] European Commission, "European Digital Identity Wallet Architecture and Reference Framework", 2026, . [I-D.ietf-oauth-sd-jwt-vc] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-17, 6 July 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, . [ISO18013] International Organization for Standardization, "ISO/IEC 18013-5:2021, Mobile driving licence (mDL) application", 2021, . [OpenID4VP] OpenID Foundation, "OpenID for Verifiable Presentations 1.0", 2026, . Aravind Expires 20 January 2027 [Page 10] Internet-Draft operator-of-record July 2026 [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [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 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 | acr / amr; | none of these | | | (+1.1 draft) | user_verification | marks operator | | | | / user_presence | modality; | | | | | SIOPv2 | | | | | authenticates | | | | | identity, not | | | | | operator class | +------------+----------------+-------------------+----------------+ | SD-JWT / | RFC 9901 (Nov | KB-JWT = | no operator/ | | KB-JWT | 2025) | iat/aud/nonce/ | origination | | | | sd_hash; proves | field | | | | key control | | +------------+----------------+-------------------+----------------+ | SD-JWT-VC | draft-ietf- | cnf = key binding | no origination | | | oauth-sd-jwt- | only | field | | | vc-17 (6 Jul | | | | | 2026) | | | +------------+----------------+-------------------+----------------+ | ISO | current | deviceAuth proves | deviceAuth | Aravind Expires 20 January 2027 [Page 11] Internet-Draft operator-of-record July 2026 | 18013-5/-7 | | device-key | proves key | | mdoc | | control | possession | | | | | only; key | | | | | possession is | | | | | not human | | | | | presence | +------------+----------------+-------------------+----------------+ | W3C VCDM | Recommendation | credential data | no operator | | 2.0 | *15 May 2025* | model | field | +------------+----------------+-------------------+----------------+ | EUDI ARF | v2.5-2.9 | X.509 + national | defines wallet | | trust | | Trusted Lists as | trust anchors; | | model | | trust anchors | no operator / | | [EUDI-ARF] | | | origination | | | | | field | +------------+----------------+-------------------+----------------+ | SCA | PSD2 RTS *Art. | payer aware of | analogy only | | dynamic | 5*, Reg (EU) | amount+payee; | (Section 1); | | linking | 2018/389 | auth code | Art. | | | | specific to | 5(1)(a)-(c) | | | | amount+payee; | requires payer | | | | accepted code | awareness of | | | | matches | amount and | | | | | payee | +------------+----------------+-------------------+----------------+ Table 4 Author's Address Anivar A. Aravind Independent Researcher Email: ping@anivar.net URI: https://anivar.net Aravind Expires 20 January 2027 [Page 12]