Re: [OAUTH-WG] OAuth URN Registry Discussion Summary

Mike Jones <> Sat, 23 June 2012 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2839021F84FF for <>; Sat, 23 Jun 2012 11:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.841
X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9eJVtx5v-tZK for <>; Sat, 23 Jun 2012 11:41:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4209121F84CD for <>; Sat, 23 Jun 2012 11:41:36 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Sat, 23 Jun 2012 18:40:02 +0000
Received: from mail59-va3 (localhost []) by (Postfix) with ESMTP id 3EE132201A5; Sat, 23 Jun 2012 18:40:02 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail59-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail59-va3 (localhost.localdomain []) by mail59-va3 (MessageSwitch) id 1340476800102220_28617; Sat, 23 Jun 2012 18:40:00 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 0FB2920009E; Sat, 23 Jun 2012 18:40:00 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 23 Jun 2012 18:39:59 +0000
Received: from ([]) by ([]) with mapi id 14.02.0309.003; Sat, 23 Jun 2012 18:41:31 +0000
From: Mike Jones <>
To: Hannes Tschofenig <>, OAuth WG <>
Thread-Topic: [OAUTH-WG] OAuth URN Registry Discussion Summary
Thread-Index: AQHNUVNNJXjHlh1ykkGDwKOQHsi2XpcIOhvw
Date: Sat, 23 Jun 2012 18:41:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth URN Registry Discussion Summary
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 18:41:37 -0000

I'd rather that we did the review based upon the current draft rather than rolling back.

Hannes, my point about three levels was that we can't necessarily know up front what the structure of URNs would be that might make sense to register in the future.  I was using that possibility as an example to object to a strict two-level hierarchy.  Sometimes a one-level name may make sense as well.

I agree with you that Section 3 of says about the colon character (":") defines a lightweight syntax for hexarchies to use when they make sense.  I just think it's overkill to put the hierarchy in the registry, per se.

I agree that in we should add IANA considerations text saying that any new extensions for client assertions should be registered with the name client-assertion-type:*.  Likewise we should figure out the right place to say that new grant types should be registered as grant-type:*.  These would be naming conventions though - not something that's a part of the registry.

				-- Mike

-----Original Message-----
From: [] On Behalf Of Hannes Tschofenig
Sent: Saturday, June 23, 2012 8:17 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary

As you have seen I have responded to various mails and I believe I understand what people want. 

Some of you obviously have plans to write extensions (in other organizations outside the IETF, and as vendor-specific extensions).  That's fine. 

You want something really lightweight (in terms of process) that does not require you to come to the IETF to write an RFC and get the entire working group excited about your hobby project. Clearly, this makes sense to me. 

So, the policy for adding new extensions has to be either 'Specification Required' or 'Expert Review' with the difference being about the information that goes into the registry. For the cases I have seen on the list it will not make a huge difference. It may make a difference for an organization where their final specifications are not publically available. Yes, these organizations still exist today....

Then, there is the question about how the identifier that gets registered should look like. You seem to like the idea of concept of a structured identifier (since otherwise you wouldn't be using it in various working group drafts already, including the example in draft-ietf-oauth-urn-sub-ns itself!) but you don't like to call it hierarchy because you fear that you will not be allowed to do whatever you want. An unjustified concern.

In that sense version -03 of the draft (see pretty much does already everything you want already do. As a policy it says "Expert Review" and it has the structure in the ID that you guys are using in your current drafts!

There are two options to go forward. 

The first one is to roll-back to version -03. 

Another option is to take version -04 and add text that explains the <id> a bit further by saying that it may contain a structure and other documents populating the registry will define the detailed structure of the <id> part. 

In we would then add a section to the IANA consideration section saying that any new extensions for client assertions needs to be registered under urn:ietf:params:oauth:client-assertion-type:

The same for urn:ietf:params:oauth:grant-type: in some other document and so on. 


OAuth mailing list