Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9341212A00E80 for ; Fri, 14 Aug 2026 12:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786734934; bh=oDiCGEnNK/xuuHfshnETDXoOH/Bu+YWsF1LS7fC+I/o=; h=References:In-Reply-To:From:Date:Subject:To; b=D5yCu9FrICF7lIb1OJtwf/UuCmKQG4QyXhiKRMtKxts0CcigHSfO13od5NfmuUQ9M fTyc8og0F433p/QXzFUiB4tZNLKT0nxB3bdzaQAmmbPs/FaB7UJdTmM/F0wkVaH0WY RkW4yWuCdTjH8aPA6XrAx/BNKVTBYuGPdY3+ieoA= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6Y97pkvpvUG for ; Fri, 14 Aug 2026 12:15:33 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id DD6E512A00E77 for ; Fri, 14 Aug 2026 12:15:33 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-930f618435cso79701785a.3 for ; Fri, 14 Aug 2026 12:15:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786734927; cv=none; d=google.com; s=arc-20260327; b=A0oCmQk473+yozImpqepFmWfnKpvtQa6jo3bMSRj1IeUr1d7RsR/V3X59F0c6R5K6A 4huSupAnaLPlg4czmfZEy76JX4K+pXZULubYiDWvOpVZubPHBQqviQ8oHxz4XOMu0QAT ma29tkDizplC68wcK/AWlYkAzwZHLkBufszh/SJlcDwG7ROPHA4wqxe8dSh1E5TyGwmg Mpe1eqZhHutQxcFPVx9vM9jH74aWxWEsO47l1NAYSa/WSpra3pMn7r3UXdr1stg+UFaL bKHYA5kd8wW0DYbdy4hjLbaKi05lX9/l3JoTXzmF4pWfZR3GK5V0HKBfpO4jtXMy+zke 0CLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=+Xj/oTp8tM6hAhOrGQSeoB/Cv0358ds6ktW3vokY1FA=; fh=4hvm/odsAU8m+5w3Y68HR6FKRzlFMwEVjOTXR/i1AsA=; b=LKfFap+TIYOyhxiwAyevKFTSEESN58MqVezjziKIARL/WlXfHtKY8PmscLBusjYOEd GoeZs4CnuTNnGqqbuScqxXKTqfggyv35cj/jpaoWfGgtPNBKiEnr5VxCsOEwp51kyQIs N07KzCbJfD0VM+vHysBLOW2qHxIg9yAU5roBGu92uogskkIVrZVJEFlsi/pvz+cY/3NW 4Ogw7n2wLtQWJxIdx3lGxiu1z/ozILeeJsi/Pq/xSX0xedksa75S2/c9LiS35LQJQde1 VDYZCLPcaQ/f18z+bjF9Up5roJUVcKlAdz8ayDfPr46IJflawQT+OC7DludIRnfyuoza KY+w==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786734927; x=1787339727; darn=ietf.org; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+Xj/oTp8tM6hAhOrGQSeoB/Cv0358ds6ktW3vokY1FA=; b=UMU3ExkaO1ITLagd3vfe3AKwnMi2MiA4E3OuTrV6pQKWlIm361ZpG6NNK47yOSp1D9 DeCKZzSWxNM/gpx55Y0hHvvsvpG+KsM/9mu3tburRqnNJjhwkB7ay1XMjhJCM3JlUCOZ aFP5p2sSessONMUWafVewUU0JuTXf5JJUvbQBdnRzMYTTjI5HQaBTN42SpDpq/tBLOsy 9+V5mql6nd9CY1zcgdbOIVKqN/mB7sRBcSxodk5tyA+ASFhEnT2FYi59GZd6H/eK42Vm 0tEmWTK1TFyuufUWrGeIZSUpPVBuS6xdY7NAfVEMwThYQYM1cEfif2AvmPIHsFc6ELf6 vuMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786734927; x=1787339727; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+Xj/oTp8tM6hAhOrGQSeoB/Cv0358ds6ktW3vokY1FA=; b=gZStxkPpTww/aEr10FMzTpHPIBJR4K9auwnQF549zxJWQZ/23hfDjo+9LjrznZ9McH gHiGG5ssWUMEfP0JXPJ6gZ8tLtdYLsjHjKxxeubxCsE5TOGC/jRje1+q8Yza4WnNIs25 CjNN+M1ly7XXLy3ROqRMrMRP9gxZtaNtB3+EUS8lnkhornYtiLAAQv3R+x2abtlSogaJ SjgjPpBHfzdoV1ZI2C4438Mpb4KQlvkXPJ3TLsxwwfxTTyVieSi7WujmFWgz9uyzw/L2 F4ZXzo71tBuUaFOaIrUXufO0DsvjWcfhj/Rkoa7+OzzORNQC2AOwN5lX+C2csAOgcLCY wkCw== X-Gm-Message-State: AOJu0YzQVWjGBiXSu1t7dSkW27fys6pa4xafhB7ePIcFhEZX+lza6X/i ubgKODSMrrZre2HJC69PRCfvau+UcqlullgX2CmGzkBH88ykE+ctZIm5Iogj8ImRrZDfwrsO6u2 4T9RPuyKhmkFfvLQJGjHwCQa07txyQBGz9HnE X-Gm-Gg: AR+sD125YJnAT3qVm4KdTz0F1OJ/iRq+JluS8HyCPjq0G9OoD8mpZBqL7Ry92AfVT9C pOm+hVgpINnYq1KrRXQyS8Pc5eo5i5tBwnOo4cUVtfcwcQrLNq5AAAVO7bSq4DM/rfzqZnQdt9t /8RRFWejh82WZquYBOLfUvCcuBn2DG9qQGpmfakqdUhaGekjpR3jrG01DzaMnuodD5Cio35nQFZ wwqLnMmrEHoeCWk/jsYQZRsjASaMZ3wgkdVMPPBQ2KLzv7t2Bc/tpchqfBT7wZGVK74SJltGGsZ DnEg4KYxTS+CaLndHh/qjvybxPm2NxO74KjRlChilj/nUvLw/QGAzF8q8C3lkdxJsyxD4BdQG1R WyjHqxbK0EffPWT+hzeyxZBSk53DiTN4mA+fbT1LG9KpLuf/4oNTPV8+ZEvk= X-Received: by 2002:a05:620a:211a:b0:936:af32:aea8 with SMTP id af79cd13be357-936d22cf7d2mr760095085a.31.1786734926667; Fri, 14 Aug 2026 12:15:26 -0700 (PDT) MIME-Version: 1.0 References: <178673402378.97581.9115037488034740847@dt-datatracker-7c6ddbc678-lb5nk> In-Reply-To: <178673402378.97581.9115037488034740847@dt-datatracker-7c6ddbc678-lb5nk> From: Omri Gazitt Date: Fri, 14 Aug 2026 12:15:15 -0700 X-Gm-Features: AUfX_my9Fa72SumScZzA28NcKUjTVyTuPz1nNbOr7_N8M76i-ORgUZP-zOgCSXk Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000009ca3fb065906a451" Message-ID-Hash: FK24AIPG3ZAM72GYQPEHP5MCXPQAPRTY X-Message-ID-Hash: FK24AIPG3ZAM72GYQPEHP5MCXPQAPRTY X-MailFrom: ogazitt@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_For_review/discussion=3A_where_an_AS_gets_the_autho?= =?utf-8?q?rization_claims_RFC_9068_recommends?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009ca3fb065906a451 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 group= s, 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 searc= h that enumerates it. The alternative is to leave that to deployment configuration. The registry exists so an unconfigured authorization serv= er and policy decision point interoperate on the three claims RFC 9068 alre= ady 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=E2=80=AFPM 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 ha= s 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 --0000000000009ca3fb065906a451 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi fo= lks,

RFC 9068 Section 2.2.3= .1 recommends that an authorization server placing group memberships, r= oles or entitlements in a JWT access token draw them from the SCIM user sch= ema, and registers groups, roles and entitlem= ents as JWT cla= ims. It says what they're called and how they're encoded. It doesn&= #39;t say where the authorization server gets them.

In deployments t= oday, they come from a directory, a database or a vendor-specific hook. Wha= t 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, defin= es how a result set becomes a claim value, and registers the three bindings= RFC 9068 already names.

It's a compa= nion to the two drafts I posted here on August 4, and it does= n't depend on them. Enrichment is a different decision from issuance, a= nd the draft is strict about keeping them apart: a search result may popula= te a claim, and may never influence whether a token is issued or what autho= rity it conveys. An AS that wants to externalize claim enrichment and nothi= ng 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 th= e token, never whether the token is issued. If there's a legitimate cas= e for an enrichment result feeding back into the issuance decision, the lay= ering is wrong and I'd rather hear it now.
  2. Whet= her the bindings deserve an IANA registry. The draft asks for one recor= ding, per claim, the resource type and action name of the search that enume= rates it. The alternative is to leave that to deployment configuration. The= registry exists so an unconfigured authorization server and policy decisio= n point interoperate on the three claims RFC 9068 already names, and I'= m not certain that's worth a registry.

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

