Re: [OAUTH-WG] A proposal for a new Internet Draft

[Clinton Bunch <[e-mail]>]

On 4/2/2023 3:13 PM, Warren Parad wrote:
> I'm looking for proof that anyone actually needs these. Introducing 
> unnecessary scopes into the spec is both a waste of time and 
> needlessly complicates the documentation. So we need there to be a 
> real problem that is attempting to be solved in which additional 
> scopes is the right solution.
>
> I'm going to start off the conversation by saying, I think this is a 
> bad idea. Most services in the world do not have any of these, and 
> when they do the relevant scopes are coupled to the relevant 
> authorization server (AS). In other words, you only define the scopes 
> you want after reviewing the documentation for the relevant AS. 
> Defining new standard scopes helps for interoperability, but there is 
> zero interoperability with scopes (the AS defines them, the Dev picks 
> them, and the User reviews them. Scopes don't carry additional meaning 
> cross platforms). So this seems like just a really bad idea to me.
>
> Scopes do help with permissions and visibility in the created id_token 
> (or access_token), for instance let's say a service wanted to link a 
> user's access to their ethereum wallet. In that case, a new scope like 
> eth_wallet_id might make sense, so that the wallet public key would 
> show up in the id_token to be directly used.
>
> But the scopes that have been proposed don't expose data in the 
> tokens, they define access. User contact information is already 
> available via *profile, email, address, and phone*. That means not 
> only are we talking about creating additional scopes, we are also 
> talking about expanding scopes in a way that currently isn't used. 
> Which brings us back to, what problem are you trying to solve?


Right now an email (or calendar or contact) client (such as Thunderbird) 
is in general written by an organization separate from the author of the 
resource server (such as Dovecot), which is different from the author of 
the authorization server.  The authorization server may have several 
scopes it supports, so even using the discovery protocol, the client 
doesn't know how to choose the scopes it needs to request without those 
scopes being hard-coded per authorization server, or entered by the 
user.  This would allow the client, AS, and resource server too use a 
common set of scopes to specify that this domain is offering groupware 
services and the scopes the client needs to request.  It requires 
cooperation from the AS administrator, true, but both client and server 
know what the appropriate scopes are without further configuration.

These clients may be used across thousandds of AS domains and having to 
hard-code the scopes for each is going to deter adoption of Oauth2 
authentication, by limiting it to only a few domains.

Another use case is connecting voice assistants to calendars hosted on 
servers of small organizations.  The voice assistant needs to know what 
scopes to request for the token to access the users calendar.  Right now 
that is limited to just the calendar services of a few large players 
which are hard-coded.

Having the user enter the necessary scopes by hand, where the client has 
that capability, leads to a poor user experience.

The point of these scopes is to allow small players in the field to use 
common implementations and have them work for a wide set of users 
without placing an undue burden on the user.

>
> On Sun, Apr 2, 2023 at 9:57 PM Clinton Bunch <[e-mail]> wrote:
>
>     On 4/2/2023 2:49 PM, Warren Parad wrote:
>>     But why these scopes?
>
>     Separate read and write scopes for the three pieces of a groupware
>     service seemed appropriate.  And separating the three pieces of
>     groupware seemed appropriate as not all domains or users will use
>     all of them.
>
>     But since the most common use cases would include both read and
>     write, I defined short-hand scopes that included both permissions.
>
>     If that doesn't answer your question, then I'm not sure what
>     you're looking for.
>
>>
>>     On Sun, Apr 2, 2023 at 9:37 PM Clinton Bunch
>>     <[e-mail]> wrote:
>>
>>
>>
>>         On 4/2/2023 2:26 PM, Warren Parad wrote:
>>>         Sorry, I'm asking why these scopes at all? I personally have
>>>         never seen any of them used ever (and I'm not being
>>>         hyperbolic), How did you come up with these suggestions?
>>>
>>         The naming seemed logical given the IANA URI namespace.  I
>>         was looking for something that would be a common set of
>>         scopes for this application domain that wasn't tied to a
>>         single vendor.
>>
>>         The purpose *could* be served by widespread adoption of
>>         Google's scopes such as
>>
>>         https://www.googleapis.com/auth/calendar
>>
>>         but I believe that the reliance on a specific vendor name
>>         would hamper wide-spread adoption, so a namespace defined by
>>         a neutral party such as IETF seemed best.
>>
>>>         On Sun, Apr 2, 2023 at 8:46 PM Clinton Bunch
>>>         <[e-mail]> wrote:
>>>
>>>             On 4/2/2023 1:34 PM, Warren Parad wrote:
>>>>
>>>>                 I propose a set of nine well-known scopes
>>>>
>>>>
>>>>             Can you elaborate on what you mean by "well-known"? Is
>>>>             there some canonical list, where these were pulled from?
>>>
>>>             I was trying to avoid the use of standard, as that
>>>             implies they must be used.  To encourage adoption, I
>>>             didn't want to imply that the large providers would be
>>>             required to change their software to accommodate these,
>>>             though it would be nice if they did.  These scopes are
>>>             not currently in use as far as I know.
>>>
>>>             The sense of well-known is that once this was published
>>>             they would be well-known scopes that could be
>>>             implemented with well-defined semantics.
>>>
>>>>
>>>>             - Warren
>>>>
>>>>             On Sun, Apr 2, 2023 at 8:12 PM Clinton Bunch
>>>>             <[e-mail]> wrote:
>>>>
>>>>                 This seemed the most appropriate working group to
>>>>                 post this suggestion.
>>>>
>>>>                 I would like to see a new Internet-Draft/RFC to add
>>>>                 some well-known
>>>>                 scopes to the IANA registry to promote adoption of
>>>>                 Oauth in Groupware
>>>>                 domains.  I will try to write it myself, but have
>>>>                 no experience with
>>>>                 I-Ds or as a technical writer and could use some help.
>>>>
>>>>                 Since the publication of RFC 7628 there is a push
>>>>                 to migrate groupware
>>>>                 servers to use Oauth2.  This is hampered by the
>>>>                 fact that there are
>>>>                 several different server implementations and client
>>>>                 implementations are
>>>>                 often written by different organizations with
>>>>                 little overlap. One of
>>>>                 the barriers to widespread adoption is that each
>>>>                 authorization server
>>>>                 has a different set of scopes to cover the
>>>>                 necessary user
>>>>                 authorizations.  One groupware client I know has
>>>>                 only a few Auth Servers
>>>>                 available that are hardcoded and nearly every one
>>>>                 has a different set of
>>>>                 scopes.  Servers have to have appropriate scopes
>>>>                 configured by the
>>>>                 administrator in order for the server to know which
>>>>                 scopes to check.  It
>>>>                 also makes it hard for clients to know which scopes
>>>>                 to request without
>>>>                 some sort of configuration file provided by the
>>>>                 domain or worse, having
>>>>                 the user enter the appropriate scopes by hand.  The
>>>>                 latter especially
>>>>                 seems like a support headache for the admin of the
>>>>                 groupware servers.
>>>>
>>>>                 I propose a set of nine well-known scopes be added
>>>>                 to the Oauth URI IANA
>>>>                 registry to address this.
>>>>
>>>>                 urn:ietf:params:oauth:scope:mail:read        -
>>>>                 Authorization to read
>>>>                 email (IMAP,POP)
>>>>                 urn:ietf:params:oauth:scope:mail:send        -
>>>>                 Authorization to send
>>>>                 mail on the user's behalf (SMTP)
>>>>                 urn:ietf:params:oauth:scope:mail         -
>>>>                 Combination of the
>>>>                 previous two scopes
>>>>                 urn:ietf:params:oauth:scope:calendar:read        -
>>>>                 Authorization to read
>>>>                 calendar entries
>>>>                 urn:ietf:params:oauth:scope:calendar:update    -
>>>>                 Authorization to
>>>>                 update/create/delete calendar entries
>>>>                 urn:ietf:params:oauth:scope:calendar        -
>>>>                 Combination of the
>>>>                 previous two scopes
>>>>                 urn:ietf:params:oauth:scope:contacts:read        -
>>>>                 Authorization to read
>>>>                 contacts information
>>>>                 urn:ietf:params:oauth:scope:contacts:update    -
>>>>                 Authorization to
>>>>                 update/create/delete contact information.
>>>>                 urn:ietf:params:oauth:scope:contacts        -
>>>>                 Combination of the
>>>>                 previous two scopes
>>>>
>>>>                 _______________________________________________
>>>>                 OAuth mailing list
>>>>                 [e-mail]
>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>
>