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

[Hannes Tschofenig <[e-mail]>]

Hi Brian, 

Hi Brian, 

On Jun 21, 2012, at 11:48 PM, Brian Campbell wrote:

> 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.
> 
> 
> That raises a different question/issue.
It is a related issue. 

The core document says you need an URI for defining new extensions and that means everyone can almost do whatever they want (as I tried to explain in this mail). Note that I saw "almost" -- as you will see below.  


> 
> My understanding of the core spec was that it used URIs in extension
> points that might be profiled by actual specifications as well as by
> vendor-specific or other less rigorous implementations.

Correct. 

For the extensions that are registered under urn:ietf:params:oauth we do, however, need to define the policy. 

> 
> To the extent that's true, §8.3 of OAuth core[1] is problematic in
> that it allows for any URI defining the grant type but requires
> additional parameters the grant type might use to be registered in the
> The OAuth Parameters Registry (and new grant types will most likely
> need additional parameters).

I agree with you. 

> 
> Inf fact, I've already got a vendor-specific grant type that uses an
> unregistered parameter on the token endpoint - it's a simple grant
> type for access token introspection [2]. At the time I was thinking
> the parameter was implicitly qualified by the grant type and this was
> all okay. But looking at it again, per the letter of the spec, this
> would seem to be a violation. But what should we have done? How does a
> vendor-specific extension go about registering a parameter? Would that
> even be a good idea?

The URN you have chosen for your product (urn:pingidentity.com:oauth2:validated_token) is, however, IMHO incorrect. There is no URN registered that starts with urn:pingidentity.com (see http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml) but I am happy to be educated otherwise. 

You could have just used http://www.pingidentity.com/oauth2/validated_token (or anything like that). The problem with that is that some folks will then try to do a lookup on this URI and will, surprise - surprise, not find anything because this URI is just meant for a different purpose. That's the only problem. 

Of course we could also allow a vendor specific branch in the URN we are defining (something which uses a enterprise id, see http://www.iana.org/assignments/enterprise-numbers). 

Ciao
Hannes


> 
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3
> [2] http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameters#GrantTypeParameters-1079271