OpenSAML user discussion

["Scott Cantor" <>]

> Ok.  Understood.  I haven't had a chance to work through Shibboleth, but
> it sounds like you don't use the AttributeQuery mechanism in the 
> manner that we're attempting.

Well, more like we don't think the role of the protocol is to communicate
which attributes are "supported". That was Walter's point.

As far as supporting zero, null, or empty values in their own right, they
just don't seem to do anything useful. Omitting the attribute outright
amounts to the same thing.

Putting it another way, overloading meaning on the empty string is a classic
bad idea in data management. ;-)

> Perhaps we're attempting to do something that the language 
> wasn't meant to do? I don't think so, but maybe I'm wrong?

I think you are if you want to tell the relying party in an assertion this
attribute in your query was or wasn't understood. If that information was
put any place it would be in the protocol wrapper, and there's no place for
it apart from as status information.

> Sorry, "valid" meaning "supported".  If an attribute is
> "invalid"/"unsupported", the authority ignores it an does not send
> it back in the response.  If the attribute is supported, what I assumed
> would happen is that the authority returns the attribute with whatever
> value(s) it has in it's attribute store. 

Right. But if the attribute has no values or the value is NULL, why include
it? The fact that we (partly) fixed this in 2.0 doesn't mean I think it's
useful.

Explicitly empty values are somewhat different, though mostly just a source
of pain for all concerned, IMHO.

> The client would then interpret a non-response as an unsupported
> attribute, a null value as a null value, and an empty string as an empty
> string.

That first part is wrong, IMHO. There is no such semantic in the spec. You
can't read anything into the absence of an attribute in the assertion. There
are many valid reasons why a supported attribute might not be there, privacy
controls being an obvious one.

> For my purposes, I can get away with not sending an attribute for
> unsupported attributes and for null values, since the resulting value is 
> essentially null in both cases.  The issue really arose when OpenSAML
> didn't let me send back empty strings, because I want to differentiate
> between null and empty.

Right, I understand.

> I didn't think that I was proposing that?  So what DO you do 
> in Shibboleth when you implement AttributeQuery requests and responses? 
> How do you handle cases where a consumer is requesting unsupported
> attributes, null value attributes, and empty string attributes from an
> attribute authority?

The Shibboleth AA only includes an attribute if it understands it, allows
the release, and at least one non-empty value exists. Whether an attribute
is "supported" or not is not in any way shape or form indicated in the
response, and my opinion is that SAML doesn't permit otherwise unless you
use the Status to do so.

-- Scott