Closing after release.

Thank you for including it! I will test the release candidate when it is released and report back if I find any bugs.

http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=3360
http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=3361

Thanks, I remember the conversation now.

I will be putting out a release candidate this week, possibly by tomorrow, so if you could test this I would appreciate it. You'll need to change your decoder type to Base64AttributeDecoder.

In the future, you should never use a simple string as a plugin type, as those are reserved by me. Use Java-style package naming to disambiguate your own extensions.

As I explained when I first brought this up on the mailing list (read the thread here: https://lists.internet2.edu/sympa/arc/shibboleth-users/2010-08/msg00360.html ), the setup that I'm working in, is encoding all attributes in base64 to avoid problems with special characters among other things. There was some discussion whether this was a valid reason for base64 encoding attributes, but the setup is as it is, and the functionality was needed, so I created the extension, and now hope to get it included to help others in a similar setup.
Just for reference, the IDP setup that requires the base64 attribute encoding is https://wayf.dk.
Simplesamlphp which is widely used with wayf.dk supports base64 attribute encoding out of the box.

What kind of data would be Base64 encoded, but still text-based and safe to expose via a header? My concern would be people using this to decode binary data, which would not work.