Exception handling [ was Version Handling [ was OpenID status
update ]]
Ben Hyde
bhyde at pobox.com
Mon Jun 6 15:26:54 PDT 2005
On Jun 6, 2005, at 5:09 PM, Paul Crowley wrote:
> In fact the protocol states that in many circumstances we won't tell
> the client what's wrong, we'll just refuse the request.
That's not actually the way I read it. openid.mode[1] is used to
signal errors. We need to be clearer that there are two kinds of
errors; the one the user has some chance of recovering from and the
ones that have to be resolved by the efforts of either the ID or the
client server.
It seems worthwhile to pull out the exception handling of the protocol
a bit more clearly.
The most common way that a failure occurs is because the ID server
can't sign off on the assertion. The reason for that failure are
numerous. Things like: "nope this browser isn't logged in" or "sorry
dude but your not allowed to know anything about Alice." The details
of these failures are must not be revealed to the client server; they
are private info between the user and her ID server.
We need a way to signal errors that are not of this kind, i.e. protocol
failures, or server down errors; i.e. ones that the user is not likely
to be able to resolve no matter how hard they try.
These errors are signaled back to the client server with the
openid.mode (what's the mode for this?) along with optionally
openid.user_setup_url. I suspect we need clearer advice to client
authors about how they deal at this point. If they want to continue to
attempt to auth the user they should present notice of a failure and
give the user the chance to A) give up, B) revise their OpenID URL, or
C) follow the user_setup_url.
Option C needs a bit more flesh on it. The user's browser should go to
user_setup_url where they get a chance to fix what ever went wrong.
Two issues need to be cleared up. First the user_setup_url must not
leak any particulars of what went wrong. Second the client server is
going to want to provide a return URL so he has some chance of getting
the user's attention back; otherwise client servers will pop up a new
window (bleck).
- ben
[1] it would be cool to get a single table of all the legal values of
mode (i.e. the nodes in the protocol state graph)
----
http://enthusiasm.cozy.org http://gibbon.cozy.org
tel:+1-781-240-2221
I forecast sunny weather!
More information about the yadis
mailing list