Shibboleth Developers

[Ian Young <>]

On 25 Aug 2010, at 20:29, Scott Cantor wrote:

>> Well, I think the problem is that there is quite a large SAML 1 only
>> install base right now and a lot of them aren't show much sign of
>> moving.  We still know there are a significant number of folks running
>> Shib 1.3 and many of the other opensource IdPs are are SAML 1 only.
> 
> I guess a compromise with possibly useful side effects is not supporting
> queries, so people would have to push attributes in the client with no
> encryption. That seems to bug people, so I guess that's a way of
> accomodating without encouraging.

It bugs some people (well, all right, it bugs *me*), but in my experience it 
doesn't bug the *right* people (i.e., most deployers).

I wouldn't like to see the Shibboleth project go down the road of shipping 
software that was only capable of running SAML 1 in what I'd regard as a 
potentially insecure mode.  If the choice was to either only support SAML 1 
with unencrypted attribute push or not support SAML 1 at all, I'd prefer to 
see no support for SAML 1.  At least then potential deployers don't have to 
understand the potential attacks in detail, and can make their decision as to 
whether to use the software on the simple basis of whether they need to talk 
to SAML 1 IdPs or not.  Of course, you may lose some potential users that way 
but at least you're not depending on deployers to make informed judgements 
about fairly obscure threat models before picking the software they use.

Obviously, I'd actually *prefer* that any Java SP supported the same profiles 
that the current native SP does, to avoid this kind of discussion entirely.  
People will make the assumption that the native SP and Java SP have roughly 
the same capabilities whether it's true or not, and making it true is 
probably a better way to avoid surprises than trying to educate people about 
the differences would be.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature