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. 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. 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). 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? [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
