Hi Aaron and Karl, Thanks for your answers. Sounds to me like we are on the same page.
Since the current processing rules focus on the ID-JAG, I got confused by the last bullet point: > The Resource Authorization Server MUST follow Section 3.3 of [RFC6749] when processing the scope claim. I read this line like "The Resource Authorization Server MUST process the scope claim as described in Section 3.3 of RFC6749" which I now understand is not what you mean. I suggest to rephrase the processing rules and in addition to section 3.3 of RFC6749 and section 5.2 of RFC7521 also include section 4.1 of RFC7521. Maybe divide the list into verifying the ID-JAG (syntax) and understanding the semantics of a request. I think section 3.3 of RFC6749 and section 4.1 of RFC7521 are important for the semantic. I personally like that section 4.1 of RFC7521 clearly states that the scope of the access token must be equal or less than the scope of the grant. That section also gives guidelines regarding the token lifetime and the issuance of the refresh token which I found helpful. Again, thanks for getting back to me and confirming my perception. Regards, Judith On Fri, Dec 5, 2025, 18:08 Karl McGuinness <[email protected]> wrote: > This is a key reason why we selected JWT Authorization Grant and not JWT > Profile for Access Token for cross-domain access. We wanted the Resource > AS to have complete control over the access tokens issued for its resources > including claims, scopes, and lifetime and decouple resource servers from > cross-domain concerns. The role of the Enterprise IdP in this > specification is to authorize whether a given client from one domain can > act as a managed enterprise user for a set of scope for a resource in > another domain. Just like with traditional IdP user federation the > relying party is always responsible for validating claims and > applying local policy for the federated user as it owns its app's session. > This is the nature of federation and claims processing and why we wanted to > allow the ID-JAG to contain identity, authentication, & authorization > claims so the Resource AS had as much evidence as possible to make local > decisions. > > -Karl > > On Fri, Dec 5, 2025 at 8:16 AM Aaron Parecki <aaron= > [email protected]> wrote: > >> Ultimately it is the Resource Authorization Server that will decide what >> scope to issue for the access token. It may have its own policies around >> scopes based on user/client/IdP and can make the final decision. >> >> If the ID-JAG contains a scope claim, it's because the IdP allows the >> admins to configure what scopes a client is allowed to request for a >> resource. It is expected that the Resource AS should respect the request if >> appropriate. In other words, the Resource AS should not blindly trust the >> scope values in the ID-JAG. >> >> To make this more concrete, let's use an example of a chat app as the >> Resource. The chat app might have its own policy that any client can get >> read/write access to the channels a user is already in, but Cross App >> Access clients using an ID-JAG do not get access to join new channels. The >> API could use a scope value of "channels:join" and only allow clients that >> have gone through an interactive user consent flow to request that scope. >> If an ID-JAG contains the "channels:join" scope, the chat app's AS would >> not include that scope in the access token issued. This is analogous to the >> text in Section 3.3 of RFC6749 treating the "scope" parameters as a request >> from the client that may or may not be granted. "The authorization server >> MAY fully or partially ignore the scope requested by the client, based on >> the authorization server policy or the resource owner's instructions." >> >> Aaron >> >> >> >> On Thu, Dec 4, 2025 at 11:25 PM Judith Kahrer <judith.kahrer= >> [email protected]> wrote: >> >>> Dear OAuth WG, >>> >>> while reading through the 01 draft of the Identity Assertion JWT >>> Authorization Grant ( >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/01/) >>> and implementing it, we came across some open questions regarding the scope >>> of the access token for the Resource that we didn't find any answer in the >>> draft or related specs. >>> >>> TLDR; The main question that we have is, does the Resource Authorization >>> Server issue in the access token whatever (scope) is in the ID-JAG? >>> Below follows a longer elaboration of my thoughts about how to process >>> the ID-JAG regarding scopes. >>> >>> The ID-JAG is a grant. A grant is always tied to a scope (implicitly or >>> explicitly). Shouldn't the scope claim in the ID-JAG be required then? In >>> that way it becomes clear for the Resource Authorization Server what the >>> subject consented to (grants access to). According to RFC 7521, section >>> 4.1, (https://datatracker.ietf.org/doc/html/rfc7521#section-4.1), "the >>> authorization server MUST limit the scope of the issued access token to be >>> equal to or less than the scope originally granted to the authorized >>> accessor." If the scope is missing in the grant, the Resource Authorization >>> Server has to make assumptions about the default scope. >>> Since the IdP Authorization Server and the Resource Authorization Server >>> are two different entities in two different trust domains, their policies >>> may differ. There is a risk that the default scope at the IdP Authorization >>> Server is not the same as the default scopes at the Resource Authorization >>> Server, which basically results in the subject consenting to one thing but >>> the client getting authorized for something different. Therefore, I think, >>> the scope claim in the ID-JAG should be REQUIRED. The scope of the access >>> token is the intersection of the scope in the ID-JAG and the requested >>> scope in the token request. At the end it is at the discretion of the >>> Resource Authorization Server what scope to include in the access token as >>> long as it doesn't violate the grant. At least, this is how I think grants >>> should work. >>> >>> In my opinion, section 4.4.1 should point to RFC 7521 for validating the >>> scope claim. The reference to RFC 6749, section 3.3 is not appropriate for >>> validating the scope claim because it is solely about the scope request >>> parameter and does not even mention its relation to the authorization >>> grant. The Resource Authorization Server must not treat the scope claim >>> like the scope request parameter. While it's ok to ignore a request >>> parameter, ignoring a grant and the scope of the grant defeats its purpose. >>> Don't you agree? >>> >>> I get the feeling that there is quite some duplication of policies in >>> the IdP Authorization Server and Resource Authorization Server with regard >>> to scopes. One needs scopes for the grant, the other for issuing access >>> tokens. Who is responsible for defining the scopes and deciding what ends >>> up in the access token? In my opinion, it should be the Resource >>> Authorization Server because it has the authority to grant access to >>> resources. If that's not the case and the Resource Authorization Server >>> issues whatever is in the grant, then it's simply an (access) token issuer >>> for the IdP Authorization Server. What's the purpose of an authorization >>> server if it doesn't own any policy? Can you elaborate more on the use >>> cases? >>> >>> I went down a rabbit hole the more I thought about scopes and I have >>> some more questions. I may eventually start a new mail thread for those to >>> keep this conversation focused on how the Resource Authorization Server >>> should handle the scopes of the ID-JAG. >>> >>> Best regards, >>> Judith Kahrer >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
