Based on the identity, and accounting, in the lower conceptual level of the architecture, a gatekeeping reverse proxy, such as https://www.haproxy.org/ or similar, becomes the front end of the federated ecosystem.
Other than activities related to OIDC/OAuth2 authorization / authentication, no unidentified traffic passes the gate. Users are only anonymous in as much as they might spawn a new identity for the duration of the session. If a particular application wants to optimize for anonymity, it might structure itself to have a very short or even single transaction session duration, but for most purposes a single (say: 5 minute) session identity is “anonymous enough.”
I would envision most services being pseudonymous, rather than fully anonymous. Identities might be created and used for months to years. Of course the cryptographic keys behind the identities can be refreshed periodically for security without losing continuity of the pseudonyms they are associated with.
System operators might keep a number of components “behind the proxy” that can short-cut communicate with each other without traversing the proxy, but component developers should always keep their components capable of navigating the proxies so that federated resources can be accessed seamlessly, as if they were local but just a bit slower to get to. To get explicit: machine to machine communication identifies itself to the proxy front ends more or less the same as human users: with cryptographically secure non-refutable identification of the clients and servers.
Session times might extend as long as 24 hours, but any service that accepts a session time greater than 60 seconds should also provide a mechanism for terminating sessions early on demand.
I must admit, I’m out of my depth when it comes to reverse proxy configuration and operation. Readers may also have noticed: the Accounting description lacked any specifics… anyone who knows of existing identity / resource management accounting solutions that tie in to reverse proxy software for real-time load balancing, routing and rejection of unauthorized users / determination of user authorization based on their resource usage, I’d appreciate a link / clue or two. Thanks.
One scenario this architecture is attempting to mitigate is: bot assault. If a service wants to be wide open to new users / partners, meaning such new entities are basically anonymous, it should be able to protect / maintain availability for known / authorized users by limiting resource availability to the unknown or poorly established entities.