Gotcha On Sun, Jul 20, 2025 at 9:50 PM Clinton Bunch <cdbu...@emeraldgroupware.org> wrote:
> Apparently, one of the replies narrowed the scope of the thread. I had > originally engaged mailmaint, calsify, and jmap as well as oath. > > On 7/20/2025 14:44, Dick Hardt wrote: > > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
