OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [security-services] Core changes for ISSUE DS-4-13


I took an AI to submit changes to core-28 for DS-4-13, the addition of
derived types for string and anyURI that enforce desired facets in the
schema, as well as a pass over the schema to identify any issues with
the changes. Some important points first:

The effect of the changes below is to type all of the string elements
and attributes in SAML as a new type of string which is required to be
at least one character long (but the character can be anything,
including whitespace). Many of the anyURI types are changed as well,
except where I think a true URI reference is meant in a resource (not
just an ID) sense, in which case emptiness could have meaning (though
perhaps not a generally useful one).

The relevant reference in XML schema that discusses the meaning of
minLength is here:

http://www.w3.org/TR/xmlschema-2/#rf-minLength

Note that based on my reading, it would not actually be all that
difficult to constrain whitespace-only out of the equation, because
Unicode does not, I don't think, define characters above #20 that are
defined to be whitespace, nor in general would they be classified
unprintable. The control characters that were mentioned, for example,
are not legal in XML. See this reference for the definition of Char in
the XML spec:

http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-character

All that said, these changes are minimal in the sense that they don't
attempt to resolve the whitespace question and primarily just prevent
somebody from passing attr="" or <el></el> in a message, and that's the
only change that was approved. Also note that the QNames in the schema
are fine as is, because QName has to be at least a legal NCName in the
namespace spec, and they start with a letter.

The following should be added to the assertion schema/namespace:

<simpleType name="NonEmptyString">
   <restriction base="xsd:string">
      <minLength value="1"/>
   </restriction>
</simpleType>
<simpleType name="NonEmptyURI">
   <restriction base="xsd:anyURI">
      <minLength value="1"/>
   </restriction>
</simpleType>

A global replacement of "saml:NonEmptyString" in place of "string" for
all type declarations should be performed. The full list of types,
elements, and attributes which must be modified follows:

In assertion.xsd:

IDType
IDReferenceType
DecisionType
    (optional since this already enumerates itself, but for
consistency?)
Issuer
NameIdentifierType
NameQualifier
SubjectConfirmationData
IPAddress
DNSAddress
ActionType
AttributeName

In protocol.xsd:

AssertionArtifact
StatusMessage
    (this one probably doesn't matter much, actually)

In summary, I found no uses of string where "" made any useful sense, so
a global change should work fine.

On the URI side, the following uses of anyURI should be changed to
saml:NonEmptyURI to enforce non-empty content.

In assertion.xsd:

Audience
Format
ConfirmationMethod
AuthenticationMethod
Location
    (this is a URL, and an empty URL makes no sense here)
Binding
Namespace (in ActionType)
AttributeNamespace

In protocol.xsd:

Recipient (currently erroneously a dateTime as Emily noted)

Basically, I left Resource out, which is used in several spots to
reference an object of a policy decision. If the use case "current
document" for some situation with SOAP or something like that (which I'm
not about to evaluate at present) is deemed unneeded, then all uses of
anyURI can be changed.

In the case where Resource is optional, there is a clear semantic
difference between omitting it (none specified) and Resource="" (the
current document). I think any other interpretation would be a bad idea.

Part of this AI was to present "findings" on the scope of this change,
so if there are any comments, get them to the list quickly.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC