OpenSAML user discussion

["Scott Cantor" <>]

> > > 2. Attribute elements MUST contain at least one AttributeValue
> > element.
> > 
> > This is fixed in 2.0.
> 
> Ok, but I'm guessing that an OpenSAML library with SAML 2.0 support is a
> long ways in the making.  In using the OpenSAML 1.0 library, I 
> still have an issue. What I'm trying to figure out is if there is a proper

> solution for this.

I understand, and the answer is no. It was just fixed in the spec, and it
was broken before.

> That's what I thought, but the OpenSAML 1.0 library chokes when I send an
> empty AttributeValue element.  And by choke, I mean that it spits 
> out a warning message:

This is because the default value handler is very limited. Probably too
limited, I could have special cased an empty element and handled it as an
empty string, so please file a bug on it. But you can always just install
your own attribute class to handle everything, and any non-trivial use case
requires that anyway.

In practice though, I don't see a lot of value in passing empty strings or
null values (or even zero values) in an application using SAML. It doesn't
make a great deal of sense to me. Just don't pass the attribute, since
you're not asserting anything of significance anyway.

> The type for an AttributeValue is anyType.  Is "empty" a valid value for
> anyType?  I would think so, but in researching the type in the XML Schema
> docs, I'm not so sure anymore.  I know that the string type is not 
> allowed to be empty or contain only whitespace.

Both string and anyType are allowed to be empty (though not "nil"), subject
to the point above that it seems a waste of XML. The SAML rule of thumb
about not using empty strings wasn't really intended to be about attribute
values.

> I completely agree, but I'm at a loss due to the inability to convert
> an empty AttributeValue.

What is the actual significance of such an assertion? What could I do with
it?

> I have been leaning towards this resolution too.  I'm just getting
> pressure from "above" to provide a distinction between "invalid", "null", 
> and "empty".  Thus, the different possible solutions in my email.  If I
> can convince the higher powers that "invalid" and "null" can both most
> likely be treated as "does not exist" and simply not returned, then that
> will at least get rid of part of my dilemna.

I can't see any use for the distinction, but other people have more
imagination than me.

Anyway, I can pretty easily special-case an empty element and turn it into
an empty string, which is what it is. If it's a major issue, I can apply the
fix to 1.0.

-- Scott