Technically, this could be solved in the RP for now, as that controls the claim going into the Transcoder.

Speaking to Scott, it might be OK for a patch to convert the LinkedTreeMapinto the expected JSONObject before it hits the transcoder.

Also, I’ll speak to @Henri about testing this from his real OP instance.

Certainly in the bigger picture, having a dedicated API to wrap and expose JSON messages is the closest analog to what was done for SAML, and the Transcoding layer was definitely designed around that idea.

One way around it might be to instantuate a delegating object implementing a dedicated marker interface and be able to get at the different representations we have to accomodate in the different cases, so the Transcoders would operate on that marler type but get at the guts via a separate method internally.

Then the transcoders would know for certain they were given an object intentionally to process.

This was not easy to test because the the OIDCStringAttributeTranscoderencodedType is a JSONObject. So, I did not go through the usual TranscoderRegistry and instead called the decodeValues method of the OIDCStringAttributeTranscoder directly with the LinkedTreeMap.

I think the best option here with the least change would be to add an if clause that tests for a Map and serialises that Map to a JSON string value (just as it does for a JSON Object).

Yes, the decode method does not understand that type, as you say. Both are java.util.Maps. I’ll take a look.