← Prev in month ← Prev in thread

[security-services] New Issue: Multi-Valued Attributes

From
Scott Cantor <>
Date
2002-01-23T04:27:50+00:00
ID
000001c1a3c5$eb29bb30$df8cd018@SAIDIN
Thread
[security-services] New Issue: Multi-Valued Attributes
During some Shibboleth discussions about attribute value syntax, RLBob
pointed out that it doesn't make a lot of sense to restrict the
AttributeValue element to a single occurrence, since many attributes
(directory-oriented and otherwise) are multi-valued.

An example is the eduPersonAffiliation attribute, which can contain one
or more enumerated values such as faculty, staff, or student.

There are three immediately evident ways to encode multiple values for
an attribute in an attribute statement:

1) Include the same attribute namespace/name multiple times, a la:

  <Attribute AttributeName="Affiliation" AttributeNamespace="eduPerson">
    <AttributeValue xsi:type="eduPerson:AffiliationType">
      staff
    </AttributeValue>
  </Attribute>
  <Attribute AttributeName="Affiliation" AttributeNamespace="eduPerson">
    <AttributeValue xsi:type="eduPerson:AffiliationType">
      student
    </AttributeValue>
  </Attribute>

2) Design the value to be a list, a la:

  <Attribute AttributeName="Affiliation" AttributeNamespace="eduPerson">
    <AttributeValue xsi:type="eduPerson:AffiliationType">
      staff student
    </AttributeValue>
  </Attribute>

3) Allow more than one AttributeValue, a la:

  <Attribute AttributeName="Affiliation" AttributeNamespace="eduPerson">
    <AttributeValue xsi:type="eduPerson:AffiliationType">
      staff
    </AttributeValue>
    <AttributeValue xsi:type="eduPerson:AffiliationType">
      student
    </AttributeValue>
  </Attribute>

Of these three solutions, the last seems the best to me. It combines the
overall brevity of solution 2 with a clearer communication of the
meaning.

It also would allow attribute values that are lists of simple types to
be encoded without an extension schema to define an xsi:type for the
list. Affiliation isn't a good example of this, because it's an
enumeration, but in other cases, it would be an advantage.

The change suggested is simply to add maxOccurs="unbounded" to the
AttributeValue element and specify that multiple values for an element
may exist. The processing model for attributes is mostly left
unspecified now anyway.

Scott Cantor

Office of Info Tech
The Ohio State Univ
← Prev in month ← Prev in thread