For (1) arguably these are different resources, therefore, they of course have different paths. The draft specifically outlines that each of them can have their own metadata document:
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#name-protected-resource-metadata- If the resource identifier value contains a path component, any terminating / MUST be removed before appending /.well-known/ and the well-known URI path suffix. The consumer of the metadata would make the following request when the resource identifier is https://resource.example.com/resource1 and the well-known URI path suffix is oauth-protected-resource to obtain the metadata, since the resource identifier contains a path component: <https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#section-3.1-4> GET /resource1/.well-known/oauth-protected-resource HTTP/1.1 Host: resource.example.com <https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#section-3.1-5> Using path components enables supporting multiple resources per host. This is required in some multi-tenant hosting configurations. This use of .well-known is for supporting multiple resources per host; unlike its use in [RFC5785 <https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-00.html#RFC5785> ], it does not provide general information about the host. For (2), this is already the case with OAuth, and has nothing to do with this draft. The solution here is for resource servers to check the *audience* claim in the incoming token if it is a JWT. If for some reason they can't do that or it isn't a JWT, then DPoP exists to constrain requests to prove that the client should be allowed to utilize that token. On Thu, Sep 21, 2023 at 6:19 PM Atul Tulshibagwale <a...@sgnl.ai> wrote: > Hi all, > I'm still looking for answers to these two questions > <https://mailarchive.ietf.org/arch/msg/oauth/NLj-xnAZ4BtFs9z62OzCro4xxoc/> > regarding the OPRM draft that was recently adopted by the WG: > > 1. If I have a resource server that has multiple endpoints, each of > which require different scopes, how should those be handled? For example, > in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a > Polling endpoint. The scopes required for these are different. How would > the client know which scope is to be used with which endpoint? > 2. Does the spec encourage insecure behavior in the caller by > requesting tokens with scopes that they do not understand? I.e. If an > authorization server is known to provide valuable tokens with certain > scopes, can a malicious resource server trick the client into requesting a > more powerful token, which it then uses to access some other service? Since > the consent dialog is likely to show two trusted names (i.e. the requesting > client and the authorization server), the user would be prone to providing > consent, even if the scope looks unnecessarily permissive. > > Thanks, > Atul > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
