[OAUTH-WG] OAuth URN Registry Discussion Summary

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 23 June 2012 15:17 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A01E221F84A2 for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2012 08:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rzSJ6dwQ-eOE for <oauth@ietfa.amsl.com>; Sat, 23 Jun 2012 08:17:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net []) by ietfa.amsl.com (Postfix) with SMTP id A5DFB21F8499 for <oauth@ietf.org>; Sat, 23 Jun 2012 08:17:17 -0700 (PDT)
Received: (qmail invoked by alias); 23 Jun 2012 15:17:16 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO []) [] by mail.gmx.net (mp010) with SMTP; 23 Jun 2012 17:17:16 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+bl6g2CyubVzOglY11a/gUJ0Wrhz0l94jnjTTBdx eTM8LUaAnaWSiQ
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 23 Jun 2012 18:17:15 +0300
Message-Id: <575E933A-6FEF-4821-8677-319FE72564D7@gmx.net>
To: OAuth WG <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jun 2012 15:17:18 -0000

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 http://tools.ietf.org/id/draft-ietf-oauth-urn-sub-ns-03.txt) 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 http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ 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.