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

Blaine Cook <> Fri, 02 December 2011 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 771ED21F9912 for <>; Fri, 2 Dec 2011 05:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4rXR8CbJiWkV for <>; Fri, 2 Dec 2011 05:10:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 621E921F9837 for <>; Fri, 2 Dec 2011 05:10:28 -0800 (PST)
Received: by ggnp4 with SMTP id p4so3495732ggn.31 for <>; Fri, 02 Dec 2011 05:10:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FdcALfY8rEwFJkDcflPvia/Udftfz5w7eb3DrnuUOaQ=; b=YzVXAmEXKvAyPm1MBLsnB5DX+Q1giqmVnPZfK8WQoaBL5YLk+bhWVMAvKJ9ayGi2Nj VyA9FxQfGGL6uRboWvUgfZLWyn9126V2d+kWSPs1yWBlifZw/89tS5/40G7hWJ+9DvgX oH+2ccNe32yJ223pGix0SxlNZrXEEh1Kf82GM=
Received: by with SMTP id t6mr2328536obt.2.1322831409320; Fri, 02 Dec 2011 05:10:09 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Dec 2011 05:09:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Blaine Cook <>
Date: Fri, 02 Dec 2011 13:09:48 +0000
Message-ID: <>
To: Barry Leiba <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: 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 13:10:29 -0000

On 2 December 2011 03:20, Barry Leiba <> wrote:
> Stephen is thinking that code will be reused.  Perhaps there'll be a
> limited number of coded toolkits, and their code will be used to
> implement various authorization servers, etc.  That's the way a lot of
> Internet code is done today.  In that case, Stephen posits, if we tell
> the toolkit writers that they MUST implement X, then at least when X
> is being used, implementations based on the different toolkits can
> always interoperate.  Lacking that directive, a toolkit that only
> implements X will be unable to interoperate with a toolkit that only
> implements Y.

My $0.02 (tl;dr: I agree with Barry):

Libraries are the point of code re-use for OAuth at the moment. If two
libraries (e.g., "Ruby OAuth" and "Java OAuth") implement all the
necessary bits of OAuth, then people using those libraries can expect
(or hope for) interop. We cannot force compliance, but we can mandate

If a service provider chooses to allow only a subset of OAuth's
functionality, and a general-purpose tool (i.e., NOT a library, though
perhaps written using a library) doesn't support that subset, then
obviously the implementations are not interoperable. However, more
likely than not, tools are designed to be used against specific
service providers OR other standards (which would in either case
mandate the way(s) in which to use OAuth).

SO, having Mandatory to Implement schemes in the general sense is pointless.
BUT, having BOTH Bearer and MAC be Mandatory to Implement for
general-purpose libraries IS useful, and will help interop (assuming
library authors bother to follow the spec).