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

Barry Leiba <> Sun, 18 December 2011 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9628221F861E for <>; Sun, 18 Dec 2011 11:00:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.655
X-Spam-Status: No, score=-100.655 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, 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 ukp+B9dL91en for <>; Sun, 18 Dec 2011 11:00:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AB8FA21F85EF for <>; Sun, 18 Dec 2011 11:00:34 -0800 (PST)
Received: by yhjj72 with SMTP id j72so4362603yhj.31 for <>; Sun, 18 Dec 2011 11:00:34 -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=gW1uGUC4T1h5LWMvF9obxbOfYn3JMKvKmvYJFlvv8e0=; b=QAuYVcGp90jJ9/3AKuY9cBjxQkJQ7s0x43FuWKaS8UMB29GV7SUrbqVItqhcmZCkCw 8m5PPrXyVs7bNZRFny2dCl9YILg/BBwgEfXIjH2aPfJFsEuFKQyv+jSDHghl+XFlNHXM QyO6I+Mn5kCv4dLtBhA8jLzyvTyRGijHvv9mU=
MIME-Version: 1.0
Received: by with SMTP id d28mr23675579yhh.37.1324234834308; Sun, 18 Dec 2011 11:00:34 -0800 (PST)
Received: by with HTTP; Sun, 18 Dec 2011 11:00:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 18 Dec 2011 14:00:34 -0500
X-Google-Sender-Auth: Sz-yFSLhP9Nf44n1JiJtHU5qyOg
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: Sun, 18 Dec 2011 19:00:35 -0000

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.

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