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 > <hannes.tschofe...@gmx.net> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
