[security-services] Analysis of the empty string situation

["Eve L. Maler" <eve.maler@sun.com>]

SAML has the following elements and attributes that can currently be empty 
strings (these are from core-25; I've tried to note places where changes 
are forthcoming).


Constructs of type xsd:string
=============================
This type allows empty strings by default.

- Optional Name and Security Domain attributes on saml:NameIdentifier
- Optional IDAddress and DNSAddress attributes on
   saml:AuthenticationLocality
- The saml:Action element
- Optional AttributeName attribute on saml:AttributeDesignator
   and saml:Attribute
- The AssertionArtifact element
- StatusMessage element

I think we don't have to worry too much about most of these; the incentive 
is to provide content.  However, we should be clear that we expect there to 
be some content.


Constructs of type saml:IDType
==============================
This is a trivial derivation of xsd:string; note that some of these will 
change to IDReferenceType soon, but the emptiness quotient won't change for 
them.

- Required AssertionID and Issuer attributes on saml:Assertion
- Required RequestID attribute on samlp:Request
- Required ResponseID and InResponse attribute on samlp:Response

We could add a minLength facet to the definition of IDType that forces the 
length to be greater than zero if we want there to be a syntactic check 
that some ID is present.  Given that so many of the characteristics of a ID 
that make it unique/successful are out of the hands of syntactic 
expression, it seems a bit like a futile gesture.


Constructs of type xsd:anyURI
=============================
This type allows a length of zero because empty URIs have an RFC 
2396-defined meaning.

- Required-repeatable Target element
- Optional Binding attribute on saml:AuthorityBinding
- Optional (soon to be required) Resource attribute on
   saml:AuthorizationDecisionStatement
- Optional Namespace attribute on saml:Actions
- Optional AttributeNamespace attribute on saml:AttributeDesignator
   and saml:Attribute
- The samlp:RespondWith element

Producers of SAML markup will probably have an incentive to provide 
sufficient content in at least the Target and RespondWith cases because 
they don't have to be used at all; if you bother to put them on, you'll 
bother to add content.

I'm not convinced it's illegitimate to have an empty URI in the Resource 
case.  We may need to investigate the Resource case further, but as a 
reminder, the example I mentioned in today's call was an empty URI meaning 
"this resource" when the action is "execute" and it's an authorization 
decision statement attached to a SOAP purchase-order payload.  Others on 
the call favored a statement that says that SAML behavior is undefined when 
the Resource is an empty URI.

In the other cases (Binding, Namespace, and AttributeNamespace), we may 
want to be clear about the non-empty requirement, but since these 
attributes are optional, it doesn't seem very important to restrict this.


Analysis
========
It seems like a pain to add facets in the saml:IDType and xsd:string cases 
to ensure that there's content in all these places, but at the same time, 
if we're truly worried about interoperability and mischievous producers of 
SAML content, we should probably use the syntactic option at our 
disposal.  It's not all that invasive, though, if we just redefine IDType 
(and the forthcoming IDReferenceType) slightly, define a saml:string that 
has the appropriate facet defined, and then switch from xsd:string to 
saml:string.  We should also add prose to the description of all of these 
types.

As for xsd:anyURI, the rationale for messing with it at this point doesn't 
seem as strong as in the other cases.


Auxiliary issues
================
- If we *don't* turn the Name attribute into regular NameIdentifier
   content, I think it should be required, not optional.

- Should the Namespace attribute be called ActionNamespace in parallel
   with AttributeNamespace?  (A few of us had a thread on the "namespace
   concept" topic recently, wherein a few other alternative names were
   suggested as well.  Should this be turned into a low-priority issue?)

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com