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

Hannes Tschofenig <> Thu, 08 December 2011 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42FCF21F85CE for <>; Thu, 8 Dec 2011 07:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K-3reoZiZ5wO for <>; Thu, 8 Dec 2011 07:17:08 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 61CC621F8557 for <>; Thu, 8 Dec 2011 07:17:08 -0800 (PST)
Received: (qmail invoked by alias); 08 Dec 2011 15:17:07 -0000
Received: from (EHLO []) [] by (mp006) with SMTP; 08 Dec 2011 16:17:07 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Ez+dYrisEA/f9ZCPqOIwBbCpeInVpYpJXmdkoUt OvOrIAEzEaOtWA
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <>
In-Reply-To: <>
Date: Thu, 08 Dec 2011 17:17:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Michael Thomas <>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
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:17:09 -0000

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. 


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