Re: [OAUTH-WG] Token Transfer Protocol

Niklas Neumann <> Tue, 19 October 2010 07:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24FF63A6C33 for <>; Tue, 19 Oct 2010 00:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shxwtadVLqfC for <>; Tue, 19 Oct 2010 00:40:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 510B93A6C1E for <>; Tue, 19 Oct 2010 00:40:41 -0700 (PDT)
Received: from ([] helo=[]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1P86pg-00029G-V7; Tue, 19 Oct 2010 09:42:05 +0200
Message-ID: <>
Date: Tue, 19 Oct 2010 09:42:08 +0200
From: Niklas Neumann <>
Organization: University of Goettingen
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Marius Scurtescu <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: (clean) by exiscan+sophie
Subject: Re: [OAUTH-WG] Token Transfer Protocol
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: Tue, 19 Oct 2010 07:40:45 -0000

In the project I am working on we are using discovery based on dynamic 
DNS but there probably are better ways. I felt that the discovery was 
rather application specific and didn't really fit into the draft but I 
am happy to expand if you think that will make things more clear.

Currently our (project-specific) workflow is something like this:
User wants to use (untrusted) public terminal to access a private 
resource. Instead of his username he inputs his authentication device 
address (i.e. DNS name of his mobile). Either the terminal or the server 
(depending on where the protocol is supported) uses the address to run 
STTP and then just substitutes the tokens STTP delivers as the user's 
The difference to a "normal" authentication is that all the "magic" is 
happening on the mobile device where the user is comfortable enough to 
use his actual credentials. For example, the device can use a 
service-specific API (or actually STTP again) to retrieve a one-time 
password that can be used (somewhat) safely on the public terminal. 
Facebook just started a service to send people otps to their mobile 
phone via text messages 
( which could be 
easily expanded to a more seamless (and world-wide available) 
authentication scenario using STTP (I am not affiliated with Facebook in 
any way, it's just an example).

Best regards

On 10/19/2010 01:19 AM, Marius Scurtescu wrote:
> Trying to imagine a real world use case.
> For example, section 2.2, how would the public terminal know that a
> user device exists, let alone where?
> Thanks,
> Marius
> On Mon, Oct 18, 2010 at 9:03 AM, 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:
>> 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
>> --
>> Niklas Neumann - University of Goettingen, Institute of Computer Science
>> Tel: +49 551 39-172053
>> _______________________________________________
>> OAuth mailing list

Niklas Neumann - University of Goettingen, Institute of Computer Science
Tel: +49 551 39-172053