Shibboleth Developers

[Velpi <>]

> One other thing I wanted to note about this.  My hope is that this new 
> WAYF code would be usable within an SP and not need to be just a 
> standalone web app.  In other words, I'm thinking of something like a 
> taglib(s) a developer could use.
I think this was discussed earlier, but it is important in this context too.

My point of view:

If you look at the WAYF concept now, it tries to define a "federation". 
Technically is no such thing as a federation. So it tries to technically 
describe something that doesn't really exists...
The SP however is aware of the IdP's that it chooses to trust for auth, 
no matter what wayf might be used in the process.

By sticking to the current WAYF concept, there will probably become a 
need for super-wayfs or multiple wayfs with the same entries in the near 
future. Federations are starting to work together (see enable-vendor) so 
something like that will have to be built. This sounds like chaos to me.

Since each SP exactly knows which IdP's it wants, that feels like a more 
clean solution. I think it can fetch everything it might need from the 
metadata, so it would not cause an extra burden from either installation 
or maintainance (unlike a separate WAYF). And since metadata is 
configured at the current 'federation' level, the people that configure 
the list of IdP's stays the same, only now there might me more than one 
(combined) 'list' for one SP... without any complex setup through 
super-wayfs or so. In this case I would try to 'brand' or customize the 
WAYF as little as possible, since it would not belong to a federation. 
[so a smart default would be great in this case]


just my 2 cents


--Velpi