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

[Clinton Bunch <[e-mail]>]

On 4/2/2023 4:44 PM, Warren Parad wrote:
> If CalDAV is that spec, then wouldn't it make sense to request updates 
> to that spec to additionally define OAuth scopes? I don't think it 
> makes sense for the OAuth WG to define scopes for other specs, and I 
> also don't think updating the CalDAV spec is in the purview of this 
> working group. Instead the expectation is for specs using OAuth to 
> define their own scopes. In that light, might it make sense to review 
> the current working groups to find one that could take on the addendum 
> to the existing CalDAV spec?
I considered posting this to calext or emailcore, but neither would be 
appropriate for all these scopes and Oauth would need to approve the 
IANA registration using this URI namespace.  So I tried here first.
>
> On Sun, Apr 2, 2023 at 11:24 PM Clinton Bunch <[e-mail]> wrote:
>
>     On 4/2/2023 4:06 PM, Warren Parad wrote:
>>     Why is this still hypothetical, is there a reason you don't want
>>     to share a concrete use case?
>
>     I run a small e-mail and calendar server for my own use.
>     Thunderbird cannot provide Oauth authentication to my server
>     without knowing what scopes define email services or calendar
>     services or contacts services.  It is impractical to expect
>     Thunderbird to map my specific scopes to those services and do the
>     same for thousands of other servers.  So having a well-defined set
>     of scopes with well-defined semantics allows Thunderbird to use
>     the discovery protocol to see that my AS supports some or all of
>     those scopes.
>
>
>>     Sure, Thunderbird needs to understand the scopes mapped by email
>>     providers, but having shared scope names, does not imply the
>>     implementation of those scopes. So Thunderbird still has to
>>     maintain a map of "what it wants" to "what scope provides that by
>>     that service in question". Having standard scopes doesn't change
>>     that, it only hopefully convinces existing email providers to
>>     actually change their scope names.
>     Since most small providers don't currently have scopes defined
>     because the clients don't even try to support scopes except those
>     defined by the big players, this gives them a set of scopes that
>     can be reasonably supported by both the AS and the client without
>     manual configuration.
>>
>>     Are existing email providers going to change their scope names? I
>>     can't see Google Calendar doing that. The problem with defining
>>     arbitrary strings that imply permissions, is that "what exactly
>>     those scopes means" is not trivially obvious. That is, as David
>>     Waite put it, does *calendar:update imply calendar:read*. Adding
>>     both to the oauth params still allows some providers to say
>>     *yes* while others say *no*. Which means we aren't just talking
>>     about adding scopes, we are talking about what those scopes
>>     imply. Before we can add scopes, I think we would need to first
>>     point to a globally accepted calendar service interface
>>     specification which we could use to draw inspiration from.
>>     However if such spec already existed, then the scopes would also
>>     exist.
>
>     How is CalDAV  not that spec?
>
>     Yes, there may be places where the semantics are not quite
>     well-defined enough, that would be the point of having a discussion.
>
>>
>>     That is to say, a spec needs to exist before creating scopes, and
>>     if the spec did exist, the scopes would already be defined. For
>>     the that reason, I don't believe this this the best working group
>>     for that.
>>
>>
>>     On Sun, Apr 2, 2023 at 10:53 PM Clinton Bunch
>>     <[e-mail]> wrote:
>>
>>         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
>>>>>>
>>>>>
>>>>
>>>
>>
>