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

[Mike Jones <[e-mail]>]

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 http://tools.ietf.org/html/rfc3553 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 http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions 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: [e-mail] [mailto:[e-mail]] 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 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. 

Ciao
Hannes

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth