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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 02 December 2011 02:27 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 55D8D21F9543 for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 18:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.29
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xPayu-Ei5yM for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 18:27:51 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A072A21F9542 for <oauth@ietf.org>; Thu, 1 Dec 2011 18:27:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D38A71541B0; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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 scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hCf9PKtUCk8s; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
Received: from [10.87.48.9] (unknown [86.41.14.223]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4D49D1541AF; Fri, 2 Dec 2011 02:27:50 +0000 (GMT)
Message-ID: <4ED837A5.502@cs.tcd.ie>
Date: Fri, 02 Dec 2011 02:27:49 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <mike@automattic.com>
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>
In-Reply-To: <CAH-8B6toCiYMeMAe-ZiHCdPCLa_Xz5aa92JjkWh=p0tkRXNnhQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:27:52 -0000

Hiya,

On 12/02/2011 02:14 AM, Michael D Adams wrote:
> On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie>  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
least.

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

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

S.