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]