Thanks in advanc= e for your=C2=A0feedback!

Omri.

=
--
Omri Gazitt

---------- Forwarded message ---------
From: <internet-drafts@ietf.org><= /span>
Date: Fri, Aug 14, 2026 at 12:00=E2=80=AFPM
Subject: New Versi= on Notification for draft-gazitt-oauth-authzen-claims-00.txt
To: Omri Ga= zitt <ogazitt@gmail.com>
=


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

Name:=C2=A0 =C2=A0 =C2=A0draft-gazitt-oauth-authzen-claims
Revision: 00
Title:=C2=A0 =C2=A0 AuthZEN Profile for Authorization Claims in JWT Access = Tokens
Date:=C2=A0 =C2=A0 =C2=A02026-08-14
Group:=C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 23
URL:=C2=A0 =C2=A0 =C2=A0 htt= ps://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-claims-00.txt Status:=C2=A0 =C2=A0https://datat= racker.ietf.org/doc/draft-gazitt-oauth-authzen-claims/
HTML:=C2=A0 =C2=A0 =C2=A0ht= tps://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:

=C2=A0 =C2=A0RFC 9068 recommends that an authorization server placing group=
=C2=A0 =C2=A0memberships, roles, or entitlements in a JWT access token draw= those
=C2=A0 =C2=A0claims from the SCIM user schema.=C2=A0 It says what the claim= s are named
=C2=A0 =C2=A0and how their values are encoded, and it does not say where an=
=C2=A0 =C2=A0authorization server obtains them.=C2=A0 In deployments today = they come
=C2=A0 =C2=A0from a directory, a database, or a vendor-specific hook, and t= he
=C2=A0 =C2=A0question they answer is an authorization question asked of som= ething
=C2=A0 =C2=A0that is not the authorization system.

=C2=A0 =C2=A0This document profiles the Resource Search API of the OpenID A= uthZEN
=C2=A0 =C2=A0Authorization API for that purpose.=C2=A0 It binds each author= ization
=C2=A0 =C2=A0claim to a search, defines how a search result set becomes a c= laim
=C2=A0 =C2=A0value, and requires that a search result never influence wheth= er a
=C2=A0 =C2=A0token is issued or what authority it conveys.=C2=A0 It may be = applied on
=C2=A0 =C2=A0its own, by an authorization server that externalizes claim =C2=A0 =C2=A0enrichment but not its issuance decision, or alongside the com= panion
=C2=A0 =C2=A0framework document that externalizes the decision.



The IETF Secretariat


--0000000000009ca3fb065906a451--