I think we’re used to thinking of scopes in terms of things that a developer can read and understand, but that’s not always going to be true. For automated systems like this, the developer isn’t always expected to understand the scope — they probably don’t even see it in many cases. The client software knows the API, but at the OAuth layer, the client just needs to know what values to put into the OAuth flow to be able to call the RS and have it work. That value could very well be an opaque string, which is supported by the 6750 response header already as well.
— Justin On Sep 22, 2023, at 1:58 PM, Atul Tulshibagwale <a...@sgnl.ai> wrote: Hi, #1 is clear now. Thanks Warren On #2, thanks Neil and Warren for your clarifications. Does it make sense to include language that warns against requesting unknown scopes in the OPRM draft? Atul On Thu, Sep 21, 2023 at 11:17 AM Neil Madden <neil.e.mad...@gmail.com<mailto:neil.e.mad...@gmail.com>> wrote: On 21 Sep 2023, at 17:19, Atul Tulshibagwale <a...@sgnl.ai<mailto: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. Regarding point 2, if this is a threat then it's already enabled by RFC 6750, which defines the `WWW-Authenticate: Bearer scope="..."` challenge header that can be used to indicate which scopes a client needs to access a resource. Even just misleading documentation for how to access the RS could enable this threat. That's not to say that this isn't worth considering (it is), but I don't think this draft makes the situation worse than now. -- Neil _______________________________________________ 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
