[OAUTH-WG] Re: Standardized OAuth 2.0 Scopes for Mail, Calendar, and Contact Access

[Clinton Bunch <[e-mail]>]

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, [e-mail] 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 
> <[e-mail]>:
>> 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 <[e-mail]> 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 
>>> <[e-mail]> 
>>> <mailto:&lt;[e-mail]&gt;>
>>>
>>> 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 -- [e-mail] <mailto:[e-mail]>
>>>
>>> > To unsubscribe send an email to [e-mail] 
>>> <mailto:[e-mail]>
>>>
>>> >
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list [e-mail]
>>> To unsubscribe send an email [e-mail]
>>
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list [e-mail]
> To unsubscribe send an email [e-mail]