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

Michael D Adams <mike@automattic.com> Fri, 02 December 2011 02:58 UTC

Return-Path: <michael.d.adams@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EE51F0C5E for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 18:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLYBtJlSUTPj for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 18:58:12 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 988CD1F0C35 for <oauth@ietf.org>; Thu, 1 Dec 2011 18:58:12 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2989793ggn.31 for <oauth@ietf.org>; Thu, 01 Dec 2011 18:58:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.101.208.36 with SMTP id k36mr1111315anq.134.1322794692171; Thu, 01 Dec 2011 18:58:12 -0800 (PST)
MIME-Version: 1.0
Sender: michael.d.adams@gmail.com
Received: by 10.101.116.15 with HTTP; Thu, 1 Dec 2011 18:57:51 -0800 (PST)
In-Reply-To: <4ED837A5.502@cs.tcd.ie>
References: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com> <CAH-8B6sjim_tcBkTPFWc1SnjhtHDQTR7sVT+aOjnYv7cs8JssA@mail.gmail.com> <4ED82D62.3070800@cs.tcd.ie> <CAH-8B6toCiYMeMAe-ZiHCdPCLa_Xz5aa92JjkWh=p0tkRXNnhQ@mail.gmail.com> <4ED837A5.502@cs.tcd.ie>
From: Michael D Adams <mike@automattic.com>
Date: Thu, 01 Dec 2011 18:57:51 -0800
X-Google-Sender-Auth: L2-SQnGlqpNNAN1FiFIcxUCLPQY
Message-ID: <CAH-8B6tDUsKB3zFNd5ks1Ff6yNB7ZBjaWOHGEoDkV=fsGjGYug@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Barry Leiba <barryleiba@computer.org>, oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2011 02:58:13 -0000

On Thu, Dec 1, 2011 at 6:27 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> 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 awesome.com only issues token of type
AWESOME and mti.com 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 awesome.com and mti.com.

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

>> 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
interoperability.
2. In a world where there is no MTI token type, interoperability
becomes ad hoc and so non-existant.