Shibboleth Developers

["RL 'Bob' Morgan" <>]

> The issue is, I guess, whether we want to replace the old request 
> protocol that was used as a placeholder up until now with a more 
> complete request message derived from the SAMLv2 spec. The motivation 
> (as I understood it) was to feature-enrich the 1.3 release to put it on 
> more equal footing with existing Web-ISO's that people have deployed 
> (e.g. A-Select, pubcookie, CAS, cosign, etc.)
>
> For me personally, the original full 2.0 timeframe of late 2005 is 
> livable for these features. I would favor doing this more because it's a 
> head-start on both the 2.0 work itself, and also forces some changes to 
> the code design to accommodate the multi-protocol behavior that we'll 
> need for other deliverables anyway.

As probably the main one beating the drum for this, let me just say 
briefly that it seems to me that the decision on whether to do this work, 
more or less as you've laid it out, as part of the 1.3 release, has to be 
looked at in the context of the overall SAML 2.0 transition plans (which 
obviously aren't very clear to us at this point).  This work might be a 
nice stepping-stone, which would be good, or it might be a big 
distraction, which would be bad.

I do think the feature gap is something of a problem now, so addressing it 
incrementally seems potentially better than waiting a year for a big-bang 
of SAML 2.0 support.  But I can also see that adding a bunch of 
Shib-specific 2.0-like features to Shib's SAML 1.x might mean never 
getting to 2.0, and would be non-standard junk that would have to be 
supported forever.  So I'm a little conflicted here.  I could imagine a 
"limited SAML 2.0 support" approach that might be cleaner; ie do real SAML 
2.0 formats in order to get the AuthnRequest features, but leave out other 
2.0 stuff so as to ship sooner.

 - RL "Bob"