alternate attribute names

[IAM David Bantz]

I found this an interesting thread. I have several times followed exactly
the tack suggested by Nate
(encode a specially constructed attribute with name and friendlyName to
meet special requirements of an SP).
So it's interesting a little concerning to read Marvin's recommendation for
what seems a more convoluted method
using activation conditions. Marvin or others, could you elaborate on why
this is a superior approach?

Thank you!

David Bantz
UA OIT IAM

On Thu, Jun 28, 2018 at 10:43 AM, Marvin Addison <marvin.addison at gmail.com>
wrote:

> On Mon, Jun 18, 2018 at 5:51 PM Greg Haverkamp <gahaverkamp at lbl.gov>
> wrote:
>
>> I haven't decided if it's better or worse, but I've lately started using
>>> activation conditions for these requests.
>>>
>>
> We've tried many solutions and I'm comfortable saying that activation
> conditions are the way to go for one-off attribute names. We're seeing an
> uptick in the number of integrations that require specific (and in many
> cases non-standard) attribute names, and activation conditions allow us to
> focus on these quirks by adding additional attribute encoders that are
> toggled with an activation condition as your example demonstrates. If
> you're doing consent or other flows that work on attribute sets, you'll
> appreciate the benefit of this approach even more.
>
> Marvin at Virginia Tech
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180628/16a3dd7b/attachment.html>