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

Brian Campbell <> Sun, 24 June 2012 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DAE621F868A for <>; Sun, 24 Jun 2012 06:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.992
X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZWZAZZ3Rp0EY for <>; Sun, 24 Jun 2012 06:45:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 69BDB21F8680 for <>; Sun, 24 Jun 2012 06:45:11 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Sun, 24 Jun 2012 06:45:11 PDT
Received: by obfk16 with SMTP id k16so6000265obf.29 for <>; Sun, 24 Jun 2012 06:45:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AJyjt4LdHXdeodkDwwa/vwZZ49r4iTrZZtEFYPBCWRk=; b=olKA92ZsE9dpGt/IBxYPUgichI2emZWgPaVhVZqOXWH6xHAJMDez6dPF4dFbVraDtj 7YCfC2Vk3gLIt2mfQPudIkNInOZU7q6kfcH4mwSwFTlddG7s9QnlTRdfGgM/UvppdXaX wOctzUDlUyH7kS23wEy/1ngwK/HNhSO8624WnzXteodoqwwZChglw9VvoNOjwapsXw4V PlcTHD5G6EWpls/tFDNvTbAHOXbbRdGpCTo7CaLrhSjG8HYpxpcGjHlSJSR1AP/Yh6/A wem/+xXZ1lvByhU2i1E+G7ftySYmpK7D5+ttcXO53neohyEzDeDf7iuPLB9YqI/gQZ+q j7GA==
Received: by with SMTP id b2mr4772600oee.41.1340545510285; Sun, 24 Jun 2012 06:45:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 24 Jun 2012 06:44:40 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Sun, 24 Jun 2012 07:44:40 -0600
Message-ID: <>
To: Mike Jones <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnrKlHLZ/SAdYvAiEq/c2jt+HzVLc5Q+rtDG0Of1/tmBDbEQMMqbOYsVg2RMRyTkQNXNO7n
Cc: OAuth WG <>
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: Sun, 24 Jun 2012 13:45:12 -0000

I concur.

RFC 3553 does say the "colon character (":") is used to denote a very
limited concept of hierarchy" and the current text in -04 uses the
colon consistent with that limited concept of hierarchy. However, as
Mike already said, the intent of is that it be a
general naming convention and not something that need be part of the

On Sat, Jun 23, 2012 at 12:41 PM, Mike Jones
<> wrote:
> 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.
>                                Cheers,
>                                -- 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.
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list