Anivar,
Both claims name real parties, and the guardian-operated wallet case is the
cleanest demonstration I've seen that operation-mode is invisible in current
presentation formats.
On whether the model should name them: yes, and I'd argue your placement
instinct answers your own question. R4 in my requirements draft asks that
authorization evidence be bound per action — operation, parameters, target,
acting-for principal — precisely because the per-session token exists before
target selection, as you note. A party that only becomes determinate at target
selection (the decision subject) can only live in an artifact created at or
after that moment: the per-action assertion, and the decision record (R8). So:
per-action artifact and audit record, not the access token — and being
descriptive-only with PDP-MUST-ignore semantics is the right discipline, since
naming an affected party and authorizing on their behalf are different
operations that shouldn't share a field.
Two pointers on venue: the human-authorization binding draft
(draft-schrock-human-authorization-binding) enumerates the host record formats
these claims would ride in, and the audit-architecture discussion
(draft-kuehlewind-audit-architecture) is where per-action record contents are
being worked. Your two claims read to me like candidate fields for both. If you
want them in the cross-proposal mapping Karthik is maintaining, I'm happy to
help place them — they're orthogonal to the delegation rows, which is exactly
why they're worth recording.
One substantive note: operator-of-record's gap is sharpest in presentation
formats where all operation is key-possession. Delegation-native artifact
families that carry distinct agent identity alongside the acting-for principal
make operation-mode explicit by construction — which suggests opr's highest
value is at translation boundaries, where a delegation-native trail is
projected into a format that erases it. That boundary might be worth a sentence
in the draft.
Morgan
On Tuesday, July 21st, 2026 at 11:05 AM, Anivar Aravind <[email protected]> wrote:
> Hi all,
>
> In the cross-domain delegation thread, Morgan's R5/R6 row highlighted
> something. the audit trail ends up attesting what each service chose to
> preserve rather than what the principal delegated. That is a gap about what
> survives transcription. I think there is a neighbouring one about what cannot
> be written down in the first place.
>
> I ran into this concretely while working through the guardian-operated wallet
> case. A key-binding proof under agent operation is cryptographically
> identical to a human-operated one, and no field in OpenID4VP, SD-JWT-VC, or
> ISO 18013-5/-7 marks the difference. Nor could I find any claim that names
> the party an action lands on when that party is neither the agent, the
> delegator, nor the owner of the resource being accessed.
>
> I posted two claims for those on Sunday:
>
> https://datatracker.ietf.org/doc/draft-aravind-oauth-decision-subject
>
> https://datatracker.ietf.org/doc/draft-aravind-oauth-operator-of-record
>
> Both are OPTIONAL and descriptive; a PDP MUST ignore them. They compose with
> act and may_act rather than competing with them: act and may_act are
> positional, while opr is retrospective. Registration would be through the JWT
> Claims registry (Specification Required, via the jwt-reg-review path), so
> this needs no working group action and I'm not asking for adoption. The
> drafts simply exist as dated references for the discussion.
>
> Should the model be able to name these parties at all when they are distinct
> from sub and act, or is that better treated as a deployment concern? And on
> placement: I've put them in the audit record or a per-action assertion rather
> than the access token, since the access token is per-session and minted
> before target selection. If that's wrong, the container question is more
> interesting to me than the claim names.
>
> If this fits better in WIMSE or the audit discussion, pointers welcome.
>
> Anivar A. Aravind
> Independent researcher
>
> --
> [https://anivar.net](https://anivar.net/)
> Newsletter: http://layer8.anivar.net/
> LinkedIn: https://www.linkedin.com/in/anivar/
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
