Re: [OAUTH-WG] Mandatory-to-implement token type

Barry Leiba <> Fri, 02 December 2011 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FF3A1F0CAF for <>; Thu, 1 Dec 2011 19:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.124
X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pm7iSToRWaKp for <>; Thu, 1 Dec 2011 19:20:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90ABF1F0C93 for <>; Thu, 1 Dec 2011 19:20:23 -0800 (PST)
Received: by ywm13 with SMTP id 13so2997200ywm.31 for <>; Thu, 01 Dec 2011 19:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=baXdOTUySUuUSFDIomSAbfpEatKgUNuWyyMJnCZzvto=; b=SFvk4TDRXk29V6P/tBhwWD3lm3NzVYDfTvsCna2scvLuCSGjHmBldiDhyt0TUlBmN7 7dCg3tlbjY9EDudOAInr8ZetE2e6zV9nI4dkCwc0zd77MnnOVO1EQwo8mY/alXwomazc J07+hYAVW4Z8SaCeLe4cjDzbY8ePZmW/kK45w=
MIME-Version: 1.0
Received: by with SMTP id b42mr16134948yho.32.1322796023131; Thu, 01 Dec 2011 19:20:23 -0800 (PST)
Received: by with HTTP; Thu, 1 Dec 2011 19:20:22 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 01 Dec 2011 22:20:22 -0500
X-Google-Sender-Auth: 9XtWyjbtf4aa27QY4_DSqVSTdUY
Message-ID: <>
From: Barry Leiba <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: oauth WG <>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
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: Fri, 02 Dec 2011 03:20:27 -0000

>> So an MTI token type + no client preference is equivalent to there
>> only existing one token type.
> Maybe.
> However, no MTI token type + no client preference = no interop.

I think this exchange, coupled with what you Stephen said in Taipei
(noting that "mandatory to implement" doesn't mean "mandatory to
use"), points out a basic difference between how Stephen is thinking
about this and how at least some of the WG participants are.  Let me
see if calling this out helps:

Stephen is thinking that code will be reused.  Perhaps there'll be a
limited number of coded toolkits, and their code will be used to
implement various authorization servers, etc.  That's the way a lot of
Internet code is done today.  In that case, Stephen posits, if we tell
the toolkit writers that they MUST implement X, then at least when X
is being used, implementations based on the different toolkits can
always interoperate.  Lacking that directive, a toolkit that only
implements X will be unable to interoperate with a toolkit that only
implements Y.

Others are thinking that deployed code will be specific to a
particular environment, and it doesn't help at all for that code to
support X if the environment demands Y.  There's no interop benefit
from the "MUST implement X" directive if the code has been written
specifically for that environment, and, as Mike T says, it only
results in untested code and wasted development time.

I see both sides of this, but in the end I think what Mike says is
spot on, here.  I think it would be very nice to strongly encourage
toolkit writers to support all the available options, but there's
absolutely no reason to require, and no benefit in requiring,
purpose-built code to do anything of the sort.

Maybe what would work best is some text that suggests what I say
above: that toolkits intended for use in implementing OAuth services
in general... implement [X and/or Y], and that code written for a
specific environment implement what makes sense for that environment.
It seems to me that to require any particular implementation in the
latter case is arbitrary and counter-productive, and doesn't help
anything interoperate.  Whereas general-purpose toolkits that
implement everything DO help interop.

Barry, as participant