attribute release: audit log vs assertion

[Peter Schober]

I'm trying to help a member from our consituency to pin down an issue.
Poking around in their IDP (4.1.2, upgraded from v3, OpenJDK 11 on
Debian 10) shows the following effects wrt attribute release:

I was trying to release samlSubjectID and samlPairwiseID[1] and I did
see them when using any of the following methods:

* the IDP's audit log
* aacli with JSON format (i.e., when not using --saml2)
* the consent UI in the subject's browser during WebSSO

But I did not see the attributes:

* using the aacli with --saml2
* in the decrypted SAML Assertion of an SP I control
  (that's set up to recieve these attrs and does so from other IDPs)

Now, the aacli difference (JSON vs. XML) seems to point towards an
issue encoding the attributes as XML.

While conf/attributes/default-rules.xml has an entry for the default
samlSubject.xml file the attribute registry is not being used at all
on an upgraded system -- which would explain the missing attributes in
the XML. Except that even after adding in some Encoders in the
resolver (and reloading, and having filter rules in place) they will
still not be released (according to aacli --saml2; I can't testing
using the browser having no credentials in LDAP).

Other attributes go out to the system just fine so metadata isn't the
issue.

Any idea where to look? I've been staring at this for too long so I'm
assuming something trivial like non-matching attribute ids (even
though I've checked). But I'm asking this here in case there's some
sublety with upgrades systems that I'm overlooking atm.

Thanks,
-peter

[1] Copy/pasted from my own documentation for our v4 deployments:
    https://wiki.univie.ac.at/display/federation/IDP+4+Attribute+resolution
    https://wiki.univie.ac.at/display/federation/IDP+4+Attribute+release