<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Since the new hybrid draft spec doesn't affect the OpenID association
method, this is moot.<br>
<br>
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.<br>
<br>
Allen<br>
<br>
<br>
Dirk Balfanz wrote:
<blockquote
cite="mid:60c552b80811182200w46d096e8i73500d9ec0670702@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
</blockquote>
</div>
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.<br>
<br>
<a moz-do-not-send="true"
href="http://openid.net/specs/openid-authentication-2_0.html#anchor20"
target="_blank">http://openid.net/specs/openid-authentication-2_0.html#anchor20</a><br>
</blockquote>
<div><br>
</div>
<div>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". </div>
<div> </div>
</div>
</blockquote>
<br>
</body>
</html>