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
