Shibboleth Developers

Comments and suggestions welcome.

The discussion  centered around identifying ways to improve the 
usability of the WAYF mechanism. There was consensus on this general 
principle -- "develop a variety of alternatives so that browser users 
rarely see the WAYF". We haven't yet seen a magic  bullet, a WAYF GUI 
design that would make this beast easy to use. Consequently its our 
strong sense that we should propose a variety of techniques that both 
Identity Providers and Service Providers could  implement to help 
users avoid seeing the WAYF.

Here's a list of the options  mentioned in yesterday's call as 
possible v1.3 deliverables:

1) Fully document  existing alternatives (eg campuses edit their 
library navigation pages so that links point to the local HS, with 
the info vendor as the target= value).

2) Implement the  persistent cookie  option. Add a checkbox to the 
current WAYF page that will cause the WAYF to set a persistent 
cookie,  rather than a session cookie. This means that users would 
encounter the WAYF once per Federation; successive trips to the WAYF 
(even after browser restart) would see the cookie and redirect on 
thru.....

We would have  to provide browser users with a mechanism to clear this cookie:

- some browsers provide a Preferences option for selectively editing 
and deleting cookies;  we  would have to document which cookie to 
remove.

- provide a url at the WAYF; accessing this url would delete the WAYF 
cookie. There's  no obvious way  to publicize this  url, however. 
Options identified so far include:

a) have the WAYF implement a short delay when it sees the cookie; 
wait for X seconds before redirect'ing to the HS. During this short 
(five second?) wait, the user  could click and stop the redirect, and 
choose a different IP.

b) add this "clear cookie" url to the Federation pages.....

c) suggest that  campuses add this url to their web sso login pages 
(see below for more info on this option)

3) (this text may need fixing....)

Implement the cookie profile, as described by Liberty, in Section 
3.6.2 of [LibertyBindProf] Cantor, Scott, Kemp, John , eds. "Liberty 
ID-FF Bindings and Profiles Specification," Version 1.2, 960 Liberty 
Alliance Project (12 November 2003). An overview of this mechanism 
can be found in section 4.5 of liberty-idff-arch-overview-v1.2.pdf .

Basically, this would allow a IP/SP to query a  WAYF/Federation, to 
determine whether the browser user has already established an origin 
within that Federation. (In Liberty, this  mechanism is used to 
determine whether the user has already established an identity with 
an Identity Provider.)

This could be used in a couple of ways:

a) Identity Providers (campuses) could inform a Federation that this 
browser user is from Campus X, which is a  member of Federation Y. 
For  instance, when a user successfully authenticates with  the SSO 
mechanism  at campus X (whether  triggered by Shib or not), that SSO 
mechanism might inform the Federation....

b) SPs  could silently query a Federation, asking  if the browser 
user is  from a member  institution.

4) Suggest to campuses that they extend their SSO systems to allow 
users to enter "@domain:  into the userid field. This would cause the 
SSO system to redirect the user to the WAYF,and  provide hint=domain 
as a parameter. The WAYF would do a search using domain as the 
pattern.