A key advantage of having a new API resource is that the resource *could* be protected and the response contextual to the requesting client. A challenge that exists today with Authorization Server Metadata is that it doesn't support per-client responses which creates complications with change management and discovery that would benefit from per-client metadata values . Additionally scopes_supported already doesn't support resource based scopes for use with resource indicator requests without forcing implementers to construct resource+scope URIs as scope names (e.g https://app.example/resource-name/scope:read). We basically need a audience+resource+scope tuple to fully qualify a grant for a Resource Authorization Server than can have N resources each with Y scopes which is what is being proposed in the PR.
-Karl On Fri, Dec 5, 2025 at 8:20 AM Aaron Parecki <aaron= [email protected]> wrote: > For all practical purposes, it is not likely that an enterprise IdP will > want to publish a list of all possible Resource Authorization Servers and > scopes that are configured. We do not expect the IdP's Authorization Server > Metadata to include data from other trust domains. > > There is an open issue to discuss how a Client can discover the possible > Resources it can obtain an ID-JAG for from the IdP: > https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/52 > > The current thinking is that this would be better accomplished by defining > a new API resource at the IdP, analogous to "userinfo", which returns a > list of resources supported based on the context of the user presented in > the request. This could then also include the list of scopes per resource. > > Aaron > > > On Fri, Dec 5, 2025 at 12:10 AM Judith Kahrer <judith.kahrer= > [email protected]> wrote: > >> Hello, >> >> while studying draft 01 of the Identity Assertion JWT Authorization >> Grant, I started wondering how the fact that the IdP Authorization Server >> handles scopes for a different trust domain impacts the ecosystem like the >> authorization server metadata. >> To my understanding the IdP Authorization Server supports scopes for a >> different - possibly multiple - trust domains. Doesn't that affect the >> meaning of the scopes_supported property in the authorization server >> metadata? Shouldn't the IdP Authorization Server in its authorization >> server metadata also include which trust domains and what scopes for those >> trust domains it supports? Currently, section 6 "Authorization Server (IdP) >> Metadata" only specifies the urn:ietf:params:oauth:token-type:id-jag as >> a value for identity_chaining_requested_token_types_supported. I get the >> feeling that this is not enough. What do you think? >> >> 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]
