Hi, Few comments:
I can offer a deployed data point from the other direction: an authorization server where the ceiling of the issuance decision is already externalized -- not to a PDP, but to a principal-signed artifact. This type of process is already standardized see RFC 9101 / JWT-Secured Authorization Request (JAR)<https://www.rfc-editor.org/rfc/rfc9101.html>. There is absolutely no need to create something new. Also this is not a ceiling, your proposal and RFC9101 are an integrity protected authorization request. A ceiling could be completely different: while an OAuth client can support “profile email openid Photos/Write Travel/Book” as allowed scope and the client effectively requesting “email Travel/Book” at authorization request, the AS logic might decide that the ceiling for this request as it comes from a non allowed IP should be limited to “openid Photos/Write Travel/Book” therefore resulting in “Travel/Book” for this request instance. This is exactly what a AS logic is for and what an externalized PDP can resolve at scale with dynamic, ephemeral, and risk-mitigating policies. the "may narrow, never broaden" invariant The principle has good faith and is generally accepted. Still can it always be resolved always as “equal or less”? is “equivalent” [different form equal] deterministic? 2 examples: * A got a “Photos/Write” scope to talk to B, B needs “Storage/WriteObject” scope to talk to C. * A got a “Travel/Plan” scope to talk to B, B needs “Boat/Book” scope to talk to C. draft-wei-aic-jwt-00 Again we have RFC 9101 / JWT-Secured Authorization Request (JAR)<https://www.rfc-editor.org/rfc/rfc9101.html> discussed and accepted as standard. So the ceiling in this model is not the AS's local policy and not a PDP verdict This ignores all the discussions about mandates and obligations which could be added as scopes to the issued tokens to perform actions the PDP requires, see: * Geroge Fletcher article: https://www.linkedin.com/pulse/task-its-bounds-obligations-constraints-line-between-them-fletcher-nvyce/?trackingId=5jAzSFXgT5uJ%2BhNx29xLoA%3D%3D * AuthZEN Profile for Obligations: https://openid.github.io/authzen/authzen-obligations-profile-1_0.html Jeff Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Stratégie de Sécurité Principal Solution Architect, Security Strategy Montréal, Canada From: Jijie Wei <[email protected]> Sent: September 4, 2026 7:41 AM To: oauth <[email protected]> Subject: [EXT] [OAUTH-WG] Re: For review/discussion: externalizing the token issuance decision to a policy decision point CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. Omri, Roland, Iman, all, The thread has converged on the ceiling question -- what bounds the issued token, who sets that bound, and whether a PDP may cross it. I can offer a deployed data point from the other direction: an authorization server where the ceiling of the issuance decision is already externalized -- not to a PDP, but to a principal-signed artifact. The AS remains the decision maker; what it may decide within is fixed by a signature rather than by a policy call. It lands squarely on the "may narrow, never broaden" invariant, and it may be a useful reference for the ceiling discussion. The model is specified in draft-wei-aic-jwt-00 (with the same data model in the X.509 profile, draft-wei-aic-identity-cert). At issuance the agent presents a Delegation Authorization (DA) -- a JWT signed by the principal's own key -- via the RFC 7523 jwt-bearer grant. The authorization server validates that DA (principal signature, nonce uniqueness, and that the requested capabilities are a subset, capability-level and parameter-level, of what the principal signed) and only then signs the outer token. The spec states the bound directly: the AS MUST NOT sign the outer token without a valid principal-signed DA (Section 10.2). So the ceiling in this model is not the AS's local policy and not a PDP verdict -- it is established by the principal's signature, and it is closed cryptographically rather than configurationally. The AS may issue a subset of the signed grant and may shorten the lifetime (we clip to min(requested, cap), with a one-hour deployment default and a fixed 24-hour ceiling), but it cannot add authority the principal did not sign. A PDP, where one is present, chooses within that principal-signed ceiling; it never widens it. That is the same ceiling-versus-recommendation split Iman describes, with the ceiling anchored one step earlier -- at the principal's key rather than at the AS's grant validation. Two points that may matter for the profile's open questions: * On affordability at issuance rates (Section 4 of the issuance draft): this decision is a local signature verification plus a nonce lookup, not an external round trip. In our deployment it measures in the low microseconds per issuance at the engine level, with sustained issuance in the several-thousand-certificates-per- second range under tuned conditions. A closed, signature-defined ceiling is cheap to enforce at issuance rates; the cost question is really about the PDP call, which this arrangement keeps off the critical issuance path. * On the token-exchange binding: our Section 10.4 uses RFC 8693 and requires the exchanged token to carry the intersection of the actor's capabilities with the subject's grants -- the same narrowing invariant applied at exchange time, across the seam your exchange draft targets. We have the X.509-to-JWT bridge path implemented and the full subject/actor exchange specified, and I would be glad to compare notes on the intersection semantics. The profile is also graded rather than all-or-nothing, which may matter for the "is this in scope / who needs it" question: a lightweight consumer deployment can omit the DA entirely and let the AS sign directly from recorded consent, while an enterprise deployment pins the ceiling to the principal's signature. Same wire shape, different placement of the decision. Happy to elaborate on the validation sequence or the subset semantics on-list or off-list, whichever is more useful. Best, Jijie Wei
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
