[Openid-specs-authzen] FW: [WIMSE] Re: [Wimse] Authorization - some ideas

Lombardo, Jeff jeffsec at amazon.com
Mon Oct 20 00:40:56 UTC 2025 

FYI

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada

Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

From: Yaron Sheffer <yaronf.ietf at gmail.com>
Sent: October 19, 2025 5:51 AM
To: LUCIA CABANILLAS RODRIGUEZ <lucia.cabanillasrodriguez at telefonica.com>; wimse at ietf.org
Subject: [EXT] [WIMSE] Re: [Wimse] Authorization - some ideas


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.

Hi Lucía,

Process-wise, this discussion (and diagram) should actually be moved from the s2s draft into the WIMSE Architecture draft.

And to your point, I think we just wanted to keep options open around authz. In very small deployments there may not be any explicit authz at all - everybody that presents a valid token/signature is trusted. In such deployments the PEP is trivial and there’s no PDP.

We have not had deep discussion of authorization at all, and AFAICT David’s message down this thread actually goes into more depth than the WG or the author team has ever had.

Thanks,
      Yaron

From: LUCIA CABANILLAS RODRIGUEZ <lucia.cabanillasrodriguez at telefonica.com<mailto:lucia.cabanillasrodriguez at telefonica.com>>
Date: Tuesday, 14 October 2025 at 12:20
To: wimse at ietf.org<mailto:wimse at ietf.org> <wimse at ietf.org<mailto:wimse at ietf.org>>
Subject: [WIMSE] Re: [Wimse] Authorization - some ideas
Hello everyone,

I hope this message finds you well.

I have a question regarding Section 1.2 of draft-ietf-wimse-s2s-protocol-06, where it is stated that the PDP (Policy Decision Point) is optional and may only be deployed when policy management is centralized.

From an architectural and security perspective, I was wondering about the rationale behind making the PDP optional. In most policy-based frameworks, the PDP plays a crucial role in ensuring that each action or message passing through a PEP is validated against defined policies, for example, checking protocol compliance, enforcing contextual constraints, or verifying trust requirements before any operation proceeds. Even the identity server could query the PDP beforehand to verify certain conditions or ensure that access or message exchanges comply with established policies.

Additionally, I might have missed some earlier discussion on this topic, but I would also like to understand whether a distributed PDP model (rather than a centralized one) has been considered, as this could preserve policy consistency while maintaining scalability and avoiding single points of failure.

Thank you very much for the clarification, and apologies if this has already been discussed in a previous thread.
Kind regards,

Lucía
De: David Brossard <david.brossard at gmail.com<mailto:david.brossard at gmail.com>>
Fecha: miércoles, 1 de octubre de 2025, 12:04
Para: wimse at ietf.org<mailto:wimse at ietf.org> <wimse at ietf.org<mailto:wimse at ietf.org>>
Asunto: [Wimse] Authorization - some ideas
AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi everyone,

I saw the recording of the interim meeting last week (video<https://www.youtube.com/watch?time_continue=1929&v=BqPBEfhMOUM>) and wanted to chime in.

First of all, I think I agree with what Joseph Saloway says on the call. And of course largely with Pieter and Justin: authorization is an orthogonal concern and we shouldn't reinvent the wheel. Let's go get authorization frameworks and patterns where they live.

Secondly, I think we need to clearly distinguish between different types of access control/authorization. If we do this, it'll help distinguish between an OAuth-based (or biased) approach to authZ vs. an "ABAC" approach to authorization.

In my mind, OAuth is great for access delegation (I grant Twitter the right to post on my wall). UMA is great for user delegation. OAuth RAR is great to scope down what clients can do (e.g. the OpenBanking payment examples). All these approaches tend to be user-centric (though I suppose they don't have to be) and all these approaches tend to rely on the RP knowing what to do with the tokens/claims/scopes. In other words, authorization is still left in the hands of the app being protected (or workload in WIMSE).

This is where ABAC comes into play (and granted, comparing OAuth, a standard/technology, to a framework is skewed at best). When I say ABAC, by the way, I'm referring to the NIST 800-162 definition or even the Zero Trust NIST 800-207 definition i.e.

  *   externalized authorization outside the app and inside a PDP
  *   runtime authorization: decisions are made at access time, not login, not session, not creation
How ABAC is implemented is irrelevant (whether Graph or policies and if so, which policies).

So my two cents: yes of course WIMSE needs a clean decoupling and that decoupling can only happen IMHO via a PEP/PDP Architecture

This is in fact very much in line with the current draft that includes the picture below. Perhaps, my comment would be that the PEP could sit in front of workloads, gateway-style (Kong, Istio, you name it - there could be workload-friendly proxies). And of course, shameless plug, step (4) could be OpenID AuthZEN.



   +------------+               +------------+

   |            |      (1)      |            |

   |            |<=============>|            |

   |            |               |            |

   | Workload A |      (3)      | Workload B |

   |            |==============>|            |

   |            |               |            |

   |            |      (5)      |   +--------+

   |            |<==============|   |  PEP   |

   +------------+               +---+--------+

         ^                        ^     ^

         |            (2)         |     |

     (2) | +----------------------+     | (4)

         | |                            |

         v v                            v

   +------------+               +------------+

   |            |               |            |

   |  Identity  |               |    PDP     |

   |   Server   |               | (optional) |

   |            |               |            |

   +------------+               +------------+





So, what does WIMSE need to do?

·        Define use cases: what are the authz requirements we envisage? This will also help clarify the other questions on this mailing list re. identifiers and their granularity.

·        Suggest profiles for other standards e..g. the AuthZEN Profile of WIMSE

·        Suggest policies: using ALFA, Rego or Cedar, what does a sample policy look like?

All of these need NOT be in the core spec but rather in a profile so long as the architecture is in the core spec (which it currently is).



Yaron also draws a parallel with MCP and even more so A2A. I've started seeing those use cases. The MCP use cases are not much different from traditional entreprise access control use cases (an employee can view data in their branch - typical mandatory access control).



A2A (and I think WIMSE as well) brings about another type of use case which blends both the mandatory type of access control and the access delegation type of access control. For instance, can agent A book travel using agent B on behalf of Bob the end user? Bob had previously delegated authority/access to agent A so it can book a trip up to $2,000 and only within the EU.



Will we see similar use cases here?



To summarize, I'd suggest the WIMSE spec follow an architecture that aligns well with ABAC if only for the sake of "zero trust". I am excited to see authorization is a hot topic so I'll strive to attend the regular calls.



Thanks,

David

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20251020/26af2ea4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8556 bytes
Desc: image002.png
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20251020/26af2ea4/attachment-0001.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20251020/26af2ea4/attachment-0001.txt>

More information about the Openid-specs-authzen mailing list