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

Michael Thomas <> Thu, 08 December 2011 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C96A21F8ACE for <>; Thu, 8 Dec 2011 07:08:08 -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=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mb-CGgAoLEhl for <>; Thu, 8 Dec 2011 07:08:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2949321F8ABB for <>; Thu, 8 Dec 2011 07:08:07 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id pB8F82hr005507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Dec 2011 07:08:02 -0800
Message-ID: <>
Date: Thu, 08 Dec 2011 07:08:02 -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=1334; t=1323356883; x=1324220883; 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=ZyDWxlDGfAQ45aOD3sjNNobuBM61DHocwybgw3IkDyc=; b=g04cmBJc9KRyDyzp+5rD5OgQ7cR8P3u/DB0GVbGb6JyetkfEdQTAZgQs6e x8NBT48EeoZ1T1pGlb2X9KYspvb1v8QWFdmlObUxJB3iI26oJ9z2wiHnHSF1 neYpYDd0DyGxXCzJNc1usc5TfacX7Y4UfDWXa2ex7ZxPuOMAAGTok=;
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 15:08:08 -0000

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

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.