Re: [OAUTH-WG] Permissions (Scope - Coming to a Consensus)

"Manger, James H" <> Mon, 03 May 2010 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C61028C1C3 for <>; Mon, 3 May 2010 06:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.17
X-Spam-Level: *
X-Spam-Status: No, score=1.17 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BZG6K6+0gOGJ for <>; Mon, 3 May 2010 06:57:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B49F28C1A0 for <>; Mon, 3 May 2010 06:57:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,319,1270389600"; d="scan'208";a="2476283"
Received: from unknown (HELO ([]) by with ESMTP; 03 May 2010 23:57:06 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5970"; a="1754130"
Received: from ([]) by with ESMTP; 03 May 2010 23:57:06 +1000
Received: from ([]) by ([]) with mapi; Mon, 3 May 2010 23:57:06 +1000
From: "Manger, James H" <>
To: Torsten Lodderstedt <>, Marius Scurtescu <>
Date: Mon, 03 May 2010 23:57:05 +1000
Thread-Topic: [OAUTH-WG] Permissions (Scope - Coming to a Consensus)
Thread-Index: Acro86qHE6Am1el/QFGbeFEM5WkUtAB0TZ9Q
Message-ID: <>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "OAuth WG (" <>
Subject: Re: [OAUTH-WG] Permissions (Scope - Coming to a Consensus)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 May 2010 13:57:28 -0000


> Scopes (~permissions) should be defined allong with the corresponding API.

But they aren't.
Lots of "APIs" -- particularly the most important/standard ones, like AtomPub, HTML itself, IMAP (?)... are already defined, or are defined separately from any permissions that one service chooses for their implementation.
Permissions can be coarse grained (eg have access / don't have access), or fine grained (eg can read green items on Fridays), or anywhere in between. If every client app always needs service-specific knowledge about how permission are arranged I don't think we can get much interop.

> Depending on the IMAP feature set you want to use there could be plenty of scopes,
ranging from "read users INBOX" to sharing scenarios, where users have 
access to other users IMAP folders.

[I am not sure that IMAP is a great example as I assume it isn't an HTTP protocol, but ignoring that]
I hope that if an IMAP service says "I support OAuth2", and a client app says "I understand IMAP and OAuth2" then they can interoperate with minimal config. The app may need an app-id/secret, it may need an URI to start at (perhaps even a complicated one), but I hope it doesn't also need a table of service-specific permission labels against every possible IMAP operation.

James Manger