+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=40amazon....@dmarc.ietf.org>: > 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 <wpa...@rhosys.ch> 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 <cdbu...@emeraldgroupware.org> > 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 -- oauth@ietf.org > > To unsubscribe send an email to oauth-le...@ietf.org > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
