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

Paul Madsen <> Sun, 04 December 2011 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B69E21F84B2 for <>; Sun, 4 Dec 2011 05:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9S-s8CeuY01 for <>; Sun, 4 Dec 2011 05:15:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 38B7E21F84B0 for <>; Sun, 4 Dec 2011 05:15:31 -0800 (PST)
Received: by qcsf15 with SMTP id f15so1190396qcs.31 for <>; Sun, 04 Dec 2011 05:15:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ues/FCxjNNLKOWPJk+yDmmmCm7x24xXVj+P0CyQPTMI=; b=DBzSZx2ZbY4QVFBuAzLobTUE+JjVrCwdxP9ll1LB4AqYVOhfNeFlaKsd4WKkpiAbBa jcof/isvJHFmmcqOTyST6c0MdhYd5gr4rVvba9DbiBbYIUppf/QsveODUeq4Pp47P/RA sLzgvcVBR5bAm8TZkjPbfBBQ1X8OblM8UhDEo=
Received: by with SMTP id g3mr1170312qci.23.1323004529186; Sun, 04 Dec 2011 05:15:29 -0800 (PST)
Received: from pmadsen-mbp.local ( []) by with ESMTPS id 8sm18754679qaf.9.2011. (version=SSLv3 cipher=OTHER); Sun, 04 Dec 2011 05:15:28 -0800 (PST)
Message-ID: <>
Date: Sun, 04 Dec 2011 08:15:26 -0500
From: Paul Madsen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070203090203090002040001"
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: Sun, 04 Dec 2011 13:15:32 -0000

Commercial OAuth authorization servers are neither 'toolkits' nor 
'purpose built code' - not used to build OAuth clients/servers but yet 
required to support more variety in deployments than a single purpose 
built server.

But, that variety is driven by customer demand, and none of ours (yet?) 
have demanded MAC. If and when that demand comes, we will add support.

To stipulate MAC as MTI would in no way reflect what the market wants. 
And 'interop' nobody wants is not meaningful interop.


On 12/3/11 4:37 PM, Barry Leiba wrote:
> Stephen says:
>> On 12/02/2011 03:20 AM, Barry Leiba wrote:
>>> Maybe what would work best is some text that suggests what I say
>>> above: that toolkits intended for use in implementing OAuth services
>>> in general... implement [X and/or Y], and that code written for a
>>> specific environment implement what makes sense for that environment.
>>> It seems to me that to require any particular implementation in the
>>> latter case is arbitrary and counter-productive, and doesn't help
>>> anything interoperate.  Whereas general-purpose toolkits that
>>> implement everything DO help interop.
>> That'd work just fine for me.
> OK, so here's what I suggest... I propose adding a new section 7.2, thus:
> -----------------------------------
> 7.2 Access Token Implementation Considerations
> Access token types have to be mutually understood among the
> authorization server, the resource server, and the client -- the
> access token issues the token, the resource server validates it, and
> the client is required to understand the type, as noted in section
> 7.1, above.  Because of that, interoperability of program code
> developed separately depends upon the token types that are supported
> in the code.
> Toolkits that are intended for general use (for building other clients
> and/or servers), therefore, SHOULD implement as many token types as
> practical, to ensure that programs developed with those toolkits are
> able to use the token types they need.  In particular, all general-use
> toolkits MUST implement bearer tokens [...ref...] and MAC tokens
> [...ref...].
> Purpose-built code, built without such toolkits, has somewhat more
> flexibility, as its developers know the specific environment they're
> developing for.  There's clearly little point to including code to
> support a particular token type when it's known in advance that the
> type in question will never be used in the intended deployment.
> Developers of purpose-built code are encouraged to consider future
> extensions and to plan ahead for changes in circumstances, and might
> still want to include support for multiple token types.  That said,
> the choice of token-type support for such purpose-built code is left
> to the developers and their specific requirements.
> -----------------------------------
> I think that expresses a reasonable compromise that might actually be
> followed and might actually do some good.  Comments?  Can we go with
> this and close this issue?  (And, sorry, I've been a Bad Chair, and
> haven't put this in the tracker.)
> Barry
> _______________________________________________
> OAuth mailing list