MIME-Version: 1.0
From: Kunal Ghosh <kghoshworkid@gmail.com>
Date: Fri, 17 Jul 2026 14:31:01 -0700
Message-ID: 
 <CAHNRNd3GNnbCC7Bh6MKoprHDBaehH8q8SaxFtRNMXG4Z-HPEUA@mail.gmail.com>
To: wimse@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008f9e470656d546a4"
Message-ID-Hash: AGEZ7IESSLFEDQJSHL44GVOBHBJNTIPV
Precedence: list
Subject: =?utf-8?q?=5BWIMSE=5D_Review_of_draft-klrc-aiagent-auth-03?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/wimse/cJ5Zg2I9p5i2f9cRw4TCcneBT1g>

--0000000000008f9e470656d546a4
Content-Type: text/plain; charset="UTF-8"

Hi Authors, all,

I hope you are doing well. I am new to the list. It is amazing to see such
good work going on in the AI Agent domain. A little background on where my
comments come from: I work on on-device threat defense and enterprise
identity at Samsung Research America, and previously worked on Universal
Logout at Okta. My comments revolve around revocation and the
human-in-the-loop section, and build in part on Yaron's review of the
2026-06-01 editor's copy.

1) I see a possible tension between Section 8 and Section 11 on revocation

Section 8 states that short-lived credentials provide "an alternative to
explicit revocation mechanisms."
Section 11 states that recipients of SSF/CAEP/RISC signals "MUST ensure
that revoked or downgraded authorization is enforced without undue delay,"
and that cached tokens "MUST NOT continue to be used after a revocation or
risk notification is received."

I may be misreading, but these seem to pull in different directions:
Section 8 positions expiry as a substitute for revocation, while Section 11
treats revocation as a live, mandatory obligation. The distinction may be
threat-model dependent. Expiry works well for credential theft. It works
poorly for a compromised agent - one that is correctly attested and holds
an unexpired credential, but whose behavior has been subverted (e.g. via
indirect prompt injection). In that case the credential remains valid and
correct for its full lifetime while the agent acts outside its intended
scope, and typical credential lifetimes exceed the time needed to act.

Would it be worth either reconciling these two sections explicitly, or
scoping Section 8's claim to the credential-exposure threat model rather
than compromise generally?

2) Section 11 makes subscription optional but enforcement mandatory

Section 11 says participants "MAY subscribe" to SSF with CAEP or RISC, but
that recipients "MUST" enforce on receipt. The MUST is therefore
conditional on the MAY. A deployment that does not subscribe has no
revocation path at all, and silently falls back to the Section 8 expiry
model without the document saying so.

Would the working group consider whether subscription should be SHOULD, or
MUST, for agents authorized to access sensitive resources? It is entirely
possible this is deliberate deployment latitude, in which case it may still
be worth stating the consequence.

3) Section 10.7: same-device deployments weaken the out-of-band property

Yaron notes in TECH-8 that CIBA assumes a push notification to a separate
device, while the agent flow may already be running on a mobile device. I
would like to extend that from the device-security side, as it is where
most of my work sits.

CIBA's value in Section 10.7 rests on the interaction being genuinely
out-of-band - the approval channel is assumed to be independent of the
requesting client. When an on-device agent and the authenticator
application share a device, that independence is gone: a device compromise
takes both the agent and the approval channel, and the confirmation is
in-band in all but name. This is not hypothetical - on-device agents
running alongside the user's authenticator are becoming common.

This does not invalidate the CIBA guidance, but the assumption seems worth
stating, along with what deployments can do when it does not hold (e.g.
relying on platform-level isolation for the approval path, or requiring a
distinct device for higher-risk operations).

4) Section 10.7 Note: RFC 9470 as a possible input to the mid-execution case

The Note in the Human in the Loop section observes that CIBA only accounts
for client initiation and does not map well to User confirmation occurring
mid-execution. Yaron's TECH-8 raises a related concern about the threat
model. I do not see RFC 9470 (OAuth 2.0 Step Up Authentication Challenge)
in Section 18, so offering it as a possible input rather than a correction:

9470's model is resource-server-initiated - the RS inspects the
authentication context behind the presented token and returns
insufficient_user_authentication with acr_values / max_age. That addresses
the initiation direction the Note identifies, and it places the trigger at
the resource, where the sensitivity of the specific action is known. The
obvious obstacle is that 9470 assumes the client can direct a user agent to
the AS, which an autonomous agent does not have. But 9470 is agnostic about
the grant used to satisfy the challenge, so a composition may be possible:
a 9470-style challenge from the resource server as the trigger, with CIBA
as the out-of-band grant that satisfies it.

One wrinkle if this were pursued: 9470's acr and auth_time reflect the
original user authentication event and do not change on token renewal,
which may need thought for long-running agent sessions.

Was 9470 considered for this case? If it was ruled out, I would find the
reasoning useful, and would rather understand it than reopen settled ground.

5) Section 14 and agent-specific threats

Section 14 defers to the security considerations of each referenced
specification, plus OAuth BCP and FAPI 2.0. Given the goal in Section 1 of
identifying gaps to guide future standardization, is agent-specific threat
analysis in scope for this document - in particular the
compromised-but-attested agent, where posture assessment at issuance
(Section 8) establishes what an agent is, but not what it is doing at
request time? If that is in scope and useful, I would be glad to help draft
text.

Thanks for the document. The consolidation framing in Section 1 is very
useful, and the prior-art mapping is more complete than most work I have
seen in this area.

Happy to upload any of these as GitHub issues if the authors prefer.

Regards,
Kunal Ghosh
ORCID: 0009-0007-4602-5624
kghoshworkid.github.io

--0000000000008f9e470656d546a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Authors, all,<br><br>I hope you a=
re doing well. I am new to the list. It is amazing to see such good work go=
ing on in the AI Agent domain. A little background on where my comments com=
e from: I work on on-device threat defense and enterprise identity at Samsu=
ng Research America, and previously worked on Universal Logout at Okta. My =
comments revolve around revocation and the human-in-the-loop section, and b=
uild in part on Yaron&#39;s review of the 2026-06-01 editor&#39;s copy.<br>=
<br>1) I see a possible tension between Section 8 and Section 11 on revocat=
ion<br><br>Section 8 states that short-lived credentials provide &quot;an a=
lternative to explicit revocation mechanisms.&quot;<br>Section 11 states th=
at recipients of SSF/CAEP/RISC signals &quot;MUST ensure that revoked or do=
wngraded authorization is enforced without undue delay,&quot; and that cach=
ed tokens &quot;MUST NOT continue to be used after a revocation or risk not=
ification is received.&quot;<br><br>I may be misreading, but these seem to =
pull in different directions: Section 8 positions expiry as a substitute fo=
r revocation, while Section 11 treats revocation as a live, mandatory oblig=
ation. The distinction may be threat-model dependent. Expiry works well for=
 credential theft. It works poorly for a compromised agent - one that is co=
rrectly attested and holds an unexpired credential, but whose behavior has =
been subverted (e.g. via indirect prompt injection). In that case the crede=
ntial remains valid and correct for its full lifetime while the agent acts =
outside its intended scope, and typical credential lifetimes exceed the tim=
e needed to act.<br><br>Would it be worth either reconciling these two sect=
ions explicitly, or scoping Section 8&#39;s claim to the credential-exposur=
e threat model rather than compromise generally?<br><br>2) Section 11 makes=
 subscription optional but enforcement mandatory<br><br>Section 11 says par=
ticipants &quot;MAY subscribe&quot; to SSF with CAEP or RISC, but that reci=
pients &quot;MUST&quot; enforce on receipt. The MUST is therefore condition=
al on the MAY. A deployment that does not subscribe has no revocation path =
at all, and silently falls back to the Section 8 expiry model without the d=
ocument saying so.<br><br>Would the working group consider whether subscrip=
tion should be SHOULD, or MUST, for agents authorized to access sensitive r=
esources? It is entirely possible this is deliberate deployment latitude, i=
n which case it may still be worth stating the consequence.<br><br>3) Secti=
on 10.7: same-device deployments weaken the out-of-band property<br><br>Yar=
on notes in TECH-8 that CIBA assumes a push notification to a separate devi=
ce, while the agent flow may already be running on a mobile device. I would=
 like to extend that from the device-security side, as it is where most of =
my work sits.<br><br>CIBA&#39;s value in Section 10.7 rests on the interact=
ion being genuinely out-of-band - the approval channel is assumed to be ind=
ependent of the requesting client. When an on-device agent and the authenti=
cator application share a device, that independence is gone: a device compr=
omise takes both the agent and the approval channel, and the confirmation i=
s in-band in all but name. This is not hypothetical - on-device agents runn=
ing alongside the user&#39;s authenticator are becoming common.<br><br>This=
 does not invalidate the CIBA guidance, but the assumption seems worth stat=
ing, along with what deployments can do when it does not hold (e.g. relying=
 on platform-level isolation for the approval path, or requiring a distinct=
 device for higher-risk operations).<br><br>4) Section 10.7 Note: RFC 9470 =
as a possible input to the mid-execution case<br><br>The Note in the Human =
in the Loop section observes that CIBA only accounts for client initiation =
and does not map well to User confirmation occurring mid-execution. Yaron&#=
39;s TECH-8 raises a related concern about the threat model. I do not see R=
FC 9470 (OAuth 2.0 Step Up Authentication Challenge) in Section 18, so offe=
ring it as a possible input rather than a correction:<br><br>9470&#39;s mod=
el is resource-server-initiated - the RS inspects the authentication contex=
t behind the presented token and returns insufficient_user_authentication w=
ith acr_values / max_age. That addresses the initiation direction the Note =
identifies, and it places the trigger at the resource, where the sensitivit=
y of the specific action is known. The obvious obstacle is that 9470 assume=
s the client can direct a user agent to the AS, which an autonomous agent d=
oes not have. But 9470 is agnostic about the grant used to satisfy the chal=
lenge, so a composition may be possible: a 9470-style challenge from the re=
source server as the trigger, with CIBA as the out-of-band grant that satis=
fies it.<br><br>One wrinkle if this were pursued: 9470&#39;s acr and auth_t=
ime reflect the original user authentication event and do not change on tok=
en renewal, which may need thought for long-running agent sessions.<br><br>=
Was 9470 considered for this case? If it was ruled out, I would find the re=
asoning useful, and would rather understand it than reopen settled ground.<=
br><br>5) Section 14 and agent-specific threats<br><br>Section 14 defers to=
 the security considerations of each referenced specification, plus OAuth B=
CP and FAPI 2.0. Given the goal in Section 1 of identifying gaps to guide f=
uture standardization, is agent-specific threat analysis in scope for this =
document - in particular the compromised-but-attested agent, where posture =
assessment at issuance (Section 8) establishes what an agent is, but not wh=
at it is doing at request time? If that is in scope and useful, I would be =
glad to help draft text.<br><br>Thanks for the document. The consolidation =
framing in Section 1 is very useful, and the prior-art mapping is more comp=
lete than most work I have seen in this area.<br><br>Happy to upload any of=
 these as GitHub issues if the authors prefer.<br><br>Regards,<br>Kunal Gho=
sh<br>ORCID: 0009-0007-4602-5624<br><a href=3D"http://kghoshworkid.github.i=
o" target=3D"_blank">kghoshworkid.github.io</a></div></div>
</div>

--0000000000008f9e470656d546a4--