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] | [List Home]


Subject: Suggested schema tightening for 2.1


I had an action to do some investigating and experimenting with pattern
constraints on the string and anyURI types used in the SAML schemas.
Recall that in prose, we require that unless the spec overrules it, all
such types are meant to have at least one non-whitespace character.

I believe the following types would be an appropriate replacement:

<simpleType name="string">
  <restriction base="string">
    <pattern value=".*\S+.*"/>
  </restriction>
    </simpleType>

<simpleType name="anyURI">
  <restriction base="anyURI">
    <pattern value=".*\S+.*"/>
  </restriction>
</simpleType>

The schemas would be updated to reference saml:string and saml:anyURI in
place of the xsd versions in various places to apply the constraint.



I've tested with an implementation that isn't known for rigorous regexp
support in its validator and I get good results so far. Empty elements,
and whitespace only content, are detected as validation failures.

We would not expect to see most implementations notice this since they
don't validate, but some of us optionally do, and there are other tools
that are more likely to do this, like metadata production tools. Having
the real schemas enforce the spec's prose would be a positive change.

I would advocate publishing these in one of two ways:

- Replacing the existing schemas in 2.1 with the justifcation that the
lexical space intended to be allowed is not actually changing.

- Publishing both the original schemas and an enhanced set.

A specific set of changed element types would be forthcoming once I look
at them all.

We could also pubish the types in a separate utility schema, but in
pactice most of our schemas tend to import the assertion schema anyway, so
putting them there is probably good enough.

-- Scott



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