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: <[email protected]> Date: Fri, Aug 14, 2026 at 12:00 PM Subject: New Version Notification for draft-gazitt-oauth-authzen-claims-00.txt To: Omri Gazitt <[email protected]> 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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
