XML Schema techniques: issues and recommendations

1. XML Schema techniques:issues and recommendations SAML F2F #4 Eve Maler eve.maler@sun.com 28 August 2001

2. Outline • Parameters of some issues facing us in development of XSD-compliant schemas • CONS-04 • CONS-03 • A small selection of others • My recommendations • TC discussion/decisions

3. Issue CONS-04: Extensibility of assertions

4. Our putative requirements for assertions • Factor out commonalities and package them in a way that can be leveraged by SAML processors • Allow users to define (a) extensions to native SAML assertions and (b) novel assertion types • Ensure that both native and user-defined assertions can appear in all the right places

5. #1: Factoring out commonalities

6. Currently done with complex types • AssertionAbstractType • SubjectAssertionAbstractType • AuthenticationAssertionType • AuthorizationDecisionAssertionType • AttributeAssertionType • Example instance:<saml:Assertion xsi:type=“AttributeAssertionType”>…</saml:Assertion>

7. Does it meet the requirement? • Yes, because XSD types are nominally accessible to software • Even if the PSVI isn’t truly accessible yet, data binding is heavily used • Model groups are the only other choice • But being macro-like, they nominally aren’t accessible to software • So no issue here

8. #2: User-defined extensionsand novel kinds of assertions

9. Currently done with non-final complex types • AssertionAbstractType • SubjectAssertionAbstractType • AuthenticationAssertionType • User-defined extensions of AuthN-type assertions • AuthorizationDecisionAssertionType • User-defined extensions of AuthZDecision-type assertions • AttributeAssertionType • User-defined extensions of Attrib-type assertions • Novel user-defined extensions with subject info • Novel user-defined extensions

10. Examples • <saml:Assertion xsi:type=“AttributeAssertionType”>(Attrib-specific stuff goes here)</Assertion><saml:Assertion xsi:type=“MyAttributeAssertionType”>(Attrib-specific stuff goes here, plus my stuff tacked on to the end)</Assertion><saml:Assertion xsi:type=“MyOtherAttributeAssertionType”>(Attrib-specific stuff goes here, with tighter occurrence constraints)</Assertion>

11. Does it meet the requirement? • Yes; users can create extensions and restrictions by declaring derived types • Derived-type elements must use the xsi:type attribute and element name is always <Assertion> • But this is true of native elements as well…

12. Another option for part of the problem • We could use <any> wildcards in content models to give extensibility without subtyping • Gives finer control over position, number, and namespace of foreign elements • Type derivation is still needed for totally novel assertion types

13. Example: extensible attribute assertions without new types <xsd:complexType name=“AttributeAssertionType”> <xsd:complexContent> <xsd:extension base=“saml:SubjectAssertionAbstractType”> <xsd:sequence><xsd:any namespace=“##any”maxOccurs=“1”/> <xsd:element ref=“saml:Attribute” maxOccurs=“unbounded”/><xsd:any namespace=“##other”maxOccurs=“unbounded”/> </xsd:sequence> </xsd:extension> </xsd:complexContent></xsd:complexType>

14. Example: instance of extended attribute assertion <saml:Assertion xsi:type=“AttributeAssertionType”> <saml:Subject>…</saml:Subject><saml:DNS_Domain>…</saml:DNS_Domain> <saml:Attribute>…</saml:Attribute><xhtml:p>…</xhtml:p><xhtml:ul>…</xhtml:ul></saml:Assertion>

15. #3: Allowing all kinds of assertions to appear in all the right places

16. Currently done with reference to <Assertion> element • Assertions may appear in <AssertionSpecifier> and <Response> • A plain <Assertion> can’t be used • Its type is abstract • It requires an xsi:type attribute to nail down the concrete type used

17. Examples, again • <saml:Assertion xsi:type=“AttributeAssertionType”>(Attribute stuff goes here)</Assertion><saml:Assertion xsi:type=“MyAttributeAssertionType”>(Attribute stuff goes here, plus my stuff tacked on to the end)</Assertion><saml:Assertion xsi:type=“MyOtherAttributeAssertionType”>(Attribute stuff goes here, with tighter occurrence constraints)</Assertion>

18. Does it meet the requirement? • Yes, because all descendants from AssertionAbstractType can go in those two spots • Some consequences: • Processors must examine the xsi:type attribute in all cases • Native and user-defined assertions look alike

19. Another option: substitution groups • It works by declaring elements to be substitutable for a “head element” • Because this gets done on an element declaration, and elements must have types, xsi:type isn’t needed in instances • All substitutable elements must have the same type as the head element (or a derived one)

20. Example: native SAML elements substitutable for <Assertion> • <xsd:element name=“AuthenticationAssertion” type=“AuthenticationAssertionType”substitutionGroup=“saml:Assertion”/><xsd:element name=“AttributeAssertion” type=“AttributeAssertionType”substitutionGroup=“saml:Assertion”/><xsd:element name=“AuthorizationDecisionAssertion” type=“AuthorizationDecisionAssertionType”substitutionGroup=“saml:Assertion”/>

21. Example: native SAML assertion elements in an instance • <saml:AuthenticationAssertion>(Authentication stuff goes here)</saml:AuthenticationAssertion><saml:AttributeAssertion>(Attribute stuff goes here)</saml:AttributeAssertion><saml:AuthorizationDecisionAssertion>(Authorization decision stuff goes here)</saml:AuthorizationDecisionAssertion>

22. Interaction of type derivation and substitution groups • They can be mixed together freely (by default) • If the SAML assertion schema relies on type derivation (as it does today), extension schemas could still define new substitutable elements with <Assertion> as a head element • If the SAML assertion schema is changed to use substitution groups, extension schemas could still define new types and use xsi:type

23. Examples: user-defined assertions done two ways • (new type derived from subject assertions; can be used directly in instance if xsi:type is used)<xsd:complexType name=“SessionAssertion”> <xsd:complexContent> <xsd:extension base=“saml:SubjectAssertionAbstractType”> … </xsd:extension> </xsd:complexContent></xsd:complexType>(add this to schema to use new element as substitute for <Assertion> element without using xsi:type)<xsd:element name=“SessionAssertion” type=“SessionAssertionType” substitutionGroup=“saml:Assertion”/>

24. Yet another option: model groups • Not considering this option seriously • Model groups are macro-like and thus remove all certainty about type adherence • They would require user-defined schemas to use the redefine mechanism

25. Issue CONS-03: Subtyping in general

26. Currently all types are implicitly set non-final • Any type can be used as the basis for derivation, not just assertion-related types • Any user can extend or restrict our constraints (according to XSD’s abilities)

27. Example: extending the NameIdentifierType type • <xsd:complexType name=“MyNameIdentifierType”> <xsd:complexContent> <xsd:extension base=“NameIdentifierType”> <xsd:sequence>(after <SecurityDomain> and <Name> comes my new stuff)<xsd:element name=“MyHooHaa” …/> </xsd:sequence> <xsd:extension> <xsd:/complexContent></xsd:complexType>

28. What is the requirement? • Flexibility makes sense for: • Our own experimentation for future versions • Innovation by users • But there are interoperability risks if we allow redefinition of SAML semantics through addition of “foreign matter” • The XSLT spec mitigates this with prose

29. Issue: global vs. local element declarations

30. Currently there is a mix of both • E.g., <Conditions> is defined both as: • Local to elements of AssertionAbstractType • Local to elements of AttributeValueType • They happen to have the same definition, but they needn’t • The pattern of global vs. local is unclear • How do local elements get processed, particularly if they have different types? • E.g., how does XSLT distinguish them? Is xsi:type required?

31. Recommendations and discussion

32. Major questions raised here • Should substitution groups be used in the SAML assertion schema instead of the xsi:type framework for extension? • Should <any> wildcards be used to allow extensibility in the three assertion types? • Should we set a restrictive finalDefault for the schema as a whole to close off extensions? • Should we use global element definitions exclusively rather than a mix?

33. YES on #1: Substitution groups instead of xsi:type in our schema • Attribute processing is more expensive than element processing; substitution groups eliminate xsi:type from “pure SAML” schemas • Extensions to native assertions can enable smarter processing even when the derived type is unfamiliar<saml:AttributeAssertion type=“MyAttributeAssertionType”>…</saml:AttributeAssertion> • DocBook role and HTML class provide philosophical precedents

34. NO on #2: <any> wildcards for type extension • The <any> option allows extensions to go “unremarked”; with derived types, extension schemas clearly define their own types and elements • This way, we don’t have to do the design work of figuring out where/how to place the <any>s • We seem to have no particular need for tight control of extensions beyond what XSD extensions offer

35. NO on #3: Restrictive finalDefault for the schema • Why cut off our (or our users’) options? Isn’t this what XML Schema is good at? • But we have to make sure that we disallow proprietary game-playing in our conformance language

36. YES on #4: Universal use of global elements • XML standards and tools are not savvy enough yet to handle local elements “natively” • Those who clamored for this feature had huge DTDs with many subelements, where there were similar but not identical names and characteristics for each “branch” • We don’t have this problem