meta-attributes as first-class citizens
Tom Scavo
trscavo at gmail.com
Mon Dec 7 18:02:20 EST 2015
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).
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 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.
What I'm trying to say is that meta-attributes need to become
first-class citizens in the idP software. Instead of saying this:
<afp:AttributeRule attributeID="eduPersonPrincipalName">
<afp:PermitValueRule xsi:type="AttributeInMetadata"
attributeName="http://id.example.org/attribute/metaPublicUserID"
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
</afp:AttributeRule>
we should be saying this:
<afp:AttributeRule attributeID="metaPublicUserID">
<afp:PermitValueRule xsi:type="AttributeInMetadata"/>
</afp:AttributeRule>
Don't know if that's possible or even the right suggestion to make, so
I'll stop there but let me restate the basic principle I'm after: I
think the Meta-Attribute Registry needs to be machine-readable and the
Shibboleth IdP needs to consume it.
Tom
[1] https://wiki.shibboleth.net/confluence/x/dAInAQ
[2] https://spaces.internet2.edu/x/QgOVBQ
More information about the dev
mailing list