[Openid-specs-authzen] FW: [WIMSE] Re: [Wimse] Authorization - some ideas
David Brossard
david.brossard at gmail.com
Mon Oct 20 08:59:56 UTC 2025
Thanks for relaying this, Jeff. WIMSE is nodding in the right direction but
we need even more support for the PEP/PDP pattern. I've been linking back
to NIST ABAC 800-162 and ZT 800-207 in my latest presentations to remind
people of the usefulness of the architecture but it's clearly not always
enough.
On Mon, Oct 20, 2025 at 2:41 AM Lombardo, Jeff via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:
> 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>
> *Date: *Tuesday, 14 October 2025 at 12:20
> *To: *wimse at ietf.org <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>
> *Fecha: *miércoles, 1 de octubre de 2025, 12:04
> *Para: *wimse at ietf.org <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
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
--
---
David Brossard
http://www.linkedin.com/in/davidbrossard
http://twitter.com/davidjbrossard
http://about.me/brossard
---
Stay safe on the Internet: IC3 Prevention Tips
<https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
Prenez vos précautions sur Internet:
https://cyber.gouv.fr/bonnes-pratiques-protegez-vous
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20251020/3f3aa4b0/attachment-0001.htm>
More information about the Openid-specs-authzen
mailing list