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

Stephen Farrell <> Sun, 18 December 2011 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12DD121F84D6 for <>; Sun, 18 Dec 2011 11:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.669
X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id po9RkqT0ctxL for <>; Sun, 18 Dec 2011 11:04:19 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id D3A9221F84B7 for <>; Sun, 18 Dec 2011 11:04:18 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B65CB171CBF; Sun, 18 Dec 2011 19:04:17 +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=1324235057; bh=ZmLxnBwRgqxZ+W IpKTQq3oM9qMbpUisDZrAswss4+zA=; b=1sh9N8g4w5LWJvM7vaD0Bca6rzYp8y x9HmEiGOGHliYaeN0FehRoeCfMZqRW93TZnsUicbYnxpXnjgZd2ZKiACAiRrL7Ny pGRgC+ATNeCjhIXG72xdcijINf8fAoJL7Mw1Ld2oop4YkY9v8uys9sbamL2qNOtj tvsZ2xohV0oU6xJ0DTyvX3TXr1iX2XRhPrxzKMQIDnZzQqM7seEJnipWthnal0KE iBzpPfe9huMbRpeeOoXSISLj/OIXw0oRIWCpA3MvFrqFLGh/iSITHOK1AjaftNFk 9pX2sk7a+Yjf2qjJBY7gkVckzyIlO5fyLeMCU/jwfuEurGGeJZMHQOYg==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id G5snkQLyMesv; Sun, 18 Dec 2011 19:04:17 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 50DE3171C68; Sun, 18 Dec 2011 19:04:17 +0000 (GMT)
Message-ID: <>
Date: Sun, 18 Dec 2011 19:04:17 +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: Barry Leiba <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sun, 18 Dec 2011 19:04:20 -0000

On 12/18/2011 07:00 PM, Barry Leiba wrote:
> Closing out this issue:
>> 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.
> We do NOT have consensus to use that text, nor any other.  As I see
> it, the STRONG consensus of the working group is not to make any
> change with regard to text about which tokens to use or how to
> authenticate the client.  This issue is closed, and Stephen
> reluctantly accepts that he's in the rough on this issue... but leaves
> us with the warning that he expects other ADs, on their own, to raise
> this issue during IESG evaluation.  That might result in DISCUSS
> positions that we have to address at that time.

Just to confirm that the above is the case.

IMO I'm still right and the WG are still wrong:-) But let's see if
we can make progress in any case.


> Eran, I think this gets us done with the base-doc issues, and we
> should be ready for you to prepare a final version that can go into
> IETF last call (unless you're aware of anything I've missed).
> Barry