Explicitly Typed Attribute Values

[Nate Klingenstein]

All,

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

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):

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>

This led me to some curiosity about what other IdP’s were doing.  Turning to the world’s largest cesspool of metadata that publishes log entries, TestShib, showed both explicitly typed AttributeValue elements and non-explicitly typed AttributeValue elements.  The entityID’s indicated that five or so providers that I checked out were using Shibboleth.

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.

Default config in v3.2.1:

        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" encodeType="false" />

Default config in v2.4.5:

        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" />

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.

I’m working with this SP to see why they care about the type and encourage them to care less, but I hope someone has insights on whether something changed here and whether there’s any interoperability concern resulting from any such change.

Thanks in advance for all your efforts helping me,
Nate.