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: Schema errors in CD

Thanks to getting to CD, I got the external review I was looking for and
several issues with the schemas were identified to me.

The least serious of them is in the metadata schema, and is a
content-ambiguity bug around the use of <any> in the role "choice" because
of the optional ds:Signature element present in the content model ahead of
it. The solution is to remove the wildcard and force role extensions to
derive from our abstract md:RoleDescriptor element, which was probably what
I should have done anyway.

The other errors are more serious problems in the BaseID/NameID/EncryptedID
types that are flat out violations, namely the derivation by extension from
anyType (only restriction is allowed). I should have run SQC against the
schemas, but I forgot to try it. Validators were consuming the schemas but I
should have dug deeper (not that I'm the only one who should have been
reviewing things).

My suggestion (given that we're going to have to make changes and go back
through review again anyway) is that we dump the tricks and just play this
straight. Make BaseID an empty, abstract extension point (like Statement,
Condition, etc.) and sever the inheritance chain we had.

The reason for not inheriting NameID and EncryptedID is that restricting
from mixed/complex down to simple is not very well understood by tools, and
that it would allow us to create a new base type for all encrypted elements
and just extend each encrypted case we have from that base instead of using
an element group.

The "base" SP/NameQualifier attributes would be moved to an attributeGroup
and used in both the concrete types.

A proposal for correcting this is below, minus the use of a base type for
encrypted content, which is a trivial addition.

A related, but less invasive, fix to SubjectConfirmationData is also needed
to change the derivation from extension to restriction.

Sorry for not catching this, but I was doing too many higher level things to
the spec.

-- Scott

    <element name="BaseID" type="saml:BaseIDAbstractType"/>
    <complexType name="BaseIDAbstractType" abstract="true"/>
    <attributeGroup name="NameQualifiers">
        <attribute name="NameQualifier" type="string" use="optional"/>
        <attribute name="SPNameQualifier" type="string" use="optional"/>
    <element name="NameID" type="saml:NameIDType"/>
    <complexType name="NameIDType">
            <extension base="string">
               <attributeGroup ref="saml:NameQualifiers"/>
               <attribute name="Format" type="anyURI" use="optional"/>
               <attribute name="SPProvidedID" type="string" use="optional"/>
    <element name="EncryptedID" type="saml:EncryptedIDType"/>
    <complexType name="EncryptedIDType">
            <group ref="saml:EncryptedType"/>
        <attributeGroup ref="saml:NameQualifiers"/>

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