coming at it more from the IdP side Rod. Just trying to scope out what could go wrong if we advertised SAML2 on our IdP.

pros:
- WAYFless URLs we use should be ok and continue to work as they force Shibboleth (SAML1.1)
- SPs who use Shib 1.x should be ok as they only use Shibboleth

cons:
- SAML2 SPs wil break personalisations - this is guaranteed from what I've read so far
- non WAYFless access could break overnight if an SP upgrades to Shib 2.x and starts using SAML2. Personalisations would be lost and we would have no control over this. No opportunity to plan for personalisation migration.
- Suppliers who join the Federation with Shib 1.x software will drag out the pain of migration.

Presumably suppliers who wish to join the Federation will not be allowed to do so if they use Shib 1.x software.

-------------------
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig

On 25 Jan 2011, at 17:30, Rod Widdowson wrote:

> Alistair,
> 
> They will - but they will force SAML1 - which is (IMO) notably slower in the profiles we recommend.
> 
> Why not go for SP side hyperlinks?  If you support the DS protocol you support them already....
> 
>> -----Original Message-----
>> From: Discussion list for Shibboleth developments [mailto:[log in to unmask]] On Behalf Of
>> Alistair Young
>> Sent: 25 January 2011 16:06
>> To: [log in to unmask]
>> Subject: Re: Moving to SAML2
>> 
>> another issue that was lying heavy on my head was whether all the Shibboleth (i.e. SAML1.1) WAYFless
>> URLs would cease to work if an IdP advertised SAML2. Thinking about it, they should still work as they
>> are specifically Shibboleth URLs.
>> 
>> ------------------------------------
>> Alistair Young
>> Senior Software Engineer
>> UHI@Sabhal Mòr Ostaig
>> 
>> 
>> 
>> 
>> On 25 Jan 2011, at 13:55, Peter Schober wrote:
>> 
>>> * Sara Hopkins <[log in to unmask]> [2011-01-25 14:39]:
>>>> I should also point out that "Shibboleth" and "SAML1" are not
>>>> synonymous terms. Shibboleth is the name of specific software that
>>>> implements the SAML protocol. Shibboleth 1.3.x versions support
>>>> SAML1. Shibboleth 2.x versions support both SAML1 and SAML2.
>>> 
>>> I suppose the term "Shibboleth" as used will also need to include the
>>> Shibboleth protocol, i.e. support for SP-first requests when using
>>> SAML1.x. So that's slightly more than the software artifacts released
>>> by the Shibboleth project.
>>> 
>>>> That issue does *not* occur because SAML2 is being used. It occurs
>>>> when SAML1 is being used, and the IdP releases both old and new
>>>> forms of eduPersonTargetedID, according to the federation's
>>>> recommendations, and the SP (which is probably Shibboleth 2.x) has
>>>> been configured so that it automatically converts the old form to
>>>> the IdP!SP!hash-value encoding. This results in the corresponding SP
>>>> header variable having a semi-colon separated list of two identical
>>>> persistent ID values in that form. The SP application needs to be
>>>> able to handle this.
>>> 
>>> If someone cared about this, submitting a feature request/bug report
>>> for the Shib SP to not populate duplicate values (generally, or solely
>>> in this specific case) could avoid that problem altogether, I would
>>> think.
>>> But it seems clear that the current situation ("scoped targetedId")
>>> needs to be remedied at *some* point.
>>> 
>>> cheers,
>>> -peter