Hi, I think you have identified a real gap and I would support work on it.
RFC 9068 Section 2.2.3.1 tells an authorization server to draw group memberships, roles, and entitlements from the SCIM user schema and registers the claims, but it is silent on provenance: how the AS obtains those values, how freshness is established, and what a resource server may assume about them. In multi-tenant deployments that silence is where the security properties actually get decided. Three requirements I would want any such document to state: 1. Provenance must be expressible. A resource server consuming a roles claim cannot today distinguish a value the AS read from an authoritative directory at authorization time from a value cached at session establishment or copied from an upstream token. Those have different revocation behavior and should not be indistinguishable on the wire. 2. As-of state must be establishable without trusting the holder. A timestamp asserting when the AS read the directory is not a mechanism for that; it is a claim by the party whose behavior is in question. This is the same problem the mandates thread is working through from the other end. 3. Tenant scoping must be explicit. In brokered and multi-tenant topologies the same group name means different things per tenant, and unqualified group claims flatten that distinction. We hit this directly in tenant-isolated PKI and identity work. I am glad to co-author or to contribute the multi-tenant requirements section if you take this forward. On Friday, August 14, 2026 at 7:18 PM UTC, [email protected] wrote: Hi folks, RFC 9068 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 that profiles the Resource Search 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 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: > Date: Fri, Aug 14, 2026 at 12:00 PM Subject: New Version Notification for draft-gazitt-oauth-authzen-claims-00.txt To: Omri Gazitt > 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]
