OpenSAML user discussion

["Scott Cantor" <>]

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

My personal opinion is that we didn't mean that restriction to apply to this
element, only the more SAML-specific ones. I can ask though.

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

What does "valid" mean? The issue of what attributes are "supported" by an
AA is an out of band issue for a deployment to address. Metadata also can
address this kind of thing, although not in 1.x.

> Without that ability, not
> sending an attribute could mean no data or it could mean that the
> attribute was invalid. 

I think you've invented a concept that doesn't really show up in the spec.
Validity in the abstract isn't something the protocol is intended to
communicate.

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

Hmm...what you proposed isn't sufficient for that unless you're proposing to
simply echo back any attribute that is understood by the AA, and send an
empty value for any attribute that didn't apply to the subject (which seems
wrong, since that's not the same as saying "no values". But that isn't
something I think others are doing. Certainly we don't in Shibboleth.

> 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 agree, but I don't see the value in going this far into it, I guess.
Issues like "schema discovery", to maybe draw an LDAP parallel, are really
separate from this particular protocol, IMHO.

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

Whether I agree with using it or not, I would consider it a bug if I was
blocking something simple that is legal, so I'll ask next week and put in a
fix if it's warranted.

-- Scott