[OAUTH-WG] For review/discussion: externalizing the token issuance decision to a policy decision point

[Omri Gazitt <[e-mail]>]

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: <[e-mail]>
Date: Tue, Aug 4, 2026 at 11:05 PM
Subject: New Version Notification for
draft-gazitt-oauth-authzen-issuance-00.txt
To: Omri Gazitt <[e-mail]>


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