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

Allen Tom <atom@yahoo-inc.com> Mon, 03 May 2010 17:03 UTC

Return-Path: <atom@yahoo-inc.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8223F28C251 for <oauth@core3.amsl.com>; Mon, 3 May 2010 10:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.076
X-Spam-Level:
X-Spam-Status: No, score=-15.076 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_40=-0.185, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8czliLAzezB for <oauth@core3.amsl.com>; Mon, 3 May 2010 10:03:33 -0700 (PDT)
Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 65AE93A6A43 for <oauth@ietf.org>; Mon, 3 May 2010 10:03:29 -0700 (PDT)
Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o43H2mIL030491; Mon, 3 May 2010 10:02:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=O+2ZGckFFCFXVsQNpFv8IzEdJxlKpG93tgqY89YAU+I/oG8ND8bJYtaoEdyzXO6R
Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 10:02:38 -0700
Received: from 10.72.76.149 ([10.72.76.149]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 May 2010 17:02:38 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Mon, 03 May 2010 10:02:35 -0700
From: Allen Tom <atom@yahoo-inc.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Message-ID: <C8044FBB.2DADE%atom@yahoo-inc.com>
Thread-Topic: [OAUTH-WG] Permissions (Scope - Coming to a Consensus)
Thread-Index: Acro86qHE6Am1el/QFGbeFEM5WkUtAB0TZ9QAAdjDx4=
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126277CFE8@WSMSG3153V.srv.dir.telstra.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 03 May 2010 17:02:38.0190 (UTC) FILETIME=[6F2848E0:01CAEAE2]
Subject: Re: [OAUTH-WG] Permissions (Scope - Coming to a Consensus)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2010 17:03:34 -0000

On a related note, there's a group working on an OAuth2 binding for IMAP
(and other SASL based protocols) here:

http://tech.groups.yahoo.com/group/sasl_oauth/

Currently, we're trying to figure out how Mail clients are supposed to
discover what scopes they need. Also, most Mail clients would probably want
more than just "IMAP" scope, they probably also want to access other related
services, including SMTP, CalDAV, LDAP, Portable Contacts, etc.


Allen


On 5/3/10 6:57 AM, "Manger, James H" <James.H.Manger@team.telstra.com>
wrote:


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