Return-Path: X-Original-To: wimse@mail2.ietf.org Delivered-To: wimse@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 93F9311BB14D4 for ; Tue, 21 Jul 2026 13:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784665133; bh=rW5lPAy54TNEA1sDRqIuRSyzUMennt42fOP61062cfg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=K92qpo5+/lq+6HhrMn8V+5ughCy+DX1fnzv3kCbwhrsWh3D8TOhO1IrhpR+wQtTvk ho2omNg7n4qimD+KezoEXNsjwisXF9xfvIZCFQ0lsORfMZYS4v1PRUaw9wo0y+L/1Y oYVN9hVvN4/GPKggNhteYXoanxLI8unCdQEcipxE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj5vJfJB3D4E for ; Tue, 21 Jul 2026 13:18:52 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B3C1D11BB14CD for ; Tue, 21 Jul 2026 13:18:52 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-2cf50c6f235so39067705ad.0 for ; Tue, 21 Jul 2026 13:18:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784665132; cv=none; d=google.com; s=arc-20260327; b=PxFLIX0QbDNL9LlZBr8PkaehLLjpOi0yvBUdosjg4PbK6rLIaGmll+GpxYPDKOstNf uv83OeQfHMJa5gks9ZxgWh4BAWmUHyCj92y+OLp97SPyMm69QXRFzLtkApvUG9dQqHW6 MtZR+ebfI88c8Er7qggEjG0fj9Zhzqda/PE1/wQvfjTI0Dch1aHnLMgwxRayuzc4Exs+ 2BbxezZEAtTF6PHTknpkpBRj8iCzkbY/V1RyEPuJrpvNxkRTXKPc6OVRAd110RmKds9t sJbIYHS6oT3LhC6nTAlxMdu8awqjMwjAIOjEIQE+cA+p5NAgnVkYlFFlqkKNqRs0eNGJ c6Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=rW5lPAy54TNEA1sDRqIuRSyzUMennt42fOP61062cfg=; fh=O2ikpNL8ac8urB6+jE3yMzLw+VaBwCFv3Nlbm/b3qMo=; b=ir0d6yjSS5nCFLV42pZ2x9J0/b92zaG/5uGRmct+G0Dlwbd+BDaF2K6R+/KtpY6e5u PFXEFBTH9r+u+g42M53mVjGeBm8rD6SQiFqR5JHztN2yg31QCfvkwDdKs5YPM4kRS+0N 4ebBoiQrLXSIzK/P2w5guLW+b34iBHCd0WNy1NNiQ8tnwXSlttILImUl+Y32Fv4yFTOU V4OgHFh6rrBakFv6PuO/goPO/1tWAAE2/NklyDbCkFp3rkLOaF3b+nntzIXn/L5bycsx GtVjehPwm10gP01eIaL6pJ4uzH1gX0k3y/N5Bbe6BYTWySsFCfqzjRcZSEJX9XFEXkS9 5dSw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784665132; x=1785269932; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rW5lPAy54TNEA1sDRqIuRSyzUMennt42fOP61062cfg=; b=A+sCz04XsCzbf7TzvwReLYP9cABGLQmLSTeuLm23HgAfveyfdFm+2gxR44N+2b/rd8 9F5iBtz6WOz9rVuU6EWFjQ+uuOt+exrYtx7QXjdiuT0netB3DQXhJEaG29Yo115fDEVw 6G8wxYKwRijGEB2kJXbq8MjGzj3XP90pwMr6nejlNx8eYPQgHHS3r8NP5sAP8XTHt0wD P/vHh7cjJGruC83RaKJcUp6wXN9FVSD1iOzyHMWMjQ744vouRzADsTBMw99AtPHpgp3z 4OQ5kPQsFjhwn2UMHp9R07AL0iSQo38CbLBCeveR7X+R05vEGokiywVGxkIon4d0iZJf As8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784665132; x=1785269932; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=rW5lPAy54TNEA1sDRqIuRSyzUMennt42fOP61062cfg=; b=V45iHgik73nJoZDZg9KR2p0PWBhqLLdT6wRCXRgNzIhII4fAxpd9qI2oB4p0FhrqCx ch8SJYob1rw56IHdaNEO5nLq7MnBKTTruD05y6MGxWPYjBea0z4JkgRORPWQ82PtZuXA cuQyI4BmBlttR4ojzJp3wUsK9XS32jBmNIcNFBmOhc9wO+9b056Rjsf0qSsLQMYJN8dg 9ZD+JZ4eb9l6fmfPbFQJAKzKZ3Pq7TwyA/UwfHZ5/OO+lGaQw9suvG8xszzYwiBxd4Dr wy6jDWvQXJ62LTf86nxqKg8YCDFF1HoIVbRxWezaJ41J8pKZMWkdMznXZVP/8kBa2wNj QFaQ== X-Forwarded-Encrypted: i=1; AHgh+RrC0fgh+o46ayHD19hy3xYkNVYeF+aB01g7VHrC5pJ3eDOPujONSMGLdvZDi9APBSxQ2OC6XQ==@ietf.org X-Gm-Message-State: AOJu0YxzSh32Kec89Uz2toXmeS9H1g/qSjOjXSninZ90TYU0zgUOAmuR Mav7GlSNsxnDq1MDp1tMx0yEQsLH5NFlch8X05iw4dBWnej31dvjvV4YcXs46AFKL/C3e7vY46I zh4AT1kXXXC7HuDG71M3pS4aSOUJ+2IU4uqmJ/VU= X-Gm-Gg: AR+sD117V2f+K8AESTnhQeesr4X69bgmCU1/ybuznxk9kNaVhXfjCNnMKMWKriyJhAY c6RtA8nYQhcm7PjD0Lufi1NPg4tXgLQDfjhii1bP3LLq0F27NbhoAFeWgsoo549XWHPRqbxYUBy e25u1TBGjl/FVYXN6XrX36h6oQBQcLrIiq+mbvIcHoHyml0msOJl7ykSkJrTi+sx0aOfL2IRyt5 +eeOBVSDX0QyfTig9ejb9LA0+yX80V+QZHrnCxAoKnoPjAj/+E/IiyNWKaXAtEL42UK1MSFQJEt JqSPzbNtsrMPddWVrDAi X-Received: by 2002:a17:903:2ec5:b0:2ca:d91e:bfb4 with SMTP id d9443c01a7336-2cf349609admr238548275ad.24.1784665131608; Tue, 21 Jul 2026 13:18:51 -0700 (PDT) MIME-Version: 1.0 References: <19f7bb8d5cc.59ca36331581131.6078881875228146344@keelapi.com> In-Reply-To: From: Kunal Ghosh Date: Tue, 21 Jul 2026 13:18:40 -0700 X-Gm-Features: AUfX_mxrGUQsl4NBvYFDTXAGojHCagv89-om-K0rDKKy5uJuo2-BJluSLOLB734 Message-ID: To: Anivar Aravind Content-Type: multipart/alternative; boundary="000000000000366b6a065724bbd1" Message-ID-Hash: XS2NSSDGRNAH5HBTWGY7PVTLCZYZWGW7 X-Message-ID-Hash: XS2NSSDGRNAH5HBTWGY7PVTLCZYZWGW7 X-MailFrom: kghoshworkid@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: =?UTF-8?B?Q2hyaXN0aWFuIOKAlCBLZWVs?= , wimse X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BWIMSE=5D_Re=3A_Review_of_draft-klrc-aiagent-auth-03?= List-Id: WIMSE Workload Identity in Multi-Service Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000366b6a065724bbd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Anivar Aravind wr= ote: > > 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 wort= h > 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 wit= h > a per-action record that's complete, integrity protected, and still silen= t > 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=E2=80=AFAM Kunal Ghosh > wrote: > >> Hi Christian, >> >> Thanks - that's a helpful sharpening. I agree the useful move is to trea= t >> 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, bo= und >> to the actual request and verifiable after the fact, captures the case t= hat >> neither expiry nor revocation reaches - the fully credentialed, compromi= sed >> 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-evide= nce >> 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=E2=80=AFAM Christian =E2=80=94 Keel >> 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 thre= at >>> 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 whe= ther >>> 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 th= at >>> 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 fo= r >>> 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 by= tes >>> 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 alread= y >>> 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 coverin= g >>> 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 -- wimse@ietf.org >>> To unsubscribe send an email to wimse-leave@ietf.org >>> >> -- >> WIMSE mailing list -- wimse@ietf.org >> To unsubscribe send an email to wimse-leave@ietf.org >> > --000000000000366b6a065724bbd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anivar,

That is a useful distinction. The per-ac= tion record giving the "what" but not the "who," and th= e operator question surviving even a complete, integrity-protected proof. T= he point that an agent-produced presentation is cryptographically indisting= uishable 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 (OpenID4= VP, 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&qu= ot; 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 intere= sted to see your descriptive claim if you post it.

Best,
Kunal
On Tue, Jul 21, 2026 at 8:54=E2=80=AFAM Anivar Aravind &= lt;ping@anivar.net> wrote:
> the credential was never the thing that got subverted. The= action was.

I think that's the key distinction, and it has an implic= ation that's worth calling out.

If the action, rather than the cr= edential, is the unit being authorized, then it's also the unit that ha= s to be reconstructable afterwards. A per-action authorization decision tha= t's bound to the request bytes gives an auditor the=C2=A0what. By itself, though, it doesn't necessarily give them the=C2=A0<= strong>who, because the signature over those bytes is produced the= same way whether the request came from a person or from an agent.

Th= at becomes most obvious at the wallet boundary. A key-binding proof in a wa= llet presentation is produced after a local unlock, and relying parties gen= erally 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 questio= n an auditor is likely to ask: who actually operated the wallet?

I do= n't think this changes your argument. If anything, it reinforces it. Th= e per-action record has to carry a little more than the credential it repla= ces: 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, bu= t the underlying point doesn't depend on it.

Anivar A. Aravind

--
https://anivar.= net
Newsletter:=C2=A0https://layer8.anivar.net
Linkedin :=C2=A0https:/= /www.linkedin.com/in/anivar/


On Mon, Jul 20, 2026 at 1:49=E2=80=AFAM= Kunal Ghosh <kghoshworkid@gmail.com> wrote:
Hi Christian,

Thanks - that= 's a helpful sharpening. I agree the useful move is to treat the two la= yers as distinct: authentication and revocation act on the credential and t= he identity, while what you are describing acts on the specific action. Fra= ming per-action authorization as its own control, bound to the actual reque= st 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 w= hich 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-w= imse-authorization-evidence yet, so I will hold specific comments until I h= ave gone through it, but the audit-evidence side sounds directly relevant t= o 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=E2=80=AFAM Christian =E2=80=94 Keel <christian@keelapi.com> wrote:<= br>
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 distincti= on between posture at issuance and behavior at request time called out expl= icitly in the threat model because it's doing a lot of quiet work. Auth= entication 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 i= t doesn't tell you is whether the specific thing the agent is trying
to do right now is a= ctually authorized. That's a hole. A compromised-but-attested agent, sa= y one that's been prompt-injected, is holding a perfectly valid, fresh,= unrevoked credential the whole time, and uses it to do something it should= n't. Expiry won't catch that and revocation won't catch it beca= use the credential was never the thing that got subverted.
=

The action was.
=

On #1: I'm with you on scoping Sec= tion 8 to credential exposure, and I think it ties straight back to #5. Sho= rt-lived credentials are great for the theft and exposure case. They just d= on't do much for an agent that's fully credentialed and compromised= . That leftover case is what makes me want to treat per-action authorizatio= n as its own control, sitting alongside authentication and revocation inste= ad of getting folded into credential lifecycle. In practice that can look l= ike a pre-execution authorization decision that's cryptographicallly bo= und to the actual bytes of the request being authorized, and that you can v= erify after the fact. It's on top of the credential and revocation mach= inery 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 separate= ly, since what mitigates one doesn't mitigate the other.

One disclosure while I'm here. I recently pos= ted draft-munoz-wimse-authorization-evidence as a companion profile coverin= g the audit-evidence side of Section 11, and I'd be glad to line up ter= minology wherever it helps.

Thanks = again for getting into this.
=

Best,
Christi= an Munoz
Keel API, Inc.

=
--
WIMSE mailing list -- w= imse@ietf.org
To unsubscribe send an email to wimse-leave@ietf.org
--
WIMSE mailing list -- w= imse@ietf.org
To unsubscribe send an email to wimse-leave@ietf.org
--000000000000366b6a065724bbd1--