alternate attribute names

[Baron Fujimoto]

On Thu, Jun 28, 2018 at 01:10:01PM -0700, Greg Haverkamp wrote:
>On Thu, Jun 28, 2018 at 12:30 PM IAM David Bantz <dabantz at alaska.edu> wrote:
>
>> 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?
>>
>
>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.

I've also learned from this thread, thanks. I can see benefits to having the alternate names defined with the activation condition. A minor(?) downside I see is that when I release the attribute in the attribute filter by its AttributeDefinition ID, it also releases all other alternate named versions of the attribute as well. Or am I missing some means to limit the released attribute to just the variant intended for that relying party?

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum