Version 2.2.0 of oidc-common did not end up implementing the decode function on OIDCScopedStringAttributeTranscoder. My oversight. I will add it for the next release.

After reviewing with it seems necessary to properly handle the complex JSON types e.g. a JSONObject, with their own transcoders and IdPAttributeValue types - these could end up being generic Map types. This will then allow it to handle, at least, all the standard claims including the address claim.

I committed the current changes and decoding logic in d4155614eab8baa256c7c860d837d52c833f0692. It no longer throws an exception on an unexpected type, just returns an empty list. I added a test for the ClaimsSetRequest.Entry type and it seems to work. Not sure how nice this looks, but can revisit if needed.

An issue in production might be; it is logging (trace) the fact it can not convert values because they are the wrong type, which may get confusing if this is legitimately not going to decode the values of the ClaimsSetRequest.Entry type.

Yes, technically it would allow an empty list of values, but I do have it throwing a decoding exception if it didn’t understand the input type (or could not convert the input type to the target type if certain properties are not set). So yes, I guess if that was just another code branch that just returned an empty list as opposed to throwing an exception, it would all work.

If the concern is “must have values”, I don’t think that’s true for our purposes anyway. If it decodes, but then the code as it is now checks the input object type and just ignores them, it’s not really going to add much overhead. So maybe just do that and not worry about it?