Thanks, Aaron and Karl for your answers. I wasn't aware of the ongoing discussion concerning discovery, thanks for pointing it out. It all makes more sense now.
Regards, Judith On Fri, Dec 5, 2025, 17:43 Karl McGuinness <[email protected]> wrote: > 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]
