Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23 (Henry S. Thompson) Thu, 08 March 2012 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B21F921F8648; Thu, 8 Mar 2012 03:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EZ2943PhRPfp; Thu, 8 Mar 2012 03:45:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9761F21F8647; Thu, 8 Mar 2012 03:45:34 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.4) with ESMTP id q28BifJH019389; Thu, 8 Mar 2012 11:44:46 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q28BiemO013576; Thu, 8 Mar 2012 11:44:40 GMT
Received: from (localhost []) by (8.14.4/8.14.4) with ESMTP id q28BiejW003264; Thu, 8 Mar 2012 11:44:40 GMT
Received: (from ht@localhost) by (8.14.4/8.14.4/Submit) id q28BidJX003259; Thu, 8 Mar 2012 11:44:39 GMT
X-Authentication-Warning: ht set sender to using -f
To: Barry Leiba <>
References: <> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
Date: Thu, 08 Mar 2012 11:44:39 +0000
In-Reply-To: <> (Barry Leiba's message of "Wed, 7 Mar 2012 18:53:37 -0500")
Message-ID: <>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Edinburgh-Scanned: at with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on
Cc: "" <>, "" <>, "" <>
Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
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: Thu, 08 Mar 2012 11:45:36 -0000

Barry Leiba <> writes:

> Henry says...
>>> No, I appreciate that you want to use registered short names in
>>> the protocol, that's just fine.  My problem is that you have left
>>> users, developers etc. with no way to discover what shortnames
>>> have been registered short of a non- trivial and error-prone
>>> informal search effort.
>>> . . .
> Eran says...
>> Not sure I understand what you are asking for, but what would the
>> IANA instruction include to support this?
> Yeh, I'm not understanding this either.  The spec establishes an
> access-token-type registry, and anyone will be able to look in that
> registry the same way they look in any other IANA registry, such as
> media-types.  It looks like Henry is asking for this to use some sort
> of type/subtype mechanism, as media-types does, wherein when a new
> token type is registered, that registration or subsequent ones can
> create subtypes of that token type.

No, sorry, not at all about subtyping or anyting like that.

Sorry this is proving difficult to communicate!

Start again.  Consider the situation five years from now, when OAUTH2
is a great success, and there are dozens of entries in its various

 1) Suppose you're a developer, setting out to implement OAUTH2.  You
    need to know what access token types, etc. to implement;

 2) Or you're a user, wondering what access token types are available,
    so you can decide which suit your requirements best;

 3) Or you're a service provider, and you come up with a new token
    type and want to check if the name you have in mind is already in

You have read the spec., and the _only_ concrete thing it tells you
about the registers is the name of an email list.  So you have to go
to the email archives and search for . . . what exactly?  Different in
the three cases above, and in none of them is it obvious how to know
what counts as success.

So what I'm asking for is more mechanism, documented in the spec. in
terms of what the registry itself will provide, which is, in each
case, a URI which will not only resolve to a list of the registered
shortnames, but will also support retrieval for any registered short
name by appending it.  So for example for the access token type
registry, the spec. should tell me that retrieving

will give me a page listing all the registered access token types, and

will return the registration details for the bearer type.

This will then make all of (1)--(3) easy.

Better this time?

       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail:
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]