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

Michael D Adams <> Fri, 02 December 2011 02:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58EE51F0C5E for <>; Thu, 1 Dec 2011 18:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OLYBtJlSUTPj for <>; Thu, 1 Dec 2011 18:58:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 988CD1F0C35 for <>; Thu, 1 Dec 2011 18:58:12 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2989793ggn.31 for <>; Thu, 01 Dec 2011 18:58:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=QvacvTvHsp/bFC9uA/34NU8f3orFSRzbMflxudWuKPQ=; b=SD4G3a1e7nj0p8dnG3acX+g7HcRAyUt6pgHCUxv+8h9hDwJtWq7rVJKZed3FCddnTP NkuxBE6FPoiK5H1pfQTuN3sdKKfJ1FdQDoSrGaRo2hP9/G96ZQgWQPKmKmIfHrloujpc B835RHBkgX1BdrowG9JLcWatyxtwfjrCS35WE=
Received: by with SMTP id k36mr1111315anq.134.1322794692171; Thu, 01 Dec 2011 18:58:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Dec 2011 18:57:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Michael D Adams <>
Date: Thu, 01 Dec 2011 18:57:51 -0800
X-Google-Sender-Auth: L2-SQnGlqpNNAN1FiFIcxUCLPQY
Message-ID: <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Barry Leiba <>, 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 02:58:13 -0000

On Thu, Dec 1, 2011 at 6:27 PM, Stephen Farrell
<> wrote:
> On 12/02/2011 02:14 AM, Michael D Adams wrote:
>> Suppose an authorization server implements OAuth2 and has some
>> requirement that the MTI token type doesn't provide (as William Mills
>> suggested), so the server implements token type AWESOME in addition to
>> token type MTI.
>> Whenever a token is requested, the authorization server issues one of
>> type AWESOME.  Type MTI is never issued.
>> Why bother implementing type MTI if it's never used?
> That, I think, assumes that the requesting party only ever works with
> the AWESOME token-type issuer. Seems a shame to me that whoever wrote
> that code can't work with any other MTI token-type issuer as well, at
> least.

Sorry, I was unclear.  Suppose only issues token of type
AWESOME and only issues tokens of type MTI.  Suppose further
that client X understands how to handle both types of tokens and can
receive and use tokens from both and

My question does not concern the client.  My question is: Why should bother implementing type MTI if it will never issue such a

>> Additionally, the authorization server could not implement type MTI
>> but claim it did.  There's no way for a third party to verify the
>> claim since the authorization server never issues a token of type MTI.
> Irrelevant. I could claim to be handsome. Would work equally
> well.

I claim the argument helps show the meaninglessness of defining an MTI
token type, but I think my statement of it is poorly formulated and
trying to restate it more clearly will just take us down a road with
as much relevance to the discussion as you grant my initial statement
:)  So I concede.

>> If tokens of type MTI are never used by this server, how does the MTI
>> token type help interop?Is your argument that this server would say
>> "No, we do not support OAuth2.  We do, however, support
>> OAuth2+AWESOME."?  That semantic argument I understand, but I am
>> ignorant as to how/if it fits into the RFC.
> No, my argument is that there are many servers and many clients on
> the Internet and having them all have a way to interop, if they
> choose to do so, is a good thing in itself. Writing an RFC so that
> its a random pick as to whether they do or don't interop is not IMO
> a good thing.

Thanks.  I understand better what you're saying.  I believe you're saying:

1. In a world where there is a MTI token type, my hypothetical
only-issue-tokens-of-type-AWESOME has explicitly opted out of
2. In a world where there is no MTI token type, interoperability
becomes ad hoc and so non-existant.