Omri, Your first and third points are as I meant them. Let me restate the second, since that is the one that did not land.
You are right that an RS consuming a token already trusts the issuer. My point is narrower: that trust covers the AS's own assertions, not the AS's account of a third party's state at a past instant. When the AS says "roles = [x, y] as of 14:02," it is making two different kinds of claim in one artifact. The first is authoritative because the AS issued it. The second is an assertion about what an upstream directory contained at a time only the AS observed, and the AS is the party whose caching, staleness, and propagation behavior the RS is trying to evaluate. Trusting the issuer does not make it a witness to its own freshness. So the mechanism I would want is not a competing trust model. It is evidence that survives independent verification: 1. The authoritative directory signs the membership snapshot it served - subject, tenant, claim set, and its own read cursor or ETag - under ECDSA P-384 or ML-DSA-65. The AS relays that signed object, or a digest of it, as a claim rather than paraphrasing its contents. 2. Existence-at-a-time is established by an RFC 3161 timestamp token over the SHA-384 digest of that signed snapshot, from a TSA that neither the AS nor the RS operates. That converts "the AS says it read at 14:02" into "a third party attests this exact snapshot existed no later than 14:02." 3. The RS then evaluates two separable things: whether the snapshot is authentic and in-tenant, and whether its timestamp falls inside the RS's own freshness policy for the operation at hand. Neither step requires trusting the AS's self-report, and an AS that served a cached value is now visibly serving an old snapshot rather than being indistinguishable from one that did not. The cost is honest: the directory has to sign, and most do not today. But the alternative is a wire format in which a fresh authoritative read and a value copied out of an upstream token look identical, which is the gap your draft correctly identifies. I would rather the document state the requirement and let deployments meet it incrementally than register a freshness claim that cannot carry the weight implementers will put on it. This is the same shape as the requirement Morgan and Mohamad converged on in the mandates thread: establish the as-of state without trusting the party that held it. A cross-reference between the two documents would be worth it, whichever lands first. On tenancy: the snapshot must bind the tenant identifier inside the signed object, not alongside it. A roles claim that is correct for tenant A and replayed against tenant B is the specific multi-tenant failure I have had to defend against in practice. Happy to share the resolver-side verification logic and interop notes; they live in a private Sanctum SecOps collaboration repo and I can grant read access on request. Brian Vicente Founding Principal and Architect Sanctum SecOps LLC www.sanctumsecops.com On Thursday, August 27, 2026 at 10:19 PM UTC, [email protected] wrote: Hi Brian, Thanks for taking the time to review the draft and for your feedback! Let me see if I fully understand your points: - a resource server may want to understand which upstream system is the source of truth for group/role/entitlement claims (i.e. provenance) before deciding to "trust" those claims - there needs to be a way to communicate when the membership information was extracted from the upstream system (and you shouldn't trust the AS to assert that information) - tenancy needs to be baked into the model I agree with you that there may be value in communicating which upstream system the group/role/entitlement information came from, and when it was extracted. However, I'm not sure whether I understand your second point about "a claim by the party whose behavior is in question". If I follow your argument, the AS may not be a trustworthy source of those claims. But today, a resource server that examines a token issued by an authorization server has an inherent trust relationship with that issuer, and I'm not sure that creating a different (or additional) trust model mechanism makes sense. Did I understand you correctly? And what type of mechanism would you suggest for the provenance and timing information? With respect to tenancy, I agree this is an interesting consideration; I left it out because RFC 9068 doesn't address it (since it only references SCIM: Schema - RFC 7643). SCIM: Protocol (RFC 7644) mentions multi-tenancy as optional, and rather than defining a specific scheme, it suggests using URL paths, subdomains, or HTTP headers for selecting tenants, as opposed to adding tenancy into the schema. With that said, ID-JAG and the OIDC Enterprise Extensions do take on claims related to tenancy, so it may be worth referring to those specs as opposed to defining something new. Do you have a specific mechanism in mind for communicating tenancy from the PEP (AS) to the PDP, and how tenancy would be communicated back? Thanks, Omri. -- Omri Gazitt On Wed, Aug 26, 2026 at 3:45 PM Brian Vicente > wrote: 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]
