On 4/2/2023 3:43 PM, David Waite wrote:
This seems like something more appropriate for a group focused closer to the
needs of groupware implementers (such as JMAP) to define. I would be worried
about whether we are capturing the appropriate level of complexity for these as
well as defining interoperable usage - for examples around calendaring:
1. What would the calendar API be behind the calendar scopes - if we are
talking RFC 7628, I would assume it is not CalDAV.
I mention RFC 7628 in terms of email. I don't know of any groupware
domains that offer calendar services without email. The protocol I had
in mind was indeed CalDAV. Sorry that wasn't clear.
2. does ...calendar:update necessarily include the ability to read calendar
entries, or is it meant to be used for a client to create and maintain its own
entries by retaining some prior knowledge
Now that you mention it, I can't think of a use case where you would
need write access without read access.
3. Some calendaring products have an additional authorization level that will
only expose free/busy information rather than full details of calendar entries
I could see an additional scope added for that.
4. Some calendaring products support maintaining both multiple local calendars
- how would a client expect to differentiate which calendar they are asking for
authorization? Would the expectation be that they are requesting those
calendars as individual resources, that the scopes only define access to _all_
calendars that the resource owner can view, or that the AS would determine
which (of potentially several) calendars to share as part of the authorization
process?
The scope would be for all calendars visible to the user as defined by
the ACLs set on the calendar server. I can't think of a manageable way
to use scope to get more fine-grained than that. Perhaps defining a new
optional claim with the URI of the specific calendar could be added to
the request and the introspection response or JWT.
-DW
On Apr 2, 2023, at 12: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
