Good morning Mam /Sir I just read the message..thank you very much for your trust..I am happy now because there is a real person who cares about me😢😢😢😢
On Mon, Jul 21, 2025, 3:33 AM <oauth-requ...@ietf.org> wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > Today's Topics: > > 1. Re: Standardized OAuth 2.0 Scopes for Mail, Calendar, and Contact > Access > (Clinton Bunch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Jul 2025 14:31:45 -0500 > From: Clinton Bunch <cdbu...@emeraldgroupware.org> > Subject: [OAUTH-WG] Re: Standardized OAuth 2.0 Scopes for Mail, > Calendar, and Contact Access > To: oauth@ietf.org > Message-ID: > <5a470426-e672-4fff-8613-d737ea953...@emeraldgroupware.org> > Content-Type: multipart/alternative; > boundary="------------BALVxe1zK0P0zcv56eBvbJJu" > > 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>: > >> 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> 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> > >>> <mailto:<cdbu...@emeraldgroupware.org>> > >>> > >>> 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 -- oauth@ietf.org <mailto:oauth@ietf.org> > >>> > >>> > To unsubscribe send an email to oauth-le...@ietf.org > >>> <mailto:oauth-le...@ietf.org> > >>> > >>> > > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list --oauth@ietf.org > >>> To unsubscribe send an email tooauth-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 tooauth-le...@ietf.org > > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 19960 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > ------------------------------ > > End of OAuth Digest, Vol 201, Issue 47 > ************************************** >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
