OpenSAML user discussion

[Mike Ferraro <>]

Quoting Scott Cantor 
<>:
> 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.

Ok.  I'll file a bug and you can decide if it's something that you want to
include.  I would have added my own attribute handling, but I wanted to try to
avoid extensions for compatability and maintenance purposes (i.e. new opensaml
releases and the like).

> 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.

We're building an attribute service and if I ask for someone's email address,
a value of empty has a different meaning than simply not returning an
attribute.  An empty email address means that the attribute is valid, but the
Subject does not have one on record.  An unreturned attribute means
that the email address attribute does not exist in the authority.  The
distinction is subtle, but is one that I wanted to make.

> 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.

Ok.  I was just going by what was in the docs:
1.2.1 String and URI Values 
All SAML string and URI reference values have the types xsd:string and
xsd:anyURI respectively, which 
are built in to the W3C XML Schema Datatypes specification [Schema2]. All
strings in SAML messages 
MUST consist of at least one non-whitespace character (whitespace is defined 
in
the XML 
Recommendation [XML] §2.3). Empty and whitespace-only values are disallowed.
Also, unless otherwise 
indicated in this specification, all URI reference values MUST consist of at
least one non-whitespace 
character, and are strongly RECOMMENDED to be absolute [RFC 2396].

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

Well, the current options for receiving attribute data are: Send a valid 
string
or don't send anything.  Since both responses MUST include a SUCCESS status
message, the ability to respond with an empty string would signify that the
attribute was valid but that it contained no data.  Without that ability, not
sending an attribute could mean no data or it could mean that the attribute 
was
invalid.  As a client, it would be helpful to be able to determine whether
there was some sort of error (requesting an invalid attribute) or simply no
data.

I guess that another way to handle this would be to return some custom 
substatus
code values.  That would seem to get complicated though, especially if 
specific
attributes needed to be identified.

> 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.

That would be ideal.  I wouldn't want the code changed just because I need a
special case, but it seems that the library should allow for an empty anyType
AttributeValue if the SAML/XML specs say that it's valid.

-Mike