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

[Hannes Tschofenig <[e-mail]>]

Hi Brian, 


On Jun 22, 2012, at 12:07 AM, Brian Campbell wrote:

> As far as the rest of the policy discussion, I have no interest or
> intent to define policy for this stuff. A year+ ago I needed a URI for
> the SAML grant type. It could be anything but it should be something
> stable. And it'd be nice if it was semi-meaningful.  I was using
> http://openid.net or something for a while and there were concerns
> about ownership and stability. Also because SAML grant was an IETF
> draft, it seed to make sense to have an IETF URI. I didn't know how to
> get one so I asked.

This all makes sense. 

> Eventually Hannes suggested the text that became
> draft-ietf-oauth-urn-sub-ns. A few more things came along that
> similarly needed URIs (JWT grant and client assertion auth) so it
> seemed to be working out well.

It indeed does work in the way you had envisioned. 

> Very little changed in that draft for
> nearly a year until the AD review yesterday brought up some
> deficiencies. I tried to address those in -03 today (and would like to
> do a -04 soon with the minor changes Mike suggested).

Fully understand that. 

With many drafts few people read through them in detail only when the last call for comment starts. 

> 
> With that said, all I really wanted was an easy way to reserve or
> register a stable and somewhat meaningful URI. It's proven not to be
> easy, however. Adding additional sub-registries and policy to
> urn:ietf:params:oauth, which will probably only ever have a few values
> in it,  seems to me to be unnecessarily adding a lot of overhead to it
> all.

What is the overhead? 

If you want a new URN for a new grant type then you 

1) pick an string that has not been used before (you see in the registry what others had put in there already. 
Example: foo-bar 

2) you stick it to urn:ietf:params:oauth:grant-type: 
Example: urn:ietf:params:oauth:grant-type:foo-bar

If you instead want to define a new assertion type you will have to stick it to urn:ietf:params:oauth:client-assertion-type:

Then, you send that request to IANA (with the template we defined in the draft). 

The only discussion point we are having is whether 
* you have to add a link to the specification that defines what this foo-bar grant type is, 
* whether there is any review following the registration. 

That's all.

Does not sound very complicated to me. 

> 
> Perhaps I'm mistaken but wouldn't Expert Review catch URIs that are
> just wrong prior to registration? And even if it didn't, what really
> is the harm?

With expert review you, for example, do not have to add a pointer to the specification to the registry. 
The expert obviously has to get the document since otherwise he wouldn't know what to do. 

In your example from above would you be OK to stick the link to the document into the registry? 


Ciao
Hannes

> 
> 
> 
> 
> 
> On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig
> <[e-mail]> 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.
>> 
>> 2) Section 8.1.  Defining Access Token Types
>> 
>> For URIs there seems to be no constraint either although the text talks about limited to vendor-specific implementations.
>> 
>> 3) client_assertion_type is created in http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-8.3
>> 
>> There is no description either for what is required to register a new assertion type into the URN class client_assertion_type.
>> 
>> (For client authentication mechanisms there is actually no registry in core and therefore there is no policy either.)
>> 
>> Ciao
>> Hannes
>> 
>> On Jun 21, 2012, at 10:12 PM, Hannes Tschofenig wrote:
>> 
>>> Hi Mike,
>>> 
>>> Thanks for your mail.
>>> 
>>> First, I would like to argue for a registry that has more than one level. We need a two level registry because the different extensions have (and will also in the future) have different extension policies.
>>> 
>>> The structure of the registry is: urn:ietf:params:oauth:<class>:<id>
>>> 
>>> On the first level, the <class> part, we have high level functionality that was defined in the core specification. This includes things like
>>> 
>>> 1) authorization grants (which you call grant-type in your registration request in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12)
>>> 
>>> So, this would be urn:ietf:params:oauth:grant-type
>>> 
>>> 2) client authentication mechanism (which you call client-assertion-type in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 but should rather mean something like client-auth-type)
>>> 
>>> So, this could be something like urn:ietf:params:oauth:client-auth-type
>>> 
>>> 3) Access Token Types (which is called 'token-type' in http://www.ietf.org/id/draft-ietf-oauth-json-web-token-00.txt)
>>> 
>>> This is urn:ietf:params:oauth:token-type.
>>> 
>>> [PS: The text in the http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.1 for registering new access token types is a bit confusing and I am not sure whether an absolute URI would actually be required even though it makes a lot of sense.]
>>> 
>>> While I believe that our initial requirement for "RFC required" for adding these top level classes makes sense since these basic extension features to OAuth are really core to the protocol functionality it is good that the group checks them carefully.
>>> 
>>> Then, at the <id> level the individual values reside. For the authorization grant this is 'saml2-bearer' as defined in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.
>>> 
>>> So, what is the right policy for adding values under urn:ietf:params:oauth:grant-type? http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 says what the policy is. So, instead of re-deciding a new policy for adding entries here it would be good to get it inline with what the policy is in the core spec.
>>> 
>>> What could go wrong if the two are not aligned? I actually had that case in the DIME working group. Without going into the details the registry had a much stronger policy (RFC required) than the protocol specification (which only required a specification, if I remember it). The consequence was that people couldn't easily register new values from other organizations since they would fail in the last step when a new registry value had to be created (since IANA then told them 'RFC Required'). Consequently, these other organizations who wanted to get their work done then avoided doing so by misusing other extensions, which was really not good.
>>> 
>>> Mike, you have actually been suggesting that a three level category for certain classes of sub-registries is actually OK as well. That may be true and we could relax the text to say that whoever defines the class also decides about the structure of the child elements underneath it.
>>> 
>>> What I believe we need to add in the document is to populate the registry with the three URIs (from above; referring to the classes) and pointing to the policy from the core specification. Then, other docs (like draft-ietf-oauth-json-web-token-00.txt) can just put their values in there.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> 
>>> On Jun 21, 2012, at 9:14 PM, Mike Jones wrote:
>>> 
>>>> This draft is much clearer.  Thanks for the quick turn-around.
>>>> 
>>>> One question:  You added:
>>>> *Index value: values subordinate to urn:ietf:params:oauth are of the from urn:ietf:params:oauth:<class>:<id> with <class>:<id> as the index value
>>>> Why bake the assumption of a two-level structure into the registry?
>>>> 
>>>> For instance, you could easily imagine legal and useful registrations of the form <class>:<subclass>:<id>, etc.
>>>> 
>>>> Maybe change this to say:
>>>> *Index value: values subordinate to urn:ietf:params:oauth are of the from urn:ietf:params:oauth:<value> with <value> as the index value.  It is suggested that <value> include both a "class" and an "identifier-within-class" component, with the two components being separated by a colon (":"); other compositions of the <value> may also be used.
>>>> 
>>>>                              -- Mike
>>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
>>>> Sent: Thursday, June 21, 2012 10:53 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt
>>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>>> 
>>>>      Title           : An IETF URN Sub-Namespace for OAuth
>>>>      Author(s)       : Brian Campbell
>>>>                         Hannes Tschofenig
>>>>      Filename        : draft-ietf-oauth-urn-sub-ns-03.txt
>>>>      Pages           : 7
>>>>      Date            : 2012-06-21
>>>> 
>>>> Abstract:
>>>>  This document establishes an IETF URN Sub-namespace for use with
>>>>  OAuth related specifications.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns
>>>> 
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03
>>>> 
>>>> A diff from previous version is available at:
>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-urn-sub-ns-03
>>>> 
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>