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 <oauth-boun...@ietf.org> on behalf of Warren Parad
<wparad=40rhosys...@dmarc.ietf.org>
*Date: *Monday, 3. April 2023 at 00:00
*To: *Clinton Bunch <cdb_i...@zentaur.org>
*Cc: *"oauth@ietf.org" <oauth@ietf.org>
*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 <cdb_i...@zentaur.org>
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
<cdbu...@zentaur.org> 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
<cdb_i...@zentaur.org> 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
<cdb_i...@zentaur.org> 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 <cdb_i...@zentaur.org> 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
<cdb_i...@zentaur.org> 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
<cdb_i...@zentaur.org>
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
