Judith, Yaron, Agree with Yaron's central point: additional client authentication challenges cannot address the unpredictability of what the client does with access it already holds. With AI-driven clients the client is typically legitimate. Attestation passes, keys are valid, the token is fresh. The risk surface is the individual action, not the client's identity.
That is why I would separate two questions this discussion risks conflating. First: should this client continue to hold access? CAEP signals, shorter grant lifetimes, refresh cycles and cross-app-access all operate here. They shrink the window between drift or compromise and revocation. Necessary, and session-granularity by construction. Second: did the human principal authorize this specific high-risk action, and can a resource server or auditor verify that after the fact? Shorter lifetimes do not answer this. A five-minute token still authorizes every action within scope for five minutes, and it produces no per-action evidence artifact. On the MFA-for-clients analogy: challenging the client raises confidence in the client. For agentic clients that is the wrong target at decision time. The entity whose intent needs verifying at a high-risk action is the human principal behind the client, and the useful output is verifiable evidence cryptographically bound to the action payload, not another point-in-time signal about the client itself. So my take is that continuous access evaluation and per-action authorization evidence are complementary controls at different granularities. Designing only for the first leaves the second question unanswered, and for AI-driven clients the second question is where the losses occur. For reference, this granularity question is the subject of a survey recently submitted to secdispatch, "Authorization Evidence for High-Risk Actions." I would welcome the discussion continuing on this list as well. Regards, Mohamad Khalil Yossif > On 2 Jul 2026, at 21:28, Yaron ZEHAVI > <[email protected]> wrote: > > Dear Judith, > Thanks for raising the topic. > > I share your concerns, in particular since AI driven clients are no longer > software systems developed and tested for a certain functionality with > reliable behavior, rather much more dynamic and unpredictable. > > In my view, additional client authentication challenges cannot address the > unpredictability of what the client is doing with the access it obtains. > Therefore, continuous access evaluation solutions are important as they > provide the signals that something is going wrong. > > In order for such signals to allow preventing further undesirable access, > access grants should have shorter lifetimes requiring clients to periodically > request renewed access, allowing intervention and prevention. > > Solution designs aiming to address these concerns should in my view leverage > shorter grant lifetimes, refresh tokens and the Identity Assertion JWT > Authorization Grant (cross-app-access) > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant, > all of which require clients to engage authorization servers, which can then > evaluate requested access. > > And +1 on the discussion, happy to learn about how the full mature CAEP > driven solution can look like, which rfcs are involved etc. > > Regards, > Yaron > > > > Classification: GENERAL > From: Judith Kahrer <[email protected] > <mailto:[email protected]>> > Sent: Thursday, July 2, 2026 6:42 PM > To: oauth <[email protected] <mailto:[email protected]>> > Subject: [OAUTH-WG] Continuous Access Evaluation and Conditional Access > Control for Clients > > This message is from an external sender - be cautious, particularly with > links and attachments. > > Dear working group, > I'm interested in the communities and other identity expert's view on a topic > I have mulled over lately. > With more and more focus on clients (mainly driven through AI discussions), > isn't it time to start thinking about continuous access evaluation for > clients? > In such an environment, wouldn't it make sense for the authorization server > to also challenge the client for additional input to increase its confidence > in the client and its behavior, similar to MFA or step-up authentication for > users? > What are your takes, thoughts? > > Yours, Judith > > P.S.: "I don't care, I simply need to survive this day", " I'm too busy with > other stuff. " or a simple "I haven't thought about it yet." are valid > answers as well. > This message and any attachment ("the Message") are confidential. If you have > received the Message in error, please notify the sender immediately and > delete the Message from your system, any use of the Message is forbidden. > Correspondence via e-mail is primarily for information purposes. RBI neither > makes nor accepts legally binding statements via e-mail unless explicitly > agreed otherwise. Information pursuant to ยง 14 Austrian Companies Code: > Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 > Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court > of Vienna (Handelsgericht Wien). > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
