Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt

Hannes Tschofenig <> Sat, 23 June 2012 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25DF321F8507 for <>; Sat, 23 Jun 2012 07:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.52
X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9TBA+cyhxiLH for <>; Sat, 23 Jun 2012 07:30:22 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 52EA521F842B for <>; Sat, 23 Jun 2012 07:30:22 -0700 (PDT)
Received: (qmail invoked by alias); 23 Jun 2012 14:30:20 -0000
Received: from (EHLO []) [] by (mp033) with SMTP; 23 Jun 2012 16:30:20 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19/DLZgC2R/8P+C1G6P1DZzqJfg+MDn79/R5Tr0kV OqM3lePUMkirZo
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Hannes Tschofenig <>
In-Reply-To: <>
Date: Sat, 23 Jun 2012 17:30:19 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Brian Campbell <>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: "" <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt
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, 23 Jun 2012 14:30:24 -0000

Hi Brian, 

Hi Brian, 

On Jun 21, 2012, at 11:48 PM, Brian Campbell wrote:

> On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig
> <> wrote:
>> Btw, in a discussion with Brian we check the policies for the three extensions in the OAuth core specification
>> 1) Section 8.3.  Defining New Authorization Grant Types
>> If you don't define additional token endpoint parameters then there is actually no requirement for expert review or a specification.
>> It is probably FCFS.
> That raises a different question/issue.
It is a related issue. 

The core document says you need an URI for defining new extensions and that means everyone can almost do whatever they want (as I tried to explain in this mail). Note that I saw "almost" -- as you will see below.  

> My understanding of the core spec was that it used URIs in extension
> points that might be profiled by actual specifications as well as by
> vendor-specific or other less rigorous implementations.


For the extensions that are registered under urn:ietf:params:oauth we do, however, need to define the policy. 

> To the extent that's true, §8.3 of OAuth core[1] is problematic in
> that it allows for any URI defining the grant type but requires
> additional parameters the grant type might use to be registered in the
> The OAuth Parameters Registry (and new grant types will most likely
> need additional parameters).

I agree with you. 

> Inf fact, I've already got a vendor-specific grant type that uses an
> unregistered parameter on the token endpoint - it's a simple grant
> type for access token introspection [2]. At the time I was thinking
> the parameter was implicitly qualified by the grant type and this was
> all okay. But looking at it again, per the letter of the spec, this
> would seem to be a violation. But what should we have done? How does a
> vendor-specific extension go about registering a parameter? Would that
> even be a good idea?

The URN you have chosen for your product ( is, however, IMHO incorrect. There is no URN registered that starts with (see but I am happy to be educated otherwise. 

You could have just used (or anything like that). The problem with that is that some folks will then try to do a lookup on this URI and will, surprise - surprise, not find anything because this URI is just meant for a different purpose. That's the only problem. 

Of course we could also allow a vendor specific branch in the URN we are defining (something which uses a enterprise id, see 


> [1]
> [2]