Attribute filter

[Cantor, Scott]

On 7/3/14, 7:22 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>As would that.  They are trivial to do. The only question whether it is
>worthwhile emitting a log.info when we meet the old names as an early step
>towards deprecating & then remving in V4.

I think so.

>>How about using "AttributeRequesterMappedEntityAttributeMatch" or maybe
>> just "MappedEntityAttributeMatch" for the new one?
>
>I don't like that too much since it although it describes what the code is
>doing, it doesn't describe what the deployer will see.  They don't need to
>know what the SAML attributes have been reversed matched, just that their
>IdP will only release the attributes that the SP has designated.  As a
>_class_ name I like it, since it does describe exactly that, down to the
>fact that it is neutral as to where the attributes were mapped from.  I
>think that "RequestedAttributeInMetadata" pretty much sums it up for me.
>We
>can then leave EntityAttributeInMetadata in place and leave it
>undocumented,
>or just remove it.

Are you suggesting merging the RequestedAttribute case with the mapped
EntityAttribute case and just doing one function? Otherwise I don't know
what you mean.


>I¹d agree: "inexact" feels like an imprecise statement and we really don't
>want to get into a language to define it.    Or is inexactness defined
>somewhere that I missed?

No, it's completely up to attributes to define their own matching rules.
If they had a notion of inexactness, it would be attribute-specific.

-- Scott