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 2A545119C7665 for ; Sun, 19 Jul 2026 11:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784487142; bh=nQpoQKRUHhyelODJGeWgg6h1hGXmgrAYQBL6/9QLsk4=; h=Date:From:To:In-Reply-To:Subject; b=BWnb1QGftqBYWl27XH8aoWX7f1luqRG3tAylF8JE0Ns8KVgoLGOKIhmnuy03rYBAN jbzR1/jYqKGPmB+GqApxpRdupBtexhzEL6nPloz2pw03YqQoSTPEYFX3lQWHVLZ4K8 n20CCS6w9g5CpK1cCOwOckQSPyEEtOTLX7bntOn0= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=keelapi.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 lq9rOEEVfLzK for ; Sun, 19 Jul 2026 11:52:21 -0700 (PDT) Received: from sender4-op-o15.zoho.com (sender4-op-o15.zoho.com [136.143.188.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 96BC7119C7643 for ; Sun, 19 Jul 2026 11:52:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784487139; cv=none; d=zohomail.com; s=zohoarc; b=MNle0vr+DK5D/7qyJ61lT/OSA8CbzcJhCrY7z+OtcGubcPR7mX0vi020NSFOvZzKb+Z7nd00+rjwUm6Un2KpkbrzIyXZXefydQlBGUaSC7jiSKl80XCZ1h2Ek137CZ+toCQNyT8nqelZe55kr86W1ypRidmzKZo4ASsX+oawHUU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1784487139; h=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=nQpoQKRUHhyelODJGeWgg6h1hGXmgrAYQBL6/9QLsk4=; b=SW8w384MWHwHDJaVEhWTTguGgls9732woR5Izr3rNJ4ULELPre3Szdt+5PZyqzRcDrzJ3KurrMopQdF1CiCqdyYUK529Wjuds212E4PdcBUDgR1xhS1KQ1vnAPUSZeQxAOMcvx/zMxenw7d86rpsb0atLIKhxjW2huyWaqIa8ls= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=keelapi.com; spf=pass smtp.mailfrom=christian@keelapi.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1784487139; s=zmail; d=keelapi.com; i=christian@keelapi.com; h=Date:Date:From:From:To:To:Message-Id:Message-Id:In-Reply-To:Subject:Subject:MIME-Version:Content-Type:Reply-To:Cc; bh=nQpoQKRUHhyelODJGeWgg6h1hGXmgrAYQBL6/9QLsk4=; b=L4uHLp0zU5xad7SApZ8p/V9HMfUj6JFhlVWqHwKwFJtK2xAZOUH+MGTM19bXssg/ eb0j9VSex92oYXVIr0oTItB5tPfMIaYNb1Wggp65x7pLd0kIbztA5gdshdEyOMAn0KW hFJ63ysrZtTmHvk9Dx7o8rPvWDWCkpbOZE4Sagss= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1784487139389547.3286877349888; Sun, 19 Jul 2026 11:52:19 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1784487138822226.87215917919502; Sun, 19 Jul 2026 11:52:18 -0700 (PDT) Date: Sun, 19 Jul 2026 11:52:18 -0700 From: =?UTF-8?Q?Christian_=E2=80=94_Keel?= To: "wimse" Message-Id: <19f7bb8d5cc.59ca36331581131.6078881875228146344@keelapi.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5439216_507036131.1784487138764" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Message-ID-Hash: HADP22F2LQKWE7EOFMEJ2JHT6CY3C6JD X-Message-ID-Hash: HADP22F2LQKWE7EOFMEJ2JHT6CY3C6JD X-MailFrom: christian@keelapi.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 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: ------=_Part_5439216_507036131.1784487138764 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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. ------=_Part_5439216_507036131.1784487138764 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
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 tr= y to build on both.

On #5: I'd really like to see that distinction between postu= re at issuance and behavior at request time called out explicitly in the th= reat 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 whethe= r the specific thing the agent is trying
to do right now is actually authori= zed. That's a hole. A compromised-but-attested agent, say one that's been p= rompt-injected, is holding a perfectly valid, fresh, unrevoked credential t= he 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 th= ing that got subverted.

The action was.

On #1: I'm with you on scopi= ng 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 lik= e 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 w= orth 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= .
<= br>
One= disclosure while I'm here. I recently posted draft-munoz-wimse-authorizati= on-evidence as a companion profile covering the audit-evidence side of Sect= ion 11, and I'd be glad to line up terminology wherever it helps.

<= /div>
Thanks again f= or getting into this.

= Best,
<= /div>
Christian Muno= z
Keel API, Inc.

------=_Part_5439216_507036131.1784487138764--