Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions
draft-aravind-oauth-operator-of-record-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-operator-of-record-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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
[DECISION-SUBJECT]
Aravind, A. A., "Decision-Subject Representation for Agent
Authorization", Work in Progress, Internet-Draft, draft-
aravind-oauth-decision-subject-00, 2026,
<https://datatracker.ietf.org/doc/draft-aravind-oauth-
decision-subject/>.
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,
<https://eur-lex.europa.eu/eli/reg_del/2018/389/oj>.
[EUDI-ARF] European Commission, "European Digital Identity Wallet
Architecture and Reference Framework", 2026,
<https://github.com/eu-digital-identity-wallet/eudi-doc-
architecture-and-reference-framework>.
[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, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-sd-jwt-vc-17>.
[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>.
[ISO18013] International Organization for Standardization, "ISO/IEC
18013-5:2021, Mobile driving licence (mDL) application",
2021, <https://www.iso.org/standard/69084.html>.
[OpenID4VP]
OpenID Foundation, "OpenID for Verifiable Presentations
1.0", 2026, <https://openid.net/specs/openid-4-verifiable-
presentations-1_0.html>.
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,
<https://www.rfc-editor.org/rfc/rfc9901>.
[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 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]