[WIMSE] Re: Review of draft-klrc-aiagent-auth-03

[Kunal Ghosh <[e-mail]>]

Hi Anivar,

That is a useful distinction. The per-action record giving the "what" but
not the "who," and the operator question surviving even a complete,
integrity-protected proof. The point that an agent-produced presentation is
cryptographically indistinguishable from a person-produced one at the
wallet boundary is not something I had considered, and it does seem to
reinforce rather than complicate the layering Christian described.

The wallet-presentation side (OpenID4VP, SD-JWT-VC, ISO 18013) is outside
what I can speak to with any authority, so I will follow more than lead
there. But the "mode of operation" point - that the record may need to
carry not just what was authorized but the operational context under which
it happened - seems worth capturing if this feeds into the threat-model
text for Section 14. I would be interested to see your descriptive claim if
you post it.

Best,
Kunal

On Tue, Jul 21, 2026 at 8:54 AM Anivar Aravind <[e-mail]> wrote:

> > the credential was never the thing that got subverted. The action was.
>
> I think that's the key distinction, and it has an implication that's worth
> calling out.
>
> If the action, rather than the credential, is the unit being authorized,
> then it's also the unit that has to be reconstructable afterwards. A
> per-action authorization decision that's bound to the request bytes gives
> an auditor the *what*. By itself, though, it doesn't necessarily give
> them the *who*, because the signature over those bytes is produced the
> same way whether the request came from a person or from an agent.
>
> That becomes most obvious at the wallet boundary. A key-binding proof in a
> wallet presentation is produced after a local unlock, and relying parties
> generally treat it as evidence that a person saw and approved that
> disclosure. Under agent operation, the same unlock happens and the
> resulting proof is cryptographically identical. Nothing in OpenID4VP,
> SD-JWT-VC, or ISO 18013-5/-7 distinguishes the two. So you can end up with
> a per-action record that's complete, integrity protected, and still silent
> on the first question an auditor is likely to ask: who actually operated
> the wallet?
>
> I don't think this changes your argument. If anything, it reinforces it.
> The per-action record has to carry a little more than the credential it
> replaces: not just what was authorized, but the mode of operation under
> which it happened. I have a short descriptive claim for that if it's
> useful, but the underlying point doesn't depend on it.
>
> Anivar A. Aravind
>
> --
> https://anivar.net
> Newsletter: https://layer8.anivar.net
> Linkedin : https://www.linkedin.com/in/anivar/
>
> On Mon, Jul 20, 2026 at 1:49 AM Kunal Ghosh <[e-mail]>
> wrote:
>
>> Hi Christian,
>>
>> Thanks - that's a helpful sharpening. I agree the useful move is to treat
>> the two layers as distinct: authentication and revocation act on the
>> credential and the identity, while what you are describing acts on the
>> specific action. Framing per-action authorization as its own control, bound
>> to the actual request and verifiable after the fact, captures the case that
>> neither expiry nor revocation reaches - the fully credentialed, compromised
>> agent.
>>
>> If the authors find it useful, naming these separately in Sections 8, 11,
>> and 14 (credential-lifecycle vs. revocation vs. per-action authorization,
>> and which threat each does and does not mitigate) seems like it would
>> remove the ambiguity I raised in points 1 and 5.
>>
>> I have not read draft-munoz-wimse-authorization-evidence yet, so I will
>> hold specific comments until I have gone through it, but the audit-evidence
>> side sounds directly relevant to the Section 11 enforcement question. I
>> will follow up on that draft's thread once I have read it properly.
>>
>> Best,
>> Kunal
>>
>> On Sun, Jul 19, 2026 at 11:52 AM Christian — Keel <[e-mail]>
>> wrote:
>>
>>> Hey Kunal, thanks for this....
>>>
>>> It's a genuinely thoughtful review, and I think points #1 and #5 get
>>> right to the heart of it.
>>>
>>> Let me try to build on both.
>>>
>>> On #5: I'd really like to see that distinction between posture at
>>> issuance and behavior at request time called out explicitly in the threat
>>> model because it's doing a lot of quiet work. Authentication tells you who
>>> or what the agent is at the moment it's issued a credential, and short
>>> credential lifetimes don't change that. What it doesn't tell you is whether
>>> the specific thing the agent is trying
>>> to do right now is actually authorized. That's a hole. A
>>> compromised-but-attested agent, say one that's been prompt-injected, is
>>> holding a perfectly valid, fresh, unrevoked credential the whole time, and
>>> uses it to do something it shouldn't. Expiry won't catch that and
>>> revocation won't catch it because the credential was never the thing that
>>> got subverted.
>>>
>>> The action was.
>>>
>>> On #1: I'm with you on scoping Section 8 to credential exposure, and I
>>> think it ties straight back to #5. Short-lived credentials are great for
>>> the theft and exposure case. They just don't do much for an agent that's
>>> fully credentialed and compromised. That leftover case is what makes me
>>> want to treat per-action authorization as its own control, sitting
>>> alongside authentication and revocation instead of getting folded into
>>> credential lifecycle. In practice that can look like a pre-execution
>>> authorization decision that's cryptographicallly bound to the actual bytes
>>> of the request being authorized, and that you can verify after the fact.
>>> It's on top of the credential and revocation machinery the draft already
>>> has instead than replacing any of it.
>>>
>>> So concretely: it might be worth having Section 14, and maybe the
>>> Section 8 and 11 language, name these two layers separately, since what
>>> mitigates one doesn't mitigate the other.
>>>
>>> One disclosure while I'm here. I recently posted
>>> draft-munoz-wimse-authorization-evidence as a companion profile covering
>>> the audit-evidence side of Section 11, and I'd be glad to line up
>>> terminology wherever it helps.
>>>
>>> Thanks again for getting into this.
>>>
>>> Best,
>>> Christian Munoz
>>> Keel API, Inc.
>>>
>>> --
>>> WIMSE mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> --
>> WIMSE mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>