...
The configuration language has a flaw in that the <AttributeDefinition> element's sourceAttributeID is always optionally setoptional, but is very ambiguous in different situations. It should have been placed within the <Dependency> element but wasn't. As a result, it's either potentially ambiguous if all the depencies are themselves attribute definitions or explicitly needed if the dependencies are data connectors. Attribute definitions only produce a single attribute (so a dependency on them doesn't need further qualification), while data connectors can produce multiple attributes, with the source ID needed to disambiguate which one is meant as an input.
In V2, it was possible to omit the sourceAttributeID attribute when using data connector dependencies. While this may behave consistently if a connector produces only one attribute, it becomes underspecified if the connector is later modified to produce more than one. As of V3.2.0, this is no longer allowed and a warning will be emitted, and the resolution process will fail. You will need to specify an appropriate sourceAttributeID to correct the problem.
As of V3.4, all use of sourceAttributeID is fully deprecated, and the old <Dependency> element itself has been replaced by explicit use of <InputAttributeDefinition> and <InputDataConnector> elements.
XML Namespaces 3.3
In all versions prior to V3.3, the configuration will contain elements in multiple namespaces. With V3.3, every non-deprecated feature can be defined in the main urn:mace:shibboleth:2.0:resolver namespace (and thus defaulted to avoid the need for prefixes). The lone exception is the specification of security credentials when connecting to data sources (LDAP mainly).
...
The two exceptions are the Scripted Data Connector and the Scripted AttrinuteAttribute definitions, where the name has been extended and so xsi:type="dc:Script" should be replaced by xsi:type="ScriptedDataConnector" and xsi:type="ad:Script" should be replaced by xsi:type="ScriptedAttribute".
...
By default, any <AttributeDefinition> elements of types ad:TransientId or ad:CryptoTransientId will be parsed but generally will be superseded by the features described in NameIDConsumptionConfiguration, and the older definitions can and should be removed.
Persistent Identifier Data Connectors and Attribute Definitions
The use of attribute-resolver.xml to define Persistent (pairwise, opaque) identifiers using the ComputedId and StoredId connectors and the ad:SAML1NameIdentifier and ad:SAML2NameID attribute definitions is deprecated. The generation of persistent subject identifiers is now independent of the resolver, and is described in NameIDGenerationConfiguration.
The second use for these features involves the "eduPersonTargetedID" SAML Attribute, which contains a SAML <NameID> XML element in its value rather than just a string. The attribute use case is itself generally deprecated because SAML 1 itself is a legacy standard and because the use of the attribute in SAML 2 is redundant. However, at present there is no replacement mechanism for this use case, so the deprecation is more centered around the use case than the planned removal of these features.
PrincipalAuthenticationMethod Attribute Defintion
...
PrincipalAuthenticationMethod Attribute Defintion
The PrincipalAuthenticationMethod attribute defintion is deprecated because the support for managing multiple authenitcation methods throughout the IdP makes it impractical to expose a single method value.
Dependency Element
V3.4 has corrected some ambiguities surrounding this element with the new <InputAttributeDefinition> and <InputDataConnector> elements.