[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"/> </attributeGroup> <element name="NameID" type="saml:NameIDType"/> <complexType name="NameIDType"> <simpleContent> <extension base="string"> <attributeGroup ref="saml:NameQualifiers"/> <attribute name="Format" type="anyURI" use="optional"/> <attribute name="SPProvidedID" type="string" use="optional"/> </extension> </simpleContent> </complexType> <element name="EncryptedID" type="saml:EncryptedIDType"/> <complexType name="EncryptedIDType"> <sequence> <group ref="saml:EncryptedType"/> </sequence> <attributeGroup ref="saml:NameQualifiers"/> </complexType>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]