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

[sanderson@opennetwork.com (Steve Anderson)]

Out of the three choices, I agree that the last one is the most attractive.
The only thing that strikes me as odd is that this allows for different
values of the same attribute to have different syntaxes.  Is that a useful
level of complexity?

--
Steve

Scott Cantor wrote:

> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Anderson;Steve
tel;fax:727-561-0303
tel;work:727-561-9500 x241
x-mozilla-html:FALSE
url:www.opennetwork.com
org:OpenNetwork Technologies
version:2.1
email;internet:sanderson@opennetwork.com
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 390;Clearwater;Florida;33762;USA
x-mozilla-cpt:;-6352
fn:Steve Anderson
end:vcard