Hey Clinton I agree with the need for standard scopes for mail, calendar, and contact APIs. Thanks for starting this work. Standard scopes will only be useful with standard APIs, and I would think that defining the scopes with the APIs would be more useful to implementers than having them defined in the OAuth WG.
I also think you will have more success in aligning a WG that cares about mail, calendar, and / or contacts on scopes than you will aligning a WG that works on the protocol on application specific scopes. /Dick On Sun, Jul 20, 2025 at 9:31 PM Clinton Bunch <cdbu...@emeraldgroupware.org> wrote: > I agree that the document scope should be expanded to include RAR profiles. > > This granularity of OAUTH scopes I've specified is in line with what I > have been asked to approve before as a user. To get much more granular > than that would be an explosion of scopes and would be re-inventing the > wheel. > > It could actually be argued that the individual scopes I've specified are > *too* granular and their restrictions is in some cases not implemented at > this time. I believe dovecot, for example, takes no notice of the scopes > defined for a token. It might be that just the composite scopes are used > and RAR support allowed to grow as it can. > > This isn't a new API being designed we're talking about. We're trying to > shoehorn in a modern authentication method into 30, even 40+ year old > protocols, with dozens of implementations and thousands of instances. Some > of those implementations have done the bare minimum to implement OAUTH, but > RAR support is going to take time. Something needs to fill that gap, or > the chicken and egg problem will never be solved leaving smaller providers > and implementers at a distinct disadvantage in the marketplace. At this > point, not even all AS implementations support RAR > > RAR notwithstanding, we may never be rid of scopes in OAUTH, just as > despite it flaws we're still using SMTP after more than 40 years. > > On 7/20/2025 13:37, tors...@lodderstedt.net wrote: > > RAR adoption is a typical hen or egg problem. The more API designers and > spec writers adopt RAR, the more RAR will be supported in products. What I > can you from experience, RAR can be implemented on top of products as it an > additional parameter. > > If you as domain expert believe static scope values are sufficient, you > should pursue your proposal. > > If there is a need to have any context/dynamic values in the „scope“ to be > authorized, you need to encode this somehow. You can do it your way or > adopt something that has already proven to work in practice and is > available as an RFC. > > best regards, > Torsten. > Am 20. Juli 2025, 19:43 +0200 schrieb Clinton Bunch > <cdbu...@emeraldgroupware.org> <cdbu...@emeraldgroupware.org>: > > I had read the blog post and I think my proposal fits well with its > intent. It specifically says that scopes are not for the fine grained > access control that Warren wants and that that should properly be the > purview of the resource server. > > While a quick look at RAR points to the fact that a specification would be > beneficial, it also appears that support for RAR is lagging. So until > authorization servers, resource servers, and clients all support RAR, some > kind of scope context is going to continue to be needed. > > That kind of "universal" support in a decoupled ecosystem like e-mail, > calendars, and contacts is going to take time. > > So, while I agree expanding the scope of the draft to include standard RAR > profiles is a good idea, I don't believe dropping the scopes would be a > good idea at this time. Doing so could easily hamstring widespread support > of advanced authentication for these services for many years. > > On 7/20/2025 04:01, Lombardo, Jeff wrote: > > 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> > <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> <<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 > > > _______________________________________________ > 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
