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

Barry Leiba <> Sat, 03 December 2011 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 309BB21F939E for <>; Sat, 3 Dec 2011 13:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.077
X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tT6xRiadv+ak for <>; Sat, 3 Dec 2011 13:37:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 953BC21F9343 for <>; Sat, 3 Dec 2011 13:37:41 -0800 (PST)
Received: by ggnk5 with SMTP id k5so502271ggn.31 for <>; Sat, 03 Dec 2011 13:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vWWKXAhBv0n8mLMy3pC5wlF9Nl2aSA9j32N+7cDzLsU=; b=uLVYSudaOVRePG98llF6cr+VYvnl/lXB7mqXttd7RgQuD8vDw7/pNYx8i2Jt5iEkA5 y+sBTejngGVggtZnwltb+OQPZBeepB+HzEZ6rm8Vo7ipAz8HpWXABmO98Eu4q9By+eUy oSxeI3p8UK/F+VV/3kBhDPNmz4ywq55p3hbnc=
MIME-Version: 1.0
Received: by with SMTP id n17mr693961anc.155.1322948261101; Sat, 03 Dec 2011 13:37:41 -0800 (PST)
Received: by with HTTP; Sat, 3 Dec 2011 13:37:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sat, 03 Dec 2011 16:37:40 -0500
X-Google-Sender-Auth: Fd6l5asj6Yj51DHT9lKWIsSMg6s
Message-ID: <>
From: Barry Leiba <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Sat, 03 Dec 2011 21:37:50 -0000

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

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.)