Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions

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."¶

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

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.¶

• 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:¶

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.¶

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:¶

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):¶

{
  "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.¶

• 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

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.¶

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

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.¶

Author's Address