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

[Clinton Bunch <[e-mail]>]

I was under the impression from my reading of the spec, that scopes were 
only ever intended as coarse-grained authorizations. I would not expect 
the AS to control finer-grained access as that would require intimate 
knowledge of the contents of the resource server.  (For example, what 
calendars a user has defined for their own account and the updates to 
that list.)

As for AS support, scopes should be a an administrative decision not a 
developer decision as a given AS may support a wide range of custom 
applications with their own scope needs.  Yes, some providers will 
probably not configure these scopes, especially large providers which 
have already designated their own scopes, but there are hundreds, if not 
thousands of groupware instances, many operated by smaller organizations 
who would be running their own AS.  Thunderbird can't hard-code scope 
for every large organization much less these smaller ones.  Currently it 
only supports 6 or 7 organizations with on the order of millions of users.

On 4/3/2023 10:38 AM, Kai Lehmann wrote:
>
> My company intends to add OAuth2 support for its groupware services 
> (mail - imap/pop3/smtp, calendar, and contacts. We are “big enough” to 
> have specific configurations in common groupware clients like 
> Thunderbird and Outlook.
>
> Although we do not yet allow 3^rd party AS, this may change in the 
> future, so a common set of well-defined scopes for those purposes 
> could actually help us avoid some complexity of mapping scopes. 
> However, it still requires all the AS to also support those scopes 
> once they are defined and agreed upon, which I think will not happen 
> as the most prominent AS providers also usually have groupware 
> solutions and they prefer the users to choose their solutions across 
> the board and not integrate with the competition.
>
> It should be mentioned, that generic permissions/scopes are usually 
> not enough for groupware solutions. Relational-based access control 
> policies are a big factor here. While an End-User may have full access 
> to one mailbox, they may only have read access to another one. This 
> cannot simply be expressed with an AT and its scopes. The service 
> provider may need to incorporate additional access control rulesets 
> (similar to Google Zanzibar or OpenFGA). RAR 
> (https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html) looks 
> promising here.
>
> Kai Lehmann
>
> 1&1 Mail & Media Development & Technology GmbH
>
> *From: *OAuth <[e-mail]> on behalf of Warren Parad 
> <wparad=[e-mail]>
> *Date: *Monday, 3. April 2023 at 00:00
> *To: *Clinton Bunch <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [OAUTH-WG] A proposal for a new Internet Draft
>
> I think it would make sense if after CalDAV was updated to explicitly 
> include OAuth scopes relevant for it, that it could be considered to 
> update the official OAuth parameter scope list to include them. But I 
> would like to avoid doing this in reverse. I.e. Let's have the 
> calendar experts decide what OAuth scopes make sense, and then we can 
> approve adding them to the list. This makes sense rather than us 
> trying to decide which scopes make sense for calendar applications 
> that we don't necessarily have expertise in. I don't have any 
> confidence in my ability (I'm not going to speak for everyone) in 
> knowing whether these are the right scopes, and getting this wrong is 
> very very hard to undo. While we can replace CalDAV specs, we don't 
> have any good strategy to remove official scopes. So before we add 
> them, we should be near 100% sure that they are the correct ones and 
> will never change.
>
> On Sun, Apr 2, 2023 at 11:53 PM Clinton Bunch <[e-mail]> 
> wrote:
>
>     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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth