Morgan, Your R4/R8 argument is a better reason for that placement than the one I actually used, which was mostly instinct. Good to have it nailed down properly.
Yes on the matrix, thanks for offering to broker it. Whoever ends up writing the row, here's what each claim actually says: - decision-subject (dsub): the party a credential/agent action is taken upon, when that party is not the agent, not the delegator, and not the resource owner. https://datatracker.ietf.org/doc/draft-aravind-oauth-decision-subject - operator-of-record (opr): who was operating the credential/agent when the action happened, independent of who holds the underlying key. https://datatracker.ietf.org/doc/draft-aravind-oauth-operator-of-record R1-R9 doesn't have a slot for either right now. R5 comes closest, and R5 is about who authorized the action, not who it landed on. I'd rather that stayed a visible distinction than quietly folded into R5. New row or sub-point, I'll leave that call to you and Karthik. On translation boundaries, it is worth a sentence, agreed. I'd frame it slightly differently: delegation-native formats have no operator-of-record field either, so the gap predates translation. Translation doesn't create it. It's just the point where a format that could carry the field gets replaced by one that can't. Thanks for pushing this along. Anivar On Tue, Jul 21, 2026 10:16 PM, morganLR <[email protected]> wrote: > 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 > 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]
