Shibboleth Developers

["RL 'Bob' Morgan" <>]

> > Hmm, what is a SAML SP other than an implementation of the SAML web browser 
> > signon profiles?
>
> An implementation of the other profiles?

What other profiles would those be?  You mean ECP?

> > What functionality would be provided to support non-web applications? 
> > WS-Sec SAML token profile?  Seems like support for use of SAML in non-web 
> > scenarios would be in opensaml, or in code specific to those scenarios.
>
> This isn't defined yet, as the email said.  A project I'm working on 
> happens to use WS-Security with the ECP profile, others I'm sure will 
> use other things.  My assertion was that people were more likely to try 
> to do that stuff with this code base than the C++ one.

You are offering a design principle based on this assertion (which is 
reasonable as far as it goes) and I'm saying that it is hard to understand 
where this principle leads if the non-web profiles aren't defined yet.

> > As long as I'm thinking about it, is WS-Fed support going to be in the 2.0 
> > Java SP?
>
> At this moment I'm not planning on anything other than SAML support.  I 
> can't imagine why we'd support WS-Fed when the author of the "spec" 
> isn't going to.

Eh, what?  Do you mean Microsoft?  They continue to support WS-Fed.  If 
you're thinking that their touting of CardSpace/id-metasystem means 
they're abandoning WS-Fed, this is not true at all.  They're quite 
unrelated, except as being different approaches to the broad problem of 
user identity.

 - RL "Bob"