[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Analysis of the empty string situation
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC