Since OpenID has a unique endpoint, the only thing separating direct from indirect requests is the openid.mode parameter. In particular, if it's missing the spec does not define how to handle errors. I would argue that in the absence of an openid.ns parameter, an OpenID 2.0 server also has no means to establish how to handle this error reporting feature.
So the error reporting covers the case where the request has valid openid.ns and openid.mode, the openid endpoint is correct, but something else about the request is not valid for some other reason. Most likely, the OP will then provide some feedback such as "The request you sent is invalid", in some default language for the OP. How much value is there in really implementing this feature? The error reporting feature also requires the OP to report the error code as 400, in violation of HTTP processing rules -- for instance, what if the nature of the error is that the server is overloaded? A 503 should be served then. I think for developers it would be much more useful to have test OPs that provide detailed error logs (e.g., entire exception stack trace, which production OPs often do not provide), so RP developers can use that for debugging. On Wed, Jan 6, 2010 at 06:47, John Bradley <[email protected]> wrote: > I stand corrected. A quick look back at the test results is not > encouraging. For direct errors I think Yahoo may be the only one I found > that passed. Google and MyOpenID are sending back something other than a > form encoded response. > > Others are trying to do a redirect to some other page etc. > > For indirect error responses Yahoo is returning the Direct error response. > I think that needs work! > > I think those tests were added after the last OSIS interop, so most people > haven't been through them. > > It is an area that needs some work. > > John B. > > On 2010-01-06, at 11:21 AM, Andrew Arnott wrote: > > 2010/1/6 John Bradley <[email protected]> > >> I have to admit that I have never tested OPs or RPs for processing error >> messages according to the spec. >> >> Another thing to add to the tests:) >> > > Actually we already have two tests on test-id.org: > OP sends properly formatted error responses to invalid direct request > messages <http://test-id.org/OP/DirectMessageErrors.aspx> > OP sends properly formatted error responses via redirect to the RP to > invalid indirect request > messages<http://test-id.org/OP/IndirectMessageErrors.aspx> > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
