How about if the openid.oauth.scope response parameter defined in
Section 9 be changed to be a more generic OAuth status indicator? It can
be used to indicate which scopes were authorized in the success case, or
it can be used as status/problem indicator if there was an error.
Perhaps the allowed values can be the same as the values defined in the
ProblemReporting extension.
http://oauth.pbwiki.com/ProblemReporting
Allen
Dirk Balfanz wrote:
On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Since the new hybrid draft spec doesn't affect the OpenID
association method, this is moot.
However, the spec should mention what SPs should do if the CK is
invalid (or doesn't match the realm) in the OpenID authentication
request. Presumably, the SP should continue servicing the OpenID
portion of the request, however, the response should indicate why
the OAuth portion of the request failed.
How about, to mimic what happens with association handles, we can
return in the response an openid.oauth.invalid_consumer parameter
instead of openid.oauth.consumer? It would mean that either the CK was
just wrong or that it didn't match the realm. Although at this point
it starts to get pretty complicated.
Does this error condition really need to be communicated back to the
RP? For development etc., it might be enough to just show an error
page to the user explaining what happened.
Dirk.
Allen
Dirk Balfanz wrote:
I'd recommend an error consistent with Section 8.2.4 in the
OpenID 2.0 spec, with a new error_code value indicating that
the either the CK or the realm was invalid. There may
actually need to be 2 errors, one to indicate that the CK is
invalid, and another to indicate that the CK is not valid for
the realm.
http://openid.net/specs/openid-authentication-2_0.html#anchor20
But Section 8.2 is about the association response. In the auth
response, we currently only have cancel or setup_needed. If we
invent another error condition there, we're no longer a pure
"extension".
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
