Re: [OAUTH-WG] Mandatory to Implement & Interoperability

Michael Thomas <> Thu, 08 December 2011 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB97121F8678 for <>; Thu, 8 Dec 2011 08:14:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uu9kJSjiQL9C for <>; Thu, 8 Dec 2011 08:14:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 93CC921F863E for <>; Thu, 8 Dec 2011 08:14:06 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id pB8GE1wo031248 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Dec 2011 08:14:02 -0800
Message-ID: <>
Date: Thu, 08 Dec 2011 08:14:01 -0800
From: Michael Thomas <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Hannes Tschofenig <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2274; t=1323360843; x=1324224843; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Michael=20Thomas=20<> |Subject:=20Re=3A=20[OAUTH-WG]=20Mandatory=20to=20Implement =20&=20Interoperability |Sender:=20 |To:=20Hannes=20Tschofenig=20<> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=YWw7I5FGcOhaLw6loauoZXbg8mXCXfceVVNzs5znSDI=; b=dsPJpoMUNA9a4HFTzozooQZ68aR/wXTikn2VES2K4paGXPH38CehBVPeXN TpqgfhiwgWWFzTolyH1AC/572S3c26NatQTTmMPkPihUbmp4giR2TgFv8Eqf gFq4FklwA4J2cZKMGGHPR1UM3sw9Wz5xZb8TZ7ldiHXorRZczuTWI=;
Authentication-Results: ; v=0.1; dkim=pass ( sig from verified; ); dkim-asp=pass
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Mandatory to Implement & Interoperability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Dec 2011 16:14:07 -0000

On 12/08/2011 07:17 AM, Hannes Tschofenig wrote:
> Hi Mike,
> I guess we are on the same page with regard to discovery/negotiation. I do not care so much how it is implemented as long it is there.
> While certain libraries may implement everything I don't think it is reasonable to assume that every deployment will have every functionality implemented. I would be super surprised. Even on a server with enough storage this is not a viable option. On constrained devices this is certainly not possible and our story cannot be built on such an assumption.

Considering that things using oauth are likely to have some sort of
browser rendering engine around, g*d help us all if an oauth library
becomes a flash space consideration :)


> Ciao
> hannes
> On Dec 8, 2011, at 5:08 PM, Michael Thomas wrote:
>> On 12/08/2011 06:18 AM, Hannes Tschofenig wrote:
>>> 3) We want the ability for algorithm negotiation/discovery, at least up to a certain degree. For example, it would would nice if a client talks to a server and they both implement TLS 1.2 then they actually use it. The requirement for crypto-agility fits in here as well.
>> I don't think that certain degree even needs to be all that
>> complicated. Suppose that in the future there exists a kitchen
>> sink liboauth which is widely available. As a service provider,
>> all I really care is that the client can interoperate with
>> me. So suppose I just generate a sdk that looks like this:
>> client--->MyServiceShim->liboauth ---------- liboauth->MyserviceShim--->server
>> No need for discovery or anything like that: it's baked into the
>> shim which I make available for all the usual suspect language
>> bindings. And it's still a better situation for the service provider
>> because they don't have to maintain liboauth... the shim becomes
>> nothing more than a the set of policy decisions that turn the
>> right knobs in the underlying library.
>> So did the MTI buy us anything in this -- rather likely -- scenario?
>> No. Whoever builds liboauth is almost by definition going to be
>> silent about winners and losers -- it's job is to implement everything,
>> not take sides.
>> Mike