AffiliationDescriptor

[Cantor, Scott]

> Is it reasonable to use this feature as a direct entity attribute replacement? I.e.,
> publish one AffiliationDescriptor per existing EntityAttribute? Any scaling
> issues with having too many AffiliationDescriptors, or with descriptors having
> too many members?

It doesn't work *with* them right now, that was my point, it works instead of them. It's a replacement for the old practice of embedding things inside EntitiesDescriptor groups and then using the group name in the config (explicitly in V3, it has "by group" notions in the syntax for expressing that).

This lets the group definition be fed in separately from the members of the group, so you break apart the limitations on hierarchical groups and where metadata actually comes from.

Given sufficient screwing around with scripting, you can achieve a fair amount of flexibility with it, but without that work, it's still limited to expressing a single set of behaviors in a RelyingPartyOverride matching one or more group names.

Fixing the combinatorial problem of NxN overrides to deal with all the different cases takes a different approach, one of which is the EntityAttributes-driven way of controlling settings.

I think it's reasonable to work out some cases in the code where "attach EntityAttribute to AffiliationDescriptor containing Foo" is equivalent to "attach EntityAttribute to Foo", but right now it's not. And it pretty much physically can't be in certain cases, like trying to use them as predicates inside the metadata configuration, it's just too circular to work.

-- Scott