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

Stephen Farrell <> Fri, 02 December 2011 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55D8D21F9543 for <>; Thu, 1 Dec 2011 18:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.29
X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4xPayu-Ei5yM for <>; Thu, 1 Dec 2011 18:27:51 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id A072A21F9542 for <>; Thu, 1 Dec 2011 18:27:51 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D38A71541B0; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1322792870; bh=/XouGbHeMmjEok zK/VeSgAwFF847w6AKSe+Fa7rGYoQ=; b=1gYbfdANEx1SbrJ9am4IhJjmIDIDsR tlaxQMBRQtIR2/sReMSXjq/PvSZNTWVX/hqQ4cq/w1nM6os2F63WBRuPTt/irJM6 WTiXveJio7gjT5cCFAwUfqcyX1jgNOiVw53IUHLPDj5Ru2Kjw6amFlSL9//2R0+W T9tm9AFGmYiEIPJ9V0yfjgiJg4xnSIfP02zuPMOz+B8SevHibOHDrhH1jORD6/II KJ7nmViusyfRmEmXmHRKGs0jizVBdF7K4o4ufyr8bWqcKhFeP12UDIeQP7hXQtsb tO+v9Uj6bzr8eN+LnkrBOoaQtlI8HA2bETAy7JC9shGQsBuMDU9fLblw==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id hCf9PKtUCk8s; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 4D49D1541AF; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
Message-ID: <>
Date: Fri, 02 Dec 2011 02:27:49 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Michael D Adams <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:27:52 -0000


On 12/02/2011 02:14 AM, Michael D Adams wrote:
> On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
> <>  wrote:
>> On 12/02/2011 01:38 AM, Michael D Adams wrote:
>>> 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.
>> So I don't get your argument. (When thinking of interop.)
> I think it's me that doesn't understand your argument.

That can be mutual:-)

> 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

> 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

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