An official home for the AuthZEN OAuth issuance profile family

On August 27 the OpenID AuthZEN working group voted to adopt all three of these drafts, and as of this week they live in the working group’s repository rather than in mine:

• AuthZEN Profile for OAuth 2.0 Token Issuance
• AuthZEN Binding for OAuth 2.0 Token Exchange
• AuthZEN Profile for Authorization Claims in JWT Access Tokens

The draft-gazitt-* Internet-Drafts stay on the datatracker as the lineage, and each document says which one it continues. Adoption is the part where they stop being mine, which is the point of it.

So why did this work end up at the OpenID Foundation and not at the IETF OAuth working group? After all, that’s where I submitted the individual drafts. Here’s how I think about the tradeoffs.

The case for the OAuth working group

The authorization server is the policy enforcement point. Every normative requirement in the framework document tells the AS how to construct the request and how to process the response: form this batch, apply these reductions first, treat a denied gate this way, never broaden.

So the people who would build this are AS implementers, and AS implementers tend to hang out on oauth@ietf.org. At the very least, the work needs to be visible to them, but they’re also the group that would have the most concrete feedback on the spec.

Of course, policy writers are the other half of the audience - for this architectural separation to have any value, there needs to be an ecosystem of PDPs which can answer the issuance question using an issuance policy written in that PDP’s policy language. But that part is easier, and without AS adoption, the whole thing is moot.

The case for the OpenID Foundation

Nothing in these documents changes an octet on the OAuth wire. Whether an AS uses a PDP as part of token issuance is an implementation detail that an OAuth client doesn’t know or care about.

Ultimately, this is a profile of the AuthZEN spec, and the OIDF AuthZEN working group has the largest audience of folks that care about creating an interoperable contract for token issuance.

What actually decided it

The OAuth WG is busy with about 90 active I-Ds, so this work would need to be important enough to that community to warrant spending WG time on it. Rather than assuming, I put the venue question to the OAuth working group in my messages to the list, and while I got some feedback there (and from other places) that identity provider writers would be interested in collaborating on this, there simply wasn’t the level of interest which would justify the WG prioritizing this work.

By contrast, there was significant interest in the AuthZEN WG to carry this forward, especially since we laid the groundwork for it in the December 2025 interop event at Gartner IAM.

What’s next

Now that the AuthZEN WG is the proper home of this work, there’s a fair amount of feedback to go through and incorporate. My hope is that we can get these documents to an implementer’s draft in time for an interop event in early 2027.

And of course, issues and pull requests are welcome in the working group repository.