Version 3.4 metadata driven overrides

[Cantor, Scott]

> Thanks. So one that would apply to all profiles would just be the following,
> correct?
> 
>   http://shibboleth.net/ns/profiles/responderId

Yes.

> I'd also like to bring up attribute release, and see what the Shib team thinks
> of the following. I know that at least you (Scott) have given this some
> thought in the past. One could define a standard entity attribute name, and
> the values of that would be the "standard" ID/FriendlyNames (as in the
> attribute-resolver-full.xml) of the attributes to be released. And then, of
> course, distributing an attribute filter file with rules in it like the following:

That's not unreasonable, it's just necessary to recognize that if we don't standardize the names in some independent way, these are going to be local to a system, since the attribute IDs are also localized. I don't think I would object to us pre-populating our samples that way since they're intended to work together, obviously. The filter has to know the attribute IDs to work regardless of whether metadata is involved.

> The other option would be to define an entity attribute name per attribute,
> but I don't see the advantage in that unless one was going to somehow work
> "values to be released of a given attribute" into that. (Although I'm sure how
> one would leverage those values in pre-embedded release rules. And trying
> to go down to the level of per-value control thru entity attribute tagging
> seems a step too far.)

Since this is all convention and nothing we're wiring into the code, I would agree that unless we perceive a real need, we should keep it reasonable.

> What do you think? Does the Shib team want to define one or more entity
> attribute names that could potentially be leveraged as one option to control
> attribute release?

I think we should ship defaults, but we would not own the names because by definition the attribute names aren't ours.

> Would you prefer the value set of such an entity attribute
> to be the urn:oid form of the names, rather than the FriendlyNames? Have
> you had some different model for such tagging in mind?

The filter doesn't operate on SAML names so it would be awkward to try and do that, but that's the only way we could do this that would be independent of any particular configuration.

I suppose what we could do is implement a new variant that sort of mapped a particular entity attribute into the equivalent form of RequestedAttribute, which is something we do support, though not all that cleanly. I'd have to think about that.

I would say for now populating the default files using the local convention/names is the simplest choice.

-- Scott