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>
wrote:

> On 21 Sep 2023, at 17:19, 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.
>
> 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

Reply via email to