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. 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 3. Some calendaring products have an additional authorization level that will only expose free/busy information rather than full details of calendar entries 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? -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
