Explicitly Typed Attribute Values

[Cantor, Scott]

> Does anyone know whether the Shibboleth IdP, as configured by default,
> explicitly types <AttributeValue> elements in outbound assertions?  And, did
> that ever change?

2.x always did and was not configurable.

3.x "defaults" to not doing so, but that's misleading because the "default" is still to include xsi:type, but we ship a default file that sets the encodeType property to false explicitly. The encodeType property defaults to true in the plugins so that a 2.x config does the same thing it did before.

> I ask because I’m working with a service that expects to see givenName
> forcibly typed as xs:string rather than xs:anyType, as is the default in the
> standard(2.7.3.1.1):

All SAML ever said about xsi:type was that you shoudn't set it to an extension type. It doesn't really preclude caring about built-in types like "string", and it's more like a bad idea than a bug.

> The typed ones were associated with transient NameID’s that looked like
> default v2, while the non-typed ones were associated with transients that
> looked like v3.

I don't know what transient IDs have to do with this.
 
> I don’t have providers of each type handy that I can use to verify that I’ve got
> all this right, but it looks like the largest wire-level change that I’ve
> encountered.

It's a difference between how two "from-scratch" systems behave, not a change. An upgraded IdP will not behave differently and the same configuration applied to both will not behave differently.

-- Scott