This wasn't all that elegant, but seems to be working. The resolver ignores the DisplayName and DisplayDescription elements, and the transcoder service now processes those into transcoder rule properties, which works for the decoding into IdPAttributes.

For attributes produced by the resolver, the transcoder registry service exposes new lookup methods that return all of the names and descriptions to attach for an attribute ID, and it builds those maps as each TranscoderRule gets installed into it.

Last-in wins, so if multiple rules for the same attribute ID exist, the last value for a given language will be used.

This also changes the language support on those resolver elements to preserve country code.

Adding the display name support revealed the problem with the split protocol design, we'd have to attach the language metadata to every rule, so it's too duplicative.

It turned out to be a simple change to just prefix some of the properties, so "name" becomes "saml2.name", etc. and all the rules collapse, which seems more elegant in hindsight, even if makes ignoring protocols harder.

The "transcoder" property now becomes a space-delimited list of bean names and it creates a rule for each transcoder bean.

The configuration can stand more improvement.

We need to extend the legacy resolver parsing so that the rules it creates for decoding attributes attach the displayName and description material, and I need to study the implications for encoding...right now the new-style rules outside the resolver won't impact IdPAttributes created directly within the resolver, so displayName/description doesn't get attached unless the legacy resolver syntax is used. Not sure yet how to address that.

>I think we probably want to retrofit that in the resolver too

This opened a can of worms (it seems to be my role these last three weeks), so I opened for the whole disaster

Added displayName and description property support.

Multiple languages are handled a la:

displayName.en-US = name
description.en-US = desc

For now I left it supporting both lang and country code using the standard Java API. I think we probably want to retrofit that in the resolver too unless somebody remembers why we did language only.

Maturity level is sufficient to commit this back to master and chew on it there.

The out of the box state right now is "new install" mode with no parsing of the resolver for mapping rules. My expectation is we end up removing the current relying-party hacks on upgrades but end up adding in a hack for this to divert configuration from the shipped mapping files to the resolver on upgrades.

It's fine for a deployer to choose wiring up both sources of information, but an upgrade shouldn't see the mappings we supply in case they conflict or change behavior.