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 <[email protected]> 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
<[email protected]>
<mailto:<[email protected]>>
wrote:
> I submitted
https://datatracker.ietf.org/doc/draft-bunch-groupware-scopes/
<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 -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
<mailto:[email protected]>
>
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
