Shibboleth Developers

[Tom Barton <>]

Some thoughts upon reading this...

. Does this problem really need shib? It's a real and common 
circumstance, but (1) there must be an alternative to federated 
solutions to guest network access, because many guests do not and will 
not originate from shibbolized environments (or a common federation, 
regardless of its architecture), and (2), given (1), building 2 
solutions to 1 problem, in which one of the solutions always works and 
the other does only sometimes, likely means that the solution that 
always works will be the only one much used and supported.

. Work in Europe has addressed the problem of referring authentication 
to a remote site to enable network access, although not with a shib 
architecture. Might be worth a look before substantial effort is spent 
on a new solution. I know that A-Select has this as a use case 
(http://a-select.surfnet.nl/), and I can't at the moment recall the name 
of that inter-realm RADIUS service that's somewhat widely deployed. And 
several TERENA countries have various national schemes.

. How would a user get or maintain a "portable handle object"? Doesn't 
this require planning ahead, ie, be not all that different than 
pre-registration from the perspective of peoples' busy lives and 
changing travel requirements? The alternative would seem to be that 
fresh ones are somehow maintained in users' browsers by origin 
infrastructure automagically.

. I don't know whether the latest JISC grant program (Circular 1/04: 
Call for Projects in Core Middleware) awarded a project that might 
address this use case with a shib style approach. Might be worth a note 
to Alan Robiette to find out, if certain readers of this list don't 
already know.

Keep on tilting!
Tom

David L. Wasley wrote:
> Here I go tilting at windmills again.