XML Schema techniques: issues and recommendations SAML F2F #4 Eve Maler 28 August 2001

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

Issue CONS-04: Extensibility of assertions

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

#1: Factoring out commonalities

Currently done with complex types AssertionAbstractType –SubjectAssertionAbstractType AuthenticationAssertionType AuthorizationDecisionAssertionType AttributeAssertionType Example instance: …

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

#2: User-defined extensions and novel kinds of assertions

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

Examples (Attrib-specific stuff goes here) (Attrib-specific stuff goes here, plus my stuff tacked on to the end) (Attrib-specific stuff goes here, with tighter occurrence constraints)

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 –But this is true of native elements as well…

Another option for part of the problem We could use 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

Example: extensible attribute assertions without new types

Example: instance of extended attribute assertion … … … … …

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

Currently done with reference to element Assertions may appear in and A plain can’t be used –Its type is abstract It requires an xsi:type attribute to nail down the concrete type used

Examples, again (Attribute stuff goes here) (Attribute stuff goes here, plus my stuff tacked on to the end) (Attribute stuff goes here, with tighter occurrence constraints)

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

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)

Example: native SAML elements substitutable for

Example: native SAML assertion elements in an instance (Authentication stuff goes here) (Attribute stuff goes here) (Authorization decision stuff goes here)

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 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

Examples: user-defined assertions done two ways (new type derived from subject assertions; can be used directly in instance if xsi:type is used) … (add this to schema to use new element as substitute for element without using xsi:type)

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

Issue CONS-03: Subtyping in general

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)

Example: extending the NameIdentifierType type (after and comes my new stuff)

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

Issue: global vs. local element declarations

Currently there is a mix of both E.g., 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?

Recommendations and discussion

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

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 … DocBook role and HTML class provide philosophical precedents

NO on #2: wildcards for type extension The 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 s We seem to have no particular need for tight control of extensions beyond what XSD extensions offer

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

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