Re: [OAUTH-WG] Token Transfer Protocol

Justin Richer <jricher@mitre.org> Mon, 18 October 2010 16:14 UTC

Return-Path: <jricher@mitre.org>
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 95EC03A6E0B for <oauth@core3.amsl.com>; Mon, 18 Oct 2010 09:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.503
X-Spam-Level:
X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 x-rX86vl3dmR for <oauth@core3.amsl.com>; Mon, 18 Oct 2010 09:14:31 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 752513A6E2E for <oauth@ietf.org>; Mon, 18 Oct 2010 09:13:36 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9IGF3Qe015677 for <oauth@ietf.org>; Mon, 18 Oct 2010 12:15:03 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o9IGF2gq015651; Mon, 18 Oct 2010 12:15:02 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 18 Oct 2010 12:15:02 -0400
From: Justin Richer <jricher@mitre.org>
To: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
In-Reply-To: <4CBC6FC0.5040708@cs.uni-goettingen.de>
References: <4CBC6FC0.5040708@cs.uni-goettingen.de>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 18 Oct 2010 12:15:02 -0400
Message-ID: <1287418502.6627.640.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Transfer Protocol
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, 18 Oct 2010 16:14:34 -0000

The ability to securely transfer tokens between systems is the last
missing part to the redelegation problem. Right now, we can have an
authorized client request a new access token with an equal or lesser
scope and be granted that with no user interaction. That token can then
be handed, using the below or similar mechanism, to another system for
its own access. I'm assuming this would work with tokens containing a
secret part (to be used for signing) as well as plain bearer tokens,
too.

 -- Justin

On Mon, 2010-10-18 at 12:03 -0400, Niklas Neumann wrote:
> Hello everybody,
> 
> I am currently working on a projected related to authentication and 
> secure token transfer between multiple devices. As such we are employing 
> a simple protocol that handles token transfers independent of the actual 
> type of token. We have adapted the protocol to be used with OAuth tokens 
> and submitted it as an Internet Draft: 
> http://tools.ietf.org/html/draft-neumann-oauth-token-transfer
> 
> I was wondering if there is interest in employing such a protocol in 
> cases where the HTTP redirection schemes of OAuth are not available or 
> not working well (e.g. desktop applications without access to a user 
> agent or authentication from a different device/application than the one 
> accessing the consumer).
> 
> Compared to other proposals such as 
> draft-dehora-farrell-oauth-accesstoken-creds the STTP is more 
> heavyweight but in turn it also has more options. With regards to 
> authentication we didn't use SASL for complexity reasons in our work 
> initialy but I don't see any reason not to include it if this is deemed 
> more appropriate.
> 
> The work that the draft is based on is still ongoing. Please understand 
> the draft as no more than a discussion proposal on how OAuth could be 
> opened to non-web-based environments and scenarios that involve multiple 
> devices without overloading the OAuth specification itself. I am happy 
> to further improve the draft if you think this might be a viable option.
> 
> Best regards
>    Niklas
>