Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4EE7B4690FF9 for ; Sun, 20 Jul 2025 02:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkslJErQGnkx for ; Sun, 20 Jul 2025 02:56:27 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 89D324690FE6 for ; Sun, 20 Jul 2025 02:56:27 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4561ca74829so38564695e9.0 for ; Sun, 20 Jul 2025 02:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; t=1753005386; x=1753610186; darn=ietf.org; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=Ah9v052vFPb88/rIcEMF77zedFnqBUmAC5oVS/Yhxvk=; b=d9W7NjB/bkyyj3ZrA/YmwB/AIXlH6gG7lrozdkxfnfFcEV89xNhhdmpgCDOk8y0Foo MXdAzAjUi8jUjTr5MDLcDR671BqptVi4xwNmf8Dj6SgZI8QyC2XDm6fc6RVnXMR3PNXr jICPnnRgYflTC8mYNE5NZvJNf/EeG6gHXcdLAsIQlyuqG/e0o9FWEutVT4SQbViwyqyq Vz4Tq379Ap9ctP0tFYhZ+rM3MRcEmwewmdBJzogPBs+ErVl+WuL7W7R0oHAgJTzma1fo PZJ9aNgDilGKq80aPfbZAbZWhWiOlag+59vk3r14VrxyiiZBoA0LvRpoY0+0qWRQEQHk m1OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753005386; x=1753610186; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ah9v052vFPb88/rIcEMF77zedFnqBUmAC5oVS/Yhxvk=; b=RKsWfWpAncO6VuBZnWdwJtaLYbUt6L/d0Xbv4F+TN4ee+vxtuUeJRcDxu9fipW5VVd QRn+KDFSEf2255NErQwc4pMEnbcxdXukfCSHOmqZimWc0qCKGUeF4gbafGuTK1FSLtd4 c7HumxpZ/NKvA69rpsOEXeR8lUncLakbvjeGIaw6r5Ts5PvKP3T7Hx7P+96VtueDe/iH OZZuYHg2+YE6hEqabX3J8+HpARZTGEHE7w3JTwrj0thbgf+5MdmWaLJf/AP99/TRa96+ ARJ0Zfo7U3xWrRaTI7E3EslgXvSGSgxJ04ISqtu01p12UO8uJf076H6MpPuKwhQmPU/F sGIQ== X-Gm-Message-State: AOJu0YzW5feVKVrnFVuPnZPvjkcEXAxMGggCdUVwqEs6+mvumEN+fkGN GlRZKH/F41gDcUIMnw4MD7cAVW5w8miJ+Cb2kbfskUzfN1/KEqpNpd/oO81BJtm+smCX4ocmnIV K/4mZVuLQTg== X-Gm-Gg: ASbGncvU0hHfLKeVvQxH1nJzLNxp7AJ3CA7GhZP8ZNsCb196MXcDvgqY5/fD6P9u+o9 JwH5aGyWhVE8WM3ROLRKD7KTLpBTd4N9QlDcgQNxqzqKdU/kH2warGLjd/tLkvQvV6j3emtih3E XHE/Fk0/VRjc0V0D3iDkgPRm0teDggMxS0hjriBRuhYDXTg/Pm6GZyC4Y+2bQomLs+UOFtF/pFX O0CgX7FD10ju1O8/uGFeua1WBpdCYEFpqp3fQ4wYr9Vq0aRfC4EE9jiNe5x4kkve8hg0KiWNFO5 Jy2fr+ygaTUfqJaFPLhkGWHWNJtbxoIkdTYrgPIsZTXhHqIRWHv2RtpS966V28iaTfAGSW2/QIT tlIOoI2eUa+xTiXpqc47ZgahOsHQVfeceHFZtyDQgEl//9YFW3Yg03DG8KvzJma5nOHL/1B0TB2 RH/1aX X-Google-Smtp-Source: AGHT+IGtHbbs4UJXHW8gWDE51lklw8ZlUwcbk8MHCDwDPfWR63ef8+eyextq3mnNwFKDjuaViRePZg== X-Received: by 2002:a05:600c:1e1b:b0:456:25aa:e9b0 with SMTP id 5b1f17b1804b1-45632814746mr150608435e9.16.1753005386232; Sun, 20 Jul 2025 02:56:26 -0700 (PDT) Received: from [10.35.153.230] (tmo-069-230.customers.d1-online.com. [80.187.69.230]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4563b5b8475sm68246655e9.12.2025.07.20.02.56.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jul 2025 02:56:25 -0700 (PDT) Date: Sun, 20 Jul 2025 12:56:19 +0300 From: "=?utf-8?Q?torsten=40lodderstedt.net?=" To: "=?utf-8?Q?oauth=40ietf.org?=" , =?utf-8?Q?Lombardo=2C_Jeff?= Message-ID: In-Reply-To: References: X-Readdle-Message-ID: cdce8c8c-d20f-41cf-8c1c-9929e6179f39@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="687cbd48_3e500d17_168ce" Message-ID-Hash: TEGVLJMEVQJQXA5R7W2QWOMZ4MK4PKBG X-Message-ID-Hash: TEGVLJMEVQJQXA5R7W2QWOMZ4MK4PKBG X-MailFrom: torsten@lodderstedt.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Standardized_OAuth_2=2E0_Scopes_for_Mail=2C_C?= =?utf-8?q?alendar=2C_and_Contact_Access?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --687cbd48_3e500d17_168ce Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline +1 for using RAR, access to calendars and so on needs context (particular= calendar instances, for example). That=E2=80=99s what RAR is designed fo= r. best regards, Torsten. Am 20. Juli 2025, 12:02 +0300 schrieb Lombardo, Jeff : > To add to Warren point, it is important to reup feu Vittorio Bertocci b= log 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 =60scope=60 cla= im should pivot into profiling OAuth 2.0 Rich Authorization Requests (htt= ps://datatracker.ietf.org/doc/html/rfc9396) > > Jean-=46ran=C3=A7ois =E2=80=9CJeff=E2=80=9D Lombardo=C2=A0=7C Amazon We= b Services > > On Sun, Jul 20, 2025 at 08:19=E2=80=AFAM Warren Parad wrote > > I have some serious problems with this document: > > =C2=A0=C2=A0 - I fundamentally disagree about the scopes defined for ma= il, calendar, > =C2=A0=C2=A0 and contact. One of the biggest problems with the scopes t= oday, is the lack > =C2=A0=C2=A0 of the scope =22update/modify/delete BUT only the emails, = contacts, and > =C2=A0=C2=A0 calendar meetings that the app has created=22. I don't wan= t to give *access > =C2=A0=C2=A0 to delete all my calendars* just so an app can *create cal= endar > =C2=A0=C2=A0 appointments in one calendar*. > > =46or 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:* > > >=C2=A0 Grants permission to create, modify, and delete calendars and e= vents on > > the user's behalf. > > > The creation, modification, and deletion of calendars must be completel= y > 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 irrespons= ible > 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, no= t > that it isn't standardized. In some cases, an incremental approach migh= t > 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=E2=80=AFAM Clinton Bunch > wrote: > > > I submitted https://datatracker.ietf.org/doc/draft-bunch-groupware-sc= opes/ > > > > 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 ow= n > > scopes for these groupware services, leading client developers to har= d > > 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.=C2=A0 The other half of the pr= oblem, > > Client Registration, is solved by R=46C 7591, OAuth 2.0 Dynamic Clien= t > > Registration Protocol. > > > > With these two pieces in place, Authorization Servers and clients can= > > begin to implement this advanced authorization process. > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list -- oauth=40ietf.org > > To unsubscribe send an email to oauth-leave=40ietf.org > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list -- oauth=40ietf.org > To unsubscribe send an email to oauth-leave=40ietf.org --687cbd48_3e500d17_168ce Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
+1 for using RAR, access to calendars and so on needs context (parti= cular calendar instances, for example). That=E2=80=99s what RAR is design= ed for.

best regards,&=23160;
Torsten.
Am 20. Juli 2025, 12:02 +0300 schri= eb Lombardo, Jeff <jeffsec=3D40amazon.com=40dmarc.ietf.org>:

To add to Warren point, it is important to reup feu Vittorio Bertocci bl= og entry on the nature of OAuth2 scopes that cover exactly this use case:= h= ttps://auth0.com/blog/on-the-nature-of-oauth2-scopes/

I think this proposal instead of building on top of the =60scope=60 claim= should pivot into profiling OAuth 2.0 Rich Authorization Requests= (https://d= atatracker.ietf.org/doc/html/rfc9396)

&=23160;

Jean-=46ran=C3=A7ois =E2=80=9CJef= f=E2=80=9D Lombardo&=23160;=7C Amazon Web Services

&=23160;<= /i>

On Sun, Jul 20, 2025 at 08:19=E2=80= =AFAM Warren Parad= <wparad=40rhosys.ch> wrote

&=23160;

I have some serious problems with this document:

&=23160;

&=23160;&=23160; - I fundamentally disagree about the scopes defined for= mail, calendar,

&=23160;&=23160; and contact. One of the biggest problems with the scope= s today, is the lack

&=23160;&=23160; of the scope =22update/modify/delete BUT only the email= s, contacts, and

&=23160;&=23160; calendar meetings that the app has created=22. I don't = want to give *access

&=23160;&=23160; to delete all my calendars* just so an app can *create = calendar

&=23160;&=23160; appointments in one calendar*.

&=23160;

=46or 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:*

&=23160;

>&=23160; Grants permission to create, modify, and delete calendars a= nd events on

> the user's behalf.

&=23160;

&=23160;

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 d= o

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.=

&=23160;

In conclusion, this document only sets out to standardize the irresponsi= ble

behavior of apps utilizing scopes today, cementing the current paradigm<= /span>

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.

&=23160;

On Sun, Jul 20, 2025 at 7:42=E2=80=AF= AM Clinton Bunch <cdbunch=40emeraldgro= upware.org>=

wrote:

&=23160;

> I submitted https://datatracker.ietf.org/doc/draft-bunch-groupware-scopes/

>&=23160;

> This is a proposal of standard OAUTH2 scopes to support the loosely=

> coupled world of mail, calendaring, and contacts servers and client= s.

>&=23160;

> The current state is that every Authorization Server defines their = own

> scopes for these groupware services, leading client developers to h= ard

> code these scopes, which, in practicality, limits them to supportin= g

> OAUTH2 authentication for only a dozen or so providers big enough t= o

> strong arm them into it.

>&=23160;

> This is the remaining barrier to wide spread deployment of OAUTH2

> authentication for groupware services.&=23160; The other half of th= e problem,

> Client Registration, is solved by R=46C 7591, OAuth 2.0 Dynamic Cli= ent

> Registration Protocol.

>&=23160;

> With these two pieces in place, Authorization Servers and clients c= an

> begin to implement this advanced authorization process.

>&=23160;

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<= /span>

> OAuth mailing list -- oauth=40ietf.org<= /a>

> To unsubscribe send an email to oauth-l= eave=40ietf.org

>&=23160;

&=23160;

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list -- oauth=40ietf.org
To unsubscribe send an email to oauth-leave=40ietf.org
=
--687cbd48_3e500d17_168ce--