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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D5C811E80A6 for <>; Thu, 1 Dec 2011 18:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ozLYkBl5YhUk for <>; Thu, 1 Dec 2011 18:14:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 876A311E8114 for <>; Thu, 1 Dec 2011 18:14:31 -0800 (PST)
Received: by ghrr18 with SMTP id r18so2940151ghr.31 for <>; Thu, 01 Dec 2011 18:14:31 -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; bh=Kw5c2pCvRJBel9p660D+EzlqjBUiSeBmOW2xnBIQHXA=; b=DKYUSE3VM2zKoM/2i+bylSIn7CAsU0pxQchHdaSsja9olnszFbFKS01nsOTBI0f1K1 /T9VpTP6RDJp5lg1q6rm2G6pT18GCDlPvVryWkh+NEG/Hm+ZTJHqX9szkbEB5yww0o7Y iQQZXhmvLWCPVEgvu4GXKTRaBhC+qYhd4sCOI=
Received: by with SMTP id b61mr15562428yhn.116.1322792071193; Thu, 01 Dec 2011 18:14:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Dec 2011 18:14:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Michael D Adams <>
Date: Thu, 01 Dec 2011 18:14:10 -0800
X-Google-Sender-Auth: 4GLdOkdMHQn2T_jOfXUg1FW51Xc
Message-ID: <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
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:14:32 -0000

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.

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?

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.

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.