[OAUTH-WG] issues with §8.3 grant type parameters? (was ... draft-ietf-oauth-urn-sub-ns-03.txt)

[Brian Campbell <[e-mail]>]

It was a design decision that seemed most appropriate given the
various factors and goals of my application at the time. My goal in
pointing to that was not to elicit feedback on the design itself but
to show that 'vendor-specific' extension grants will happen, and
already have happened, and that that might suggest a problem with the
text in §8.3 of the core spec. Do others see an issue here?

http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3

We can discuses the merits of the introspection as a grant type
approach if/when the WG chooses to take that on as a work item and to
the extent that approach is of interest. My colleague posted an
early/rough draft of that approach as an attachment to
http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html

On Fri, Jun 22, 2012 at 12:09 AM, Manger, James H
<[e-mail]> wrote:
>> In 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].
>>
>> [2]
>> http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter
>> s#GrantTypeParameters-1079271
>
>
> Why are you trying to overload this new functionality onto a URI used for other purposes?
> Why not just pick a URI specifically for your purpose, eg /as/validate?
>
> --
> James Manger