Shibboleth Developers

[Walter Hoehn <>]

The problem with this approach is that the selection mechanism presented 
by the WAYF is in no way standard.  The only thing about the WAYF that 
is specified is how it accepts query parameters from the target. 
Although this method might work very well with the InQueue WAYF, other 
folks setting up a shibboleth federation might not use our WAYF at all. 
 More specifically, if the federation only has a couple of origins that 
are part of a closely knit network, it might be easier just to have 
something much simpler that integrates more tightly with the existing 
interfaces.  The "sites file" format is not standard either, but I think 
it might be a better option to rely on it directly.  Anybody using the 
Internet2 supplied software will have it.  Other implementations will 
need metadata, which could be converted to this format, if necessary.

-Walter


Scott Cantor wrote:

> > Is it recommended that a non-html client parse the
> > xhtml's option elements (much in the same way it would
> > have to parse the xhtml form with the base-64-encoded
> > xml samlresponse from the HS).... or would direct
> > access to the WAYF's sites.xml file be provided at
> > some point?
>
>
> Direct access to the file is not a problem (it already is public), but the
> trick is that your web interface doesn't distinguish between your browser
> users and your Java client, and doesn't know to do anything different.
>
> I would think the optimum solution in the short term is to tweak the WAYF to
> sniff for a user agent or other HTTP header to signal to it that the
> presentation to the client should be XML. Perhaps just content negotiation
> via the Accept header, even.
>
> -- Scott

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature