Hi folks, Yaron Sheffer's thread <https://mailarchive.ietf.org/arch/msg/oauth/CCvvii3fjQWYczpYgzVC2Aoa9-U/> in June/July on standardizing a policy language framed the question as one about scope: whether authorization policy, kept out of OAuth's scope for years, is due for a revisit. That thread took up policy on the OAuth wire. I have submitted two drafts about the other half of it, policy behind the wire, which I don't think has been discussed here much if at all.
It also sidesteps the hardest part of Yaron's question. Agreeing on how an authorization server poses the question does not require agreeing on the language the policy is written in, and OpenID AuthZEN 1.0 already defines how to structure the question. [In full disclosure, I am a former co-chair of the OpenID AuthZEN working group and an editor of the Authorization API.] The observation the drafts start from is that a long list of OAuth specifications define a moment at which an authorization server decides whether to issue a token, and every one of them declines to define the decision. Transaction Tokens is the bluntest about it: "the authorization policy for determining such issuance is out of scope for this specification." RFC 8693 and Identity Chaining each do the same thing in a subordinate clause. ID-JAG gets closest, and describes an interface in prose: the AS "evaluates administrator-defined policy [...] and determines if the client should be granted access to act on behalf of the subject for the target audience, resources, scopes, and authorization details," and adds that granted scopes may be a subset of those requested. Each of those is the right editorial call for the document it appears in. My observation is only that the same call made four times leaves the most security-relevant step in issuance with no interoperable expression, and that the industry has needed to fill this gap: five major authorization servers ship a proprietary extension point at exactly this moment, and only one of the five can refuse to issue. The drafts profile the OpenID AuthZEN Authorization API for that moment, casting the AS as a policy enforcement point: - AuthZEN Profile for OAuth 2.0 Token Issuance <https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/> - the mapping from a token request onto AuthZEN's five-tuple, and the rules by which a decision may shape the issued token. §4 covers the deployment question of whether an authorization server can afford a policy call at issuance rates. - AuthZEN Binding for OAuth 2.0 Token Exchange <https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-token-exchange/> - the binding for RFC 8693 and the family that inherits its seam: identity chaining, ID-JAG and transaction tokens, where a request names a second party whose authority is separately at stake. Nothing here changes anything on the OAuth wire. A client cannot tell whether the AS consulted a policy decision point, and no new parameter, endpoint or error code is defined. That is deliberate, and it is also the crux of question 1 below. Open questions. These are also filed as issues here <https://github.com/ogazitt/oauth-authzen/issues> if a reply is easier there than on the list, though I would rather have it here. 1. *Is this in scope for OAuth at all?* Because the profile is invisible on the wire, there is a real argument that it belongs at the OpenID Foundation as an AuthZEN profile, and I have had that feedback directly. The counter is that the sentences being filled in are in this working group's documents, and its participants are the ones who wrote them. Question 2 is the sharpest version of this: whatever the answer is, it is not one the OpenID Foundation can give. I would rather ask than assume. 2. *What should an AS return when policy refuses?* I could not find a consistent answer, and I would like to be told I missed one. RFC 8693 section 2.2.2 says `invalid_request` where the presented tokens are unacceptable on policy grounds. Identity Chaining points at RFC 7523 section 3.1, whose own MUST is about JWT validity rather than policy, and which lands on `invalid_grant`. ID-JAG and Transaction Tokens describe the permit branch and leave the deny branch unwritten. If the answer is that `invalid_grant` is the understood catch-all and the coarseness is deliberate, that is a fine answer, and I would rather write it down than have a profile invent something. 3. *Is a new IANA registry the right way to name the gate action?* It is currently `issue:<token-type>:<grant-type>` built from registered short names, in a new registry, rather than from the existing grant type URIs. The reason is that policy engines have real length and character constraints on relation identifiers, but I am not confident this is the right trade and it is the kind of naming call this working group is better at than I am. 4. *Is "may narrow, never broaden" the right invariant for the response?* (section 6.3 of the issuance draft, and the rule I would most like challenged.) A decision may shorten a lifetime, drop scopes or tighten an audience, and may never add authority. Everything else in the response handling falls out of it, including which fields an implementation may ignore. If there is a legitimate case for a policy decision point adding authority at issuance, the design is wrong and I would like to hear it now. There is a longer write-up <https://notes.ogazitt.com> of the argument, including the survey behind the five-vendor claim above. Next steps include implementing the drafts with a Keycloak module rather than leave them on paper, and would take that work in whichever direction the answer to question 1 points. Thanks! Omri. -- Omri Gazitt ---------- Forwarded message --------- From: <[email protected]> Date: Tue, Aug 4, 2026 at 11:05 PM Subject: New Version Notification for draft-gazitt-oauth-authzen-issuance-00.txt To: Omri Gazitt <[email protected]> A new version of Internet-Draft draft-gazitt-oauth-authzen-issuance-00.txt has been successfully submitted by Omri Gazitt and posted to the IETF repository. Name: draft-gazitt-oauth-authzen-issuance Revision: 00 Title: AuthZEN Profile for OAuth 2.0 Token Issuance Date: 2026-08-05 Group: Individual Submission Pages: 36 URL: https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.txt Status: https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/ HTML: https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-issuance Abstract: Numerous OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a security token, and each of them declares the decision itself to be a matter of local policy that is out of scope. The result is that a decision common to every OAuth deployment has no interoperable expression. This document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point. It specifies how the inputs to a token issuance request map onto AuthZEN's mandatory five-tuple, how a Policy Decision Point response may shape the issued token, and how the two parties discover each other's capabilities. The mapping is complete for grants whose request names a single party and a single target, including the authorization code and client credentials grants. Companion documents bind the grant families that add structure this document does not model, the token exchange family first among them. The IETF Secretariat
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
