[OAUTH-WG] Re: Standardized OAuth 2.0 Scopes for Mail, Calendar, and Contact Access

["[e-mail]" <[e-mail]>]

+1 for using RAR, access to calendars and so on needs context (particular calendar instances, for example). That’s what RAR is designed for.

best regards,
Torsten.
Am 20. Juli 2025, 12:02 +0300 schrieb Lombardo, Jeff <jeffsec=[e-mail]>:
> To add to Warren point, it is important to reup feu Vittorio Bertocci blog entry on the nature of OAuth2 scopes that cover exactly this use case: https://auth0.com/blog/on-the-nature-of-oauth2-scopes/
>
> I think this proposal instead of building on top of the `scope` claim should pivot into profiling OAuth 2.0 Rich Authorization Requests (https://datatracker.ietf.org/doc/html/rfc9396)
>
> Jean-François “Jeff” Lombardo | Amazon Web Services
>
> On Sun, Jul 20, 2025 at 08:19 AM Warren Parad <[e-mail]> wrote
>
> I have some serious problems with this document:
>
>    - I fundamentally disagree about the scopes defined for mail, calendar,
>    and contact. One of the biggest problems with the scopes today, is the lack
>    of the scope "update/modify/delete BUT only the emails, contacts, and
>    calendar meetings that the app has created". I don't want to give *access
>    to delete all my calendars* just so an app can *create calendar
>    appointments in one calendar*.
>
> For me, scopes for calendar and contacts are already broken by design, and
> this document actually makes it worse. Take the scope
> *urn:ietf:params:oauth:scope:calendar:update:*
>
> >  Grants permission to create, modify, and delete calendars and events on
> > the user's behalf.
>
>
> The creation, modification, and deletion of calendars must be completely
> independent from the creation, modification, and deletion of calendars. And
> most problematically, *as a user*, I would only want to give access to do
> this one calendar at a time. Because of this we really need to define
> resource based syntax inside of OAuth spec to replace the scopes.
>
> In conclusion, this document only sets out to standardize the irresponsible
> behavior of apps utilizing scopes today, cementing the current paradigm
> rather than replacing it with something that actually works correctly.
> Using OAuth scopes alone for this access, is the part that is wrong, not
> that it isn't standardized. In some cases, an incremental approach might
> help get to the perfect solution, but I don't see this document helping to
> make that happen. If it does anything for me, this prevents forward
> progress in preference of keeping exactly what we already have.
>
> On Sun, Jul 20, 2025 at 7:42 AM Clinton Bunch <[e-mail]>
> wrote:
>
> > I submitted https://datatracker.ietf.org/doc/draft-bunch-groupware-scopes/
> >
> > This is a proposal of standard OAUTH2 scopes to support the loosely
> > coupled world of mail, calendaring, and contacts servers and clients.
> >
> > The current state is that every Authorization Server defines their own
> > scopes for these groupware services, leading client developers to hard
> > code these scopes, which, in practicality, limits them to supporting
> > OAUTH2 authentication for only a dozen or so providers big enough to
> > strong arm them into it.
> >
> > This is the remaining barrier to wide spread deployment of OAUTH2
> > authentication for groupware services.  The other half of the problem,
> > Client Registration, is solved by RFC 7591, OAuth 2.0 Dynamic Client
> > Registration Protocol.
> >
> > With these two pieces in place, Authorization Servers and clients can
> > begin to implement this advanced authorization process.
> >
> > _______________________________________________
> > OAuth mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]