Shibboleth Developers

["Scott Cantor" <>]

> Both Bob and Scott have argued that if the AttributeValue is merely a 
> simple string, we shouldn't create unnecessary complexity by using a 
> new element. I think I'm convinced..... but for completeness sake I 
> feel I have to ask .... do we gain any generality by using an 
> element, by deferring the typing of a particular attribute value? 
> Does using an element allow the code to be more general, to separate 
> it from any nastiness resulting from being tied to a "simple string"?

None that I can see. The XML content model should be whatever is most
appropriate for the attribute. If it's sufficient to use a built-in
schema type to represent the possible values, then that's the best
answer in XML terms.

Nothing constrains the implementation of components that use the
attribute value to do something interesting with it just because it's a
simple value.

I still see each attribute as a bundle of plugins in various places,
dynamically invoked using the attribute's QName to locate the plugin.
Maybe (hopefully?) there will be opportunities for design patterns in
those plugins that can be factored into base classes to simplify this,
for similar content models.

> I understand this to say that we should use strings wherever 
> possible. In addition, we should include xsi:type="string" where 
> applicable, in order to vastly simplify the parsing of these elements 
> by the consumer. Is that correct?

I wouldn't say just strings, but any of the built-in types. Anything
that parses without an extension schema is faster to validate and easier
to build common handling code across.

> Issue 2-- multi-valued Attributes
> 
> Did we ever specifically discuss whether multi-valued 
> attributes for which the person has multiple values should be 
> passed as one attribute or multiple?

Discussed, but not decided. I think one attribute is sensible, but that
makes more sense with affiliation and less sense with some of the other
eduPerson stuff like these proposed group/entitlement attributes, simply
because it seems like those groups could be a very broad, unrelated set
of associations.

Then again, a lot of pretty successful security models have nothing but
principals and groups, including the only one with any desktop
penetration, so who's to say?

> c) others?

I think RLBob has a point about SAML not permitting multiple
AttributeValues. On the face of it, that doesn't make a whole lot of
sense. I don't know how they'll react to the suggestion, but we could
find out.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--