Re: Attribute values or the lack therof

["Jim Christopher" <jchristo@carolina.rr.com>]

Robert et al;

> Re: sniffing out semantics - I think this is really a separate issue.  If
> the requester is not authorized to see an attribute, I think the attribute
> should just not be returned in the assertion.  A "sniffer" still won't be
> able to tell the difference between an attribute that doesn't exist and an
> attribute they are unauthorized to see. Or did I miss something?

That's part of what I was trying to convey.  In order to indicate that an
attribute had no-value ( "", null, nil, Nothing, etc. ), early on we simply
did not include an attribute designator in the response; this quickly proved
inadequate because we also made a practice of omitting attributes to which
the requester is not authorized in order to prevent sniffing.  This made it
difficult for the requester to determine the meaning of the response: does
the missing attribute mean the attribute has no value, or does it mean the
requester does not have authorization to query for that attribute?  In short
we found a need to distinguish between returning-a-value-of-nothing ( per
David's post ) and returning-nothing ( per the sniffing discussion ).  So we
opted to define a "no-value" attribute value to distinguish the two cases.

> You have dealt with this issue by defining the proprietary URN.  The rules
> about defining proprietary URN's has always been a bit fuzzy to me, but
I'm
> not sure that doing what you did conforms to URN registration "rules".
> Perhaps someone better versed in URN namespace definitions can elaborate.

I'm sure you are correct.  The "URN" is by no means indended for public
consumption, but instead as a reference for the closed-community of our
application vendors.  In light of your comments and those of Scott Cantor,
however, I have requested that our team review the use of URIs in our
service.

> I think the "right" solution to this issue is to fix the SAML spec by
> permitting an AttributeValue element to be returned as an empty element -
> i.e. <AttributeValue/>.  One "might" say that this is already allowed by

+1

If the AttributeValue element were nillable, perhaps?

> declaring that section 1.2.1 does not apply to the "user" data provided in
> this element.  Section 1.2.1 starts out with the sentence "All SAML string
> and URI reference values have the type xsd:String and xsd:anyURI,
> respectively...".  So one could just say that the attribute value data is
> not a "SAML string".  Thus it can be permissible to send an empty element
> for <AttributeValue>.

Our interpretation comes from the second and third sentences of that section
( 1.2.1 ): "All strings in SAML messages MUST consist of at least one
non-whitespace character ....  Empty and whitespace-only values are
disallowed.", which we took as precluding us from returning an empty
AttributeValue element to indicate no-attribute-value.

One option that just occurred to me that we didn't consider during
implementation - since the AttributeValue is defined as type xsd:anyType, it
seems to me that we should have defined an element in our namespace to
represent no-value.  Something like so:

<AttributeValue><null
xmlns="http://www.learningstation.com/services/security/SAML"; xsi:nil="true"
/></AttributeValue>

I suppose we got stuck on the notion of the no-value being a simple type.
This feels better than the URN solution we have now, but I'd still prefer to
nil the AttributeValue element directly.

> I'm not in favor of introducing a separate URN to distinguish the
null/empty
> value.

To be frank the URN leaves a bad taste in our mouths as well; I wasn't
advocating its use, just informing the group of the solution we came up with
for the problem.

jim christopher
senior developer / r&d
learningstation