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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EA2A11E8096 for <>; Thu, 1 Dec 2011 18:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.59
X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ajo7IUwMS3vG for <>; Thu, 1 Dec 2011 18:22:15 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id C859711E8081 for <>; Thu, 1 Dec 2011 18:22:15 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D700F1541AF; Fri, 2 Dec 2011 02:22:14 +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=1322792534; bh=vN9CF4S7qOPF7G epIo1ghJQnGvQJcSJgwD1LvyLpJbo=; b=x80hr1ildu8XON1HkLxTCJUHMrakD9 iy7Gk+YlOG67eObzRTw+SlZZEvCF/PD/k3eCmjaOOmevqdaMuOqbOhGExvGOpMAv BjGIhKIeqU7wZsLEVA2/LC6OXFyPFmRJzYRQfm93vqDGuUldoCe7Vdzoqao6jJrP iZZp39avtkHP8bUQ625tNdyI0GtX+0GPTL5JLzfkIMPH1ALAL6hI9BAjCOZSLrJP zJErVlbqTf8fJCr03PsS5/t/3AOy0x/ATlIED2DTCyIlAzNRlQJZBKe4BwSEh39j hzcItCHoF/puKHV54yk8wG9Sb/vViLRYvULMwOVMqNKJSZfMncSf8WvQ==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id 3hBe1iYxrA0a; Fri, 2 Dec 2011 02:22:14 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 21478153C7E; Fri, 2 Dec 2011 02:22:14 +0000 (GMT)
Message-ID: <>
Date: Fri, 02 Dec 2011 02:22:13 +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 Thomas <>
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:22:16 -0000

Hi Mike,

On 12/02/2011 01:35 AM, Michael Thomas wrote:
> On 12/01/2011 05:23 PM, Stephen Farrell wrote:
>>> E.g. MAC tokens work well for non-TLS protected resources. Bearer
>>> tokens in contrast are easier to use, but require TLS protected
>>> service to avoid theft-of-credential.
>> So picking is a nuisance sure. But it helps interop.
> This smacks of truth by blatant assertion.

Of course. My 2 sentences have 10 words. Yours has 7. Neither can
really capture everything.

Nonetheless, picking between one of two things does help interop

 > If something is required to
> be implemented but is unused -- which will happen if the profile
> chosen by the SDK doesn't need the required one -- you're not going
> to get better interoperability, you're just going to get untested code.

That'd be a fair point if the MTI wasn't used.

While that might be true of MAC, I doubt it'd be true for bearer,
which is what seemed to be the thing folks in the room in Taipei
would pick, had they to pick.

So yes, your argument would be telling if the WG chose a rare
beast as the MTI thing.

> I don't see what the big deal is about saying that discovery, etc, is
> for a -bis release of this PS. That would take care of your problem of
> reaching back into this PS to change just this part. And what are the
> chances of not having a recycle anyway with any well-deployed PS?
> Zero?

That's not a reason to not fix an easily fixable thing now though.

> |We disagree about that I guess. To me it seems a peculiar way to go
> |unless one assumes that coders write code that's specific to a specific
> |service provider.
> But that is exactly what's happening in the field.

To date yes. I would (perhaps naively) hope for that to get better
(by at least a bit) when we have an OAuth 2.0 RFC.


> Mike
> Mike