Hi Lucía, Thank you for the pointers and feedback! Implementation experience is exactly what I was hoping these drafts would draw out, and yours is more directly on point than anything I've found so far.
I did know about Thomas Darimont's work (his deck references Open Policy Containers <https://openpolicycontainers.com/> and Topaz <https://www.topaz.sh/>, two technologies that I was involved with creating). But I didn't know that it had progressed into the deployments you cite. The ROBUST-6G and iTrust6G write-ups are the useful part for me, because they are evidence that this seam is being filled in the field rather than in demos. Your `kck.rego` is a good illustration of what the drafts try to generalize. The condition that decides the case is `isGrantType(...)`, and the grant type reaches the policy as a free-form attribute inside `context`. That means both sides have to agree where to find the important fields that determine how to make the decision. In the AuthZEN profile those fields go into specific parts of the AuthZEN payload; in particular, the grant type and the token type compose a named action. This also means a PDP can be indexed on it, and can enumerate what it is prepared to decide through the Action Search API, rather than each deployment inventing an attribute name and each policy hardcoding a realm. That is the essence of the proposal: generalize the extension point for deciding whether to issue a token, and how to shape it, onto OpenID AuthZEN 1.0. The drafts define the mapping from the decision-critical inputs - subject, audience, grant type and token type - onto AuthZEN's subject, action, resource and context model, and the rules by which a decision may shape the outgoing token. The point of the mapping is that it is agnostic to the engine behind it. AuthZEN is implementable over OPA, Zanzibar, Topaz, XACML or any of the other ~20 open source or proprietary PDPs, which we have demonstrated <https://authzen-interop.net/docs/intro#policy-decision-points> across seven interop events. There is a detail here that may interest this group. Keycloak shipped <https://www.keycloak.org/2026/05/authzen-as-experimental-feature> experimental AuthZEN support in 26.7.0, but in the PDP role: it serves the Evaluation and Evaluations APIs so that external enforcement points can ask Keycloak about resource access. These drafts ask for the mirror image, Keycloak as a policy enforcement point calling out at issuance. Same API, opposite direction. That is the unification I think is worth having: the decision at token issuance and the decision at resource access both have policy behind them, and today they are asked in two different ways. I'd love to go deeper on this. An implementation report is the most valuable thing an individual draft can attract, and if the Telefónica work could be held up against the mapping in the drafts, including where it does not fit, that would carry more weight on this list than anything I can argue in the abstract. Thanks, Omri -- Omri Gazitt On Wed, Aug 5, 2026 at 4:25 AM LUCIA CABANILLAS RODRIGUEZ < [email protected]> wrote: > Hi Omri, > > I have worked extensively on implementations where Keycloak externalizes > authorization decisions to an external PDP, specifically Open Policy Agent > (OPA), so I found your proposal particularly interesting. > > For reference, below is an example of integration between Keycloak and OPA > that illustrates how token issuance decisions can be delegated to an > external policy engine: > https://github.com/tefiros/keycloak-opa-authz-demo/tree/main > > I am also including an example Rego policy: > https://github.com/tefiros/Access-control-helm/blob/develop/test/kck.rego > > This policy illustrates how issuance decisions can be enforced externally. > For example, it can deny token issuance when specific conditions are not > met, such as requiring the use of OpenID Connect before a token can be > returned. > > We have also documented this approach in research projects where Keycloak > interacts with an external PDP: > > - > - > https://robust-6g.eu/wp-content/uploads/2026/05/ROBUST-6G-D2.3_v1.0.pdf > (Section 5.1.2.4) > - > https://www.sns-itrust6g.com/wp-content/uploads/2026/05/iTrust6G-D4.2.pdf > (Section 4.1.2) > - > > These references may be useful as implementation experience for the > discussion around externalizing token issuance decisions and the practical > integration of OAuth/OIDC infrastructures with external policy engines. > > If this is of interest, I would be happy to discuss it in more detail. It > could be an interesting topic to continue exploring in future IETF meetings > and discussions, or perhaps through collaborations as well. > > Best regards, > Lucía > *De: *Omri Gazitt <[email protected]> > *Fecha: *miércoles, 5 de agosto de 2026 a las 8:40 > *Para: *[email protected] <[email protected]> > *Asunto: *[OAUTH-WG] For review/discussion: externalizing the token > issuance decision to a policy decision point > > *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 folks, > > Yaron Sheffer's thread > <https://mailarchive.ietf.org/arch/msg/oauth/CCvvii3fjQWYczpYgzVC2Aoa9-U/> in > June/July on standardizing a policy language framed the question as one > about scope: whether authorization policy, kept out of OAuth's scope for > years, is due for a revisit. That thread took up policy on the OAuth wire. > I have submitted two drafts about the other half of it, policy behind the > wire, which I don't think has been discussed here much if at all. > > It also sidesteps the hardest part of Yaron's question. Agreeing on how an > authorization server poses the question does not require agreeing on the > language the policy is written in, and OpenID AuthZEN 1.0 already defines > how to structure the question. [In full disclosure, I am a former co-chair > of the OpenID AuthZEN working group and an editor of the Authorization API.] > > The observation the drafts start from is that a long list of OAuth > specifications define a moment at which an authorization server decides > whether to issue a token, and every one of them declines to define the > decision. Transaction Tokens is the bluntest about it: "the authorization > policy for determining such issuance is out of scope for this > specification." RFC 8693 and Identity Chaining each do the same thing in a > subordinate clause. ID-JAG gets closest, and describes an interface in > prose: the AS "evaluates administrator-defined policy [...] and determines > if the client should be granted access to act on behalf of the subject for > the target audience, resources, scopes, and authorization details," and > adds that granted scopes may be a subset of those requested. > > Each of those is the right editorial call for the document it appears in. > My observation is only that the same call made four times leaves the most > security-relevant step in issuance with no interoperable expression, and > that the industry has needed to fill this gap: five major authorization > servers ship a proprietary extension point at exactly this moment, and only > one of the five can refuse to issue. > > The drafts profile the OpenID AuthZEN Authorization API for that moment, > casting the AS as a policy enforcement point: > > - AuthZEN Profile for OAuth 2.0 Token Issuance > <https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/> - > the mapping from a token request onto AuthZEN's five-tuple, and the rules > by which a decision may shape the issued token. §4 covers the deployment > question of whether an authorization server can afford a policy call at > issuance rates. > - AuthZEN Binding for OAuth 2.0 Token Exchange > > <https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-token-exchange/> > - > the binding for RFC 8693 and the family that inherits its seam: identity > chaining, ID-JAG and transaction tokens, where a request names a second > party whose authority is separately at stake. > > Nothing here changes anything on the OAuth wire. A client cannot tell > whether the AS consulted a policy decision point, and no new parameter, > endpoint or error code is defined. That is deliberate, and it is also the > crux of question 1 below. > > Open questions. These are also filed as issues here > <https://github.com/ogazitt/oauth-authzen/issues> if a reply is easier > there than on the list, though I would rather have it here. > > 1. *Is this in scope for OAuth at all?* Because the profile is > invisible on the wire, there is a real argument that it belongs at the > OpenID Foundation as an AuthZEN profile, and I have had that feedback > directly. The counter is that the sentences being filled in are in this > working group's documents, and its participants are the ones who wrote > them. Question 2 is the sharpest version of this: whatever the answer is, > it is not one the OpenID Foundation can give. I would rather ask than > assume. > > 2. *What should an AS return when policy refuses?* I could not find > a consistent answer, and I would like to be told I missed one. RFC > 8693 section 2.2.2 says `invalid_request` where the presented tokens are > unacceptable on policy grounds. Identity Chaining points at RFC 7523 > section 3.1, whose own MUST is about JWT validity rather than policy, and > which lands on `invalid_grant`. ID-JAG and Transaction Tokens describe the > permit branch and leave the deny branch unwritten. If the answer is that > `invalid_grant` is the understood catch-all and the coarseness is > deliberate, that is a fine answer, and I would rather write it down than > have a profile invent something. > > 3. *Is a new IANA registry the right way to name the gate action?* It is > currently `issue:<token-type>:<grant-type>` built from registered > short names, in a new registry, rather than from the existing grant type > URIs. The reason is that policy engines have real length and > character constraints on relation identifiers, but I am not confident this > is the right trade and it is the kind of naming call this working group > is better at than I am. > > 4. *Is "may narrow, never broaden" the right invariant for the response?* > (section > 6.3 of the issuance draft, and the rule I would most like challenged.) A > decision may shorten a lifetime, drop scopes or tighten an audience, and > may never add authority. Everything else in the response handling falls out > of it, including which fields an implementation may ignore. If there is a > legitimate case for a policy decision point adding authority at issuance, > the design is wrong and I would like to hear it now. > > There is a longer write-up <https://notes.ogazitt.com> of the argument, > including the survey behind the five-vendor claim above. Next steps include > implementing the drafts with a Keycloak module rather than leave them on > paper, and would take that work in whichever direction the answer to > question 1 points. > > Thanks! > Omri. > > -- > Omri Gazitt > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Tue, Aug 4, 2026 at 11:05 PM > Subject: New Version Notification for > draft-gazitt-oauth-authzen-issuance-00.txt > To: Omri Gazitt <[email protected]> > > > A new version of Internet-Draft draft-gazitt-oauth-authzen-issuance-00.txt > has > been successfully submitted by Omri Gazitt and posted to the > IETF repository. > > Name: draft-gazitt-oauth-authzen-issuance > Revision: 00 > Title: AuthZEN Profile for OAuth 2.0 Token Issuance > Date: 2026-08-05 > Group: Individual Submission > Pages: 36 > URL: > https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/ > HTML: > https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-issuance > > > Abstract: > > Numerous OAuth 2.0 specifications define a moment at which an > authorization server decides whether to issue a security token, and > each of them declares the decision itself to be a matter of local > policy that is out of scope. The result is that a decision common to > every OAuth deployment has no interoperable expression. > > This document defines a profile for using the OpenID AuthZEN > Authorization API to externalize that decision to a Policy Decision > Point. It specifies how the inputs to a token issuance request map > onto AuthZEN's mandatory five-tuple, how a Policy Decision Point > response may shape the issued token, and how the two parties discover > each other's capabilities. > > The mapping is complete for grants whose request names a single party > and a single target, including the authorization code and client > credentials grants. Companion documents bind the grant families that > add structure this document does not model, the token exchange family > first among them. > > > > The IETF Secretariat > > > > ------------------------------ > > 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 > _______________________________________________ > 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]
