OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [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
cantor.2@osu.edu
Office of Info Tech
The Ohio State Univ



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC