meta-attributes as first-class citizens

[Cantor, Scott]

On 12/7/15, 6:02 PM, "dev on behalf of Tom Scavo" <dev-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:



>I've updated the documentation on AttributeInMetadata [1] and blogged
>about meta-attributes [2] but this is only half the story. The other
>half includes the interplay between meta-attributes and consent (among
>other things).

Consent operates on the data being released, basically, not why you chose to release it. So they don't really matter. Even regular SAML attributes aren't relevant to this implementation of it.

>I'm pretty sure we want the Meta-Attribute Registry to be
>machine-readable so that the consent machinery can consume
>standardized attribute display names and descriptions. Only then will
>users have a consistent experience across IdPs.

That wouldn't apply to this implementation, it doesn't operate on what you're defining, it operates on internal IdP attributes.

>That by itself probably isn't compelling enough. A machine readable
>registry should also constrain permissible mappings from
>meta-attributes to wire attributes in the IdP software. That is
>perhaps the more important missing piece.

SAML would basically require that (not that it be machine readable, just that *something* defines the matching rules intended). But in this design, there's no real place for that to be implemented. Maybe in the query filtering perhaps. Mostly the IdP needs a deployer to tell it how to map from SAML to the internal/local meaning. I don't think that can or should be generalized, or what it would accomplish to do so.

>we should be saying this:
>
>  <afp:AttributeRule attributeID="metaPublicUserID">
>    <afp:PermitValueRule xsi:type="AttributeInMetadata"/>
>  </afp:AttributeRule>

Doesn't really fit how the IdP works. attributeID there is fully local/internal and can never be imposed apart from just standardizing common config files.

-- Scott