<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 9, 2015 at 12:33 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/9/15, 10:50 AM, "users on behalf of Rod Widdowson" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:rdw@steadingsoftware.com">rdw@steadingsoftware.com</a>> wrote:<br>
<br>
<br>
<br>
>> it seems to release only the final encoded attribute.<br>
><br>
>From reading the code I would have expected to see the first. But I’ll confirm that that is what the AddAttributeStatementToAssertion actions do (each IdPAttribute gets encoded by a maximum of one encoder).<br>
><br>
>I'd defer to Scott as to whether that is correct, although lack of backwards compatibility has always got to be treated with suspicion.<br>
<br>
</span>It sounds like a bug, although in practice most cases where this was being done were actually suboptimal. Usually the goal was to encode it differently for a different RP, and so attaching a condition to the encoder might be the better choice here, but I don't think it was intentional that the behavior changed, no.<br></blockquote><div><br></div><div>IDP-785 for your debugging pleasure then.  You're right, this is exactly being done due to some RP insisting that the attribute be encoded their way.  What really frosts my cake about this particular RP is they're running Shibboleth as their SP.</div><div><br></div><div>Dave</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>David Langenberg<div>Identity & Access Management Architect</div><div>The University of Chicago</div></div></div></div>
</div></div>