<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 12:30 PM IAM David Bantz <<a href="mailto:dabantz@alaska.edu" target="_blank">dabantz@alaska.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I found this an interesting thread. I have several times followed exactly the tack suggested by Nate<div>(encode a specially constructed attribute with name and friendlyName to meet special requirements of an SP).</div><div>So it's interesting a little concerning to read Marvin's recommendation for what seems a more convoluted method <br>using activation conditions. Marvin or others, could you elaborate on why this is a superior approach?<br></div></div></blockquote><div><br></div><div>We don't do consent, so I'm not sure where those wins are.  For me, the huge win is not having to worry about filtering.  Before I shifted to using the activation conditions, I'd create the entirely new attribute, with an entirely new attribute ID, and then I'd have to go write add to a filter policy to release that attribute.  But if some vendor comes along and wants uid released as an attribute named "username" instead of "urn:oid:0.9.2342.19200300.100.1.1", I can do that just in the resolver, in an existing attribute definition, without a bunch of copied boilerplate in two files.   </div><div><br></div><div>I have some idea bubbling around in my head based on what Martin wrote, but I probably shouldn't speculate too much.</div><div><br></div><div>Greg</div></div></div>