what should happen when the user hits "cancel" in the selector?
RL 'Bob' Morgan
While testing the Shibboleth information card RP, I boldly hit the
"cancel" button in my DigitalMe selector. This gave me a low-level error
page (xmltooling::XMLParserException, fatal error during XML parsing:
Invalid document structure) from the RP. This is obviously suboptimal,
though presumably fixable in this implementation. Chatting with folks
here, though, it seems that browser/add-on protocol behavior in the
"cancel" case is not well-specified. It seems to me that from the app
point of view "cancel" is not just some random error, it is a particular
user behavior that a well-behaved app should try to handle gracefully (eg,
offer other authn methods, or helpdesk links, or something).
By way of discussion: I observe that "cancel" is a feature that selectors
have (I suppose they must all have a "cancel" button, right, to let the
user escape from the selector UI?) that, in my experience, the web-form
login pages used in redirect-signon schemes (SAML, openid, all the
homegrown ones) don't have; nor do the protocols support the concept.
That is, in SAML there's no protocol message for "user visited IdP but
didn't authenticate". If the user arrives at a login web page and can't
or doesn't authenticate using it, it's up to the user to go back to the
originating app (and often the back button doesn't work to do this) or
whatever else they want to do. This ends up placing the burden on apps to
be very careful about how and when they redirect users for authentication,
which I'd say is the opposite of what we want apps to do.
Does it seem to others that "cancel" behavior in information cards needs
more standardization (or is it standardized already and I'm just not aware
of it)? If so should this be done in the IMI TC?
- RL "Bob"
Pamela Dingle
Eric Norman
On Apr 19, 2009, at 5:56 PM, RL 'Bob' Morgan wrote:
> By way of discussion: I observe that "cancel" is a feature that
> selectors
> have (I suppose they must all have a "cancel" button, right, to let the
> user escape from the selector UI?) that, in my experience, the web-form
> login pages used in redirect-signon schemes (SAML, openid, all the
> homegrown ones) don't have; nor do the protocols support the concept.
> That is, in SAML there's no protocol message for "user visited IdP but
> didn't authenticate". If the user arrives at a login web page and
> can't
> or doesn't authenticate using it, it's up to the user to go back to the
> originating app (and often the back button doesn't work to do this) or
> whatever else they want to do. This ends up placing the burden on
> apps to
> be very careful about how and when they redirect users for
> authentication,
> which I'd say is the opposite of what we want apps to do.
This sound to me like you're exposing a flaw in the redirect-signon
schemes
(SAML, OpenID, etc). Is that your intent?
> Does it seem to others that "cancel" behavior in information cards
> needs
> more standardization (or is it standardized already and I'm just not
> aware
> of it)? If so should this be done in the IMI TC?
Doesn't "cancel" mean that a user wants to terminate the process in
which
they are engaged? I.e. "I changed my mind and don't want to do that".
Let
me put in this way. If it doesn't mean that to a user and it isn't
handled
gracefully (by whatever mens), then the designers go on Santa's
"naughty"
list. Those comments are not peculiar to information cards. There's
already a "standard" for information cards to follow.
So, to answer the question you asked in the subject line, the user has
started a process by pushing some kind of "login" button. "Cancel"
should
terminate that process and to be graceful, should return the user to
where
they were as if that button had never been pushed.
Eric Norman
RL 'Bob' Morgan
On Sun, 19 Apr 2009, Pamela Dingle wrote:
> I had thought that the selector was supposed to return control silently
> to the RP, without posting a token?
Sorry, I'm slow(er) today. The sequence is:
1. browser sends GET (or whatever) to server
2. server sends response to browser with embedded trigger(s)
3. browser sees trigger, invokes selector
4. user clicks cancel in selector UI
5. ?
Does 5 involve the browser sending something to server? If so, what
should it be?
- RL "Bob"
Markus Sabadello
5. selector UI disappears from the screen, <form> gets submitted, but without a token
6. user sees a different page in browser. in the best case the page says "you didn't submit a token", in the worst case it displays an exception stack trace
What should happen instead:
5. selector UI disappears from the screen and nothing at all happens in the browser
6. user still sees the same page as before in browser. user can trigger selector UI again by clicking the same purple-i button as before
Markus