Standardized OAuth 2.0 Scopes for Mail, Calendar, and Contact Access

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 January 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The OAuth 2.0 Authorization Framework [RFC6749] defines the "scope" parameter as a mechanism for limiting an application's access to a user's account. While effective, the lack of standardized scope values for fundamental internet services like email and calendaring has led to a situation where every major provider (Google, Microsoft, etc.) has defined their own proprietary scope URIs.¶

This forces client implementers to create and maintain a hardcoded list of provider-specific configurations, creating a high barrier to entry for new service providers and preventing seamless discovery and configuration for end-users. A user of a new groupware server, for example, cannot expect their favorite desktop client to "just work."¶

This document aims to rectify this by defining a set of common, interoperable scopes for groupware functions. These scopes are intended to be published by Authorization Servers in their metadata documents as defined in [RFC8414], allowing clients to discover them and request appropriate permissions dynamically.¶

2. Proposed Groupware Scopes

This specification proposes the following scope values. They are defined within the urn:ietf:params:oauth:scope namespace, which is the appropriate registry for IETF-defined OAuth parameters.¶

3. Security Considerations

The principle of least privilege SHOULD be followed. A client application SHOULD request the most granular scope necessary for its function. For example, a scheduling assistant application that only needs to find open time slots should only request urn:ietf:params:oauth:scope:calendar:freebusy.¶

Authorization servers MUST validate requested scopes and MUST NOT issue access tokens containing scopes that the user has not explicitly authorized for the client. The interpretation and enforcement of these scopes is the responsibility of the Resource Server (e.g., the IMAP or CalDAV server).¶

4. IANA Considerations

This document requests the registration of eleven new values in the "OAuth Scope Registry" under the "OAuth Parameters" registry.¶

Author's Address