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 <james.h.man...@team.telstra.com> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
