[OAUTH-WG] For review/discussion: where an AS gets the authorization claims RFC 9068 recommends

[Omri Gazitt <[e-mail]>]

Hi folks,

RFC 9068 Section 2.2.3.1
<https://www.rfc-editor.org/info/rfc9068/#section-2.2.3.1> recommends that
an authorization server placing group memberships, roles or entitlements in
a JWT access token draw them from the SCIM user schema, and registers groups,
roles and entitlements as JWT claims. It says what they're called and how
they're encoded. It doesn't say where the authorization server gets them.

In deployments today, they come from a directory, a database or a
vendor-specific hook. What each of them answers is an authorization
question, but there isn't a standard way to ask it.

I've posted a draft
<https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-claims/> that
profiles the Resource Search
<https://openid.net/specs/authorization-api-1_0-final.html#name-resource-search-api>
API of OpenID AuthZEN for that step. It binds each claim to a search,
defines how a result set becomes a claim value, and registers the three
bindings RFC 9068 already names.

It's a companion to the two drafts I posted
<https://mailarchive.ietf.org/arch/msg/oauth/O0DUaMCsgRzFRkieDrUez1p7M_4/>
here on August 4, and it doesn't depend on them. Enrichment is a different
decision from issuance, and the draft is strict about keeping them apart: a
search result may populate a claim, and may never influence whether a token
is issued or what authority it conveys. An AS that wants to externalize
claim enrichment and nothing else can apply this on its own.

Two things I'd like feedback on:

   1. *That separation.* A failed or empty search changes which claims
   appear in the token, never whether the token is issued. If there's a
   legitimate case for an enrichment result feeding back into the issuance
   decision, the layering is wrong and I'd rather hear it now.
   2. *Whether the bindings deserve an IANA registry.* The draft asks for
   one recording, per claim, the resource type and action name of the search
   that enumerates it. The alternative is to leave that to deployment
   configuration. The registry exists so an unconfigured authorization server
   and policy decision point interoperate on the three claims RFC 9068 already
   names, and I'm not certain that's worth a registry.

[As in my earlier post: in full disclosure, I am a former co-chair of the
OpenID AuthZEN working group and an editor of the Authorization API, and
have been thinking about how to align the AuthZEN and OAuth ecosystems.]

Thanks in advance for your feedback!

Omri.
--
Omri Gazitt

---------- Forwarded message ---------
From: <[e-mail]>
Date: Fri, Aug 14, 2026 at 12:00 PM
Subject: New Version Notification for
draft-gazitt-oauth-authzen-claims-00.txt
To: Omri Gazitt <[e-mail]>


A new version of Internet-Draft draft-gazitt-oauth-authzen-claims-00.txt has
been successfully submitted by Omri Gazitt and posted to the
IETF repository.

Name:     draft-gazitt-oauth-authzen-claims
Revision: 00
Title:    AuthZEN Profile for Authorization Claims in JWT Access Tokens
Date:     2026-08-14
Group:    Individual Submission
Pages:    23
URL:
https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-claims-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-claims/
HTML:
https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-claims-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-claims


Abstract:

   RFC 9068 recommends that an authorization server placing group
   memberships, roles, or entitlements in a JWT access token draw those
   claims from the SCIM user schema.  It says what the claims are named
   and how their values are encoded, and it does not say where an
   authorization server obtains them.  In deployments today they come
   from a directory, a database, or a vendor-specific hook, and the
   question they answer is an authorization question asked of something
   that is not the authorization system.

   This document profiles the Resource Search API of the OpenID AuthZEN
   Authorization API for that purpose.  It binds each authorization
   claim to a search, defines how a search result set becomes a claim
   value, and requires that a search result never influence whether a
   token is issued or what authority it conveys.  It may be applied on
   its own, by an authorization server that externalizes claim
   enrichment but not its issuance decision, or alongside the companion
   framework document that externalizes the decision.



The IETF Secretariat