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
