[OAUTH-WG] Question about particular OAuth use case

David Fox <david@davidjfox.com> Thu, 08 March 2012 19:35 UTC

Return-Path: <david@davidjfox.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDD421F84C3 for <oauth@ietfa.amsl.com>; Thu, 8 Mar 2012 11:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTkSx6QFgP3o for <oauth@ietfa.amsl.com>; Thu, 8 Mar 2012 11:35:45 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E228221F84B9 for <oauth@ietf.org>; Thu, 8 Mar 2012 11:35:44 -0800 (PST)
Received: by obbta4 with SMTP id ta4so1201104obb.31 for <oauth@ietf.org>; Thu, 08 Mar 2012 11:35:44 -0800 (PST)
Received: by 10.60.4.162 with SMTP id l2mr3521416oel.3.1331235344548; Thu, 08 Mar 2012 11:35:44 -0800 (PST)
Received: from [192.168.0.195] (c-24-14-127-202.hsd1.il.comcast.net. [24.14.127.202]) by mx.google.com with ESMTPS id yv3sm3818044obb.3.2012.03.08.11.35.43 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:35:43 -0800 (PST)
Message-ID: <4F590A14.8050909@davidjfox.com>
Date: Thu, 08 Mar 2012 13:35:48 -0600
From: David Fox <david@davidjfox.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQl7seFFc80R6gFzRpQqpMGQ9Okhr7K77IL1U7VQ9muWtmlhF+emSlo3l+eT9luLh2dvF1lt
Subject: [OAUTH-WG] Question about particular OAuth use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 08 Mar 2012 19:35:46 -0000

Hello all, I have a question about a possible use case of OAuth.

The standard use case which is outlined thoroughly in the spec, is a 
client asking a resource owner for access to their information from the 
resource server. But, what about the case where a client/resource owner 
wants to share a particular resource with another, and potentially 
unregistered, user?

An example illustrating what I mean:

An application allows users to upload various templates of documents. 
And, by using an API, a user can send various types of media (e.g., 
tweets, FB pictures) to be inserted into said templates, thus creating 
new documents on the fly.
Now, imagine a user in this application has various customers they wish 
to give access to a certain template. To achieve this, the user creates 
a token for each customer -- which could be locked down to a certain 
template, IP, domain, number of uses etc -- and delivers each token to 
the corresponding customer.

Has anything like this been mentioned before? And if so, what was the 
suggested "dance?"
 From what I know, I'd imagine using bearer tokens and locking them to 
some of the conditions listed above would be best, but I'd like a more 
professional opinion.

Thanks,
-David Fox

PS, after re-reading the spec, I found a typo:
Section 2.1: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.1

The authorization server MAY provider tools to manage such complex 
clients through a single administration interface.

I believe this should be:
The authorization server MAY provide tools to manage such complex 
clients through a single administration interface.