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

William Mills <> Sun, 11 December 2011 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BD7521F84C3 for <>; Sun, 11 Dec 2011 09:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.561
X-Spam-Status: No, score=-17.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PkI8ZvjTvcpO for <>; Sun, 11 Dec 2011 09:27:37 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 238F121F84BD for <>; Sun, 11 Dec 2011 09:27:36 -0800 (PST)
Received: from [] by with NNFMP; 11 Dec 2011 17:27:30 -0000
Received: from [] by with NNFMP; 11 Dec 2011 17:27:30 -0000
Received: from [] by with NNFMP; 11 Dec 2011 17:27:30 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 42247 invoked by uid 60001); 11 Dec 2011 17:27:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1323624449; bh=de2qcG96HdfH7IzZ2HR4T7PgQ6sboyYJnWi4JrRWZuM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IO/kekGjsb4bBVY/LxNSszBkGSJoUdP7AscxLA9EoLjIy0VMa8MxDNSq2Cjf9wY0nJI8yuYBjfMFo7OxUm0Y1EJvZkTSQd/IOkV6uWNSosKPi8z5Mmr7rKAwJg2/PxKqTrz9iGYzSHHgSvcdGk9JNHpsiAQioM0aZJ7XPJi+im0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gaH4v9ijgaUpkRw4Wm0eEG6h8qquywxuxEnWEijNCcC9XLiRYemkRHDRgUEHbd8su8/5WcXiXmfDepSebEDywHbMh1a0vPIlb/sgZqr/vYxZ5cJVdHKxC9/SHT6HL4Vp+ki3MB/ktzby2GZ7wzunb84bQG3r7IPD8OraivWJ2AY=;
X-YMail-OSG: ew13.YAVM1kFSerFi6xNzDs1lsubeSPeU9.h6eXVVZB9SPY HOKuqx.hJdrYfzvRqx7J2b36rzuLfSTEDAjevxmDuZAwBO7NIBmf.0lSxUke mraldRYv.en0LjpkZOQI4aH3qz6WkYFpV.SgSDSYyg9Oyqay2noGlT60jC2q rZ4gzwQjythj4DxcspAGpYFQgVuJDdzfZSypysn9dPPHGa4DO7c4uHrQwiTe L24Ny7bzl3DxXE3jl.vlsNRpa0dmQSRZ2pJnddm8j_.nN1q9MD6ZYftQm3co WRws51CgK7V13FtUWfwx6W6vq3ibNY.zlQOHZsomjVJqn2is4EQqo6X8m1Hz LMr2kuYu1Czcx8A9gmAxOuaJJlFa5PZR4DMehLnfkL0rhQ7N9wqf4ji8gt1. VNcUd_tWglbLiTVM-
Received: from [] by via HTTP; Sun, 11 Dec 2011 09:27:29 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Sun, 11 Dec 2011 09:27:29 -0800
From: William Mills <>
To: Leif Johansson <>, Paul Madsen <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-688701768-1323624449=:41873"
Cc: "" <>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Dec 2011 17:27:38 -0000

They are only compatible in the sense that they share the same security characteristics.

 From: Leif Johansson <>
To: Paul Madsen <> 
Cc: "" <> 
Sent: Sunday, December 11, 2011 3:28 AM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type

As an implementor of a toolkit let me offer this: the only use/requirement of mac that I've seen is for backwards compat with 1.0a. 

4 dec 2011 kl. 14:15 skrev Paul Madsen <>:

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
>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 
>OAuth mailing list
OAuth mailing list