Hi Judith Regarding your two questions:
> 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? If by continuous access evaluation you mean the ability to adjust access based on a changing risk profile in an environment, I agree that it is a good thing. The work in the shared signals group is a good example of some of the building blocks needed to do this (e.g. the https://openid.net/wg/sharedsignals/). > 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? It is my perspective that in terms of solutions, a "challenge for additional input" from a client/agent/workload and the MFA analogy may be misleading and is unlikely to deliver the desired outcomes when it comes to continuous access evaluation. Some thoughts below: Clients/software/agents/worklloads are subject to a very different lifecycle from human identities. It is expensive to perform human identity proofing (determining that the user is a real user etc), so it is usually done once, and the user is given a number of authentication artefacts that hopefully won't all be compromised. Systems ask for the simplest one to use (ergonomically) and only ask for the more complicated ones if we think the user will tolerate the inconvenience or the risk to the relying party is intolerable (e.g. the system really needs additional evidence that the user is probably the same user that started the transaction). With clients/workloads/agents/software identiy proofing is cheap and can be done everytime a workload requires credentials. The evidence collected during this proofing step can range from simple environment checks all the way to hardware attestation checks. The cost compared to human identity proofing is very low. If you want more assurance, collect more evidence upfront. Issue short lived credentials that are only valid for the duration of an operation (or are very short lived). The client presents these credentials to identify itself to the AS and every other entity with which it might interact. The credentials are always fresh and are frequently renewed (e.g. every few minutes). If you want more certainty about the identity of the client/workload/software/agent, collect that information upfront before issuing the credentials it uses to access the authorization server. If a client/agent/workload/software environment does not meet the identity proofing/attestation rules, the credential is not issued or renewed, resulting in immediate loss of access, without the need for an AS to be involved. The work in WIMSE and SPIFFE provides a good foundation for this type of approach. It is also important to address the access the client/agent/workloadd/software already holds (e.g. an access tokens). This is where the work from the shared signals working group is helpful (e.g. the https://openid.net/wg/sharedsignals/). I would suggest looking in that direction for mechanisms to signal access attenuation. I can foresee the need for a Workload Identity Security Event (WISE) profile for example. Please note that I do agree that continuous access evaluation is important, whether a client or a human (or both) are involved, but step-up authentication for clients/agents/workloads/software seems like a less efficient way to respond to changes in authorization state than other approaches such as those grounded in secure signals or other mechanisms to support dynamic attenuation or revocation of access. Cheers Pieter On Thu, Jul 2, 2026 at 5:51 PM Judith Kahrer <judith.kahrer= [email protected]> wrote: > 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. > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
