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