XML Schema techniques: issues and recommendations

1
XML Schema techniquesissues and recommendations

• SAML F2F 4
• Eve Maler
• eve.maler_at_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 instanceltsamlAssertion
  xsitypeAttributeAssertionTypegtlt/samlAsserti
  ongt

7
Does it meet the requirement?

• Yes, because XSD types are nominally accessible
  to software
• Even if the PSVI isnt truly accessible yet, data
  binding is heavily used
• Model groups are the only other choice
• But being macro-like, they nominally arent
  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

• ltsamlAssertion xsitypeAttributeAssertionType
  gt (Attrib-specific stuff goes
  here)lt/AssertiongtltsamlAssertion
  xsitypeMyAttributeAssertionTypegt
  (Attrib-specific stuff goes here, plus my stuff
  tacked on to the end)lt/AssertiongtltsamlAssertion
  xsitypeMyOtherAttributeAssertionTypegt
  (Attrib-specific stuff goes here, with tighter
  occurrence constraints)lt/Assertiongt

11
Does it meet the requirement?

• Yes users can create extensions and restrictions
  by declaring derived types
• Derived-type elements must use the xsitype
  attribute and element name is always ltAssertiongt
• But this is true of native elements as well

12
Another option for part of the problem

• We could use ltanygt 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

• ltxsdcomplexType nameAttributeAssertionTypegt
  ltxsdcomplexContentgt ltxsdextension
  basesamlSubjectAssertionAbstractTypegt
  ltxsdsequencegt ltxsdany
  namespaceany maxOccurs1/gt
  ltxsdelement refsamlAttribute
  maxOccursunbounded/gt ltxsdany
  namespaceother maxOccursunbounded
  /gt lt/xsdsequencegt lt/xsdextensiongt
  lt/xsdcomplexContentgtlt/xsdcomplexTypegt

14
Example instance of extended attribute assertion

• ltsamlAssertion xsitypeAttributeAssertionTy
  pegt ltsamlSubjectgtlt/samlSubjectgt
  ltsamlDNS_Domaingtlt/samlDNS_Domaingt
  ltsamlAttributegtlt/samlAttributegt
  ltxhtmlpgtlt/xhtmlpgt ltxhtmlulgtlt/xhtmlulgtlt/sam
  lAssertiongt

15
3 Allowing all kinds of assertions to appear in
all the right places
16
Currently done with reference to ltAssertiongt
element

• Assertions may appear in ltAssertionSpecifiergt and
  ltResponsegt
• A plain ltAssertiongt cant be used
• Its type is abstract
• It requires an xsitype attribute to nail down
  the concrete type used

17
Examples, again

• ltsamlAssertion xsitypeAttributeAssertionType
  gt (Attribute stuff goes here)lt/Assertiongtltsam
  lAssertion xsitypeMyAttributeAssertionTypegt
  (Attribute stuff goes here, plus my stuff
  tacked on to the end)lt/AssertiongtltsamlAssertion
  xsitypeMyOtherAttributeAssertionTypegt
  (Attribute stuff goes here, with tighter
  occurrence constraints)lt/Assertiongt

18
Does it meet the requirement?

• Yes, because all descendants from
  AssertionAbstractType can go in those two spots
• Some consequences
• Processors must examine the xsitype 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, xsitype isnt
  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
ltAssertiongt

• ltxsdelement nameAuthenticationAssertion
  typeAuthenticationAssertionType
  substitutionGroupsamlAssertion/gtltxsdelement
  nameAttributeAssertion typeAttributeAssert
  ionType substitutionGroupsamlAssertion/gtlt
  xsdelement nameAuthorizationDecisionAssertion
  typeAuthorizationDecisionAssertionType
  substitutionGroupsamlAssertion/gt

21
Example native SAML assertion elements in an
instance

• ltsamlAuthenticationAssertiongt (Authentication
  stuff goes here)lt/samlAuthenticationAssertiongt
  ltsamlAttributeAssertiongt (Attribute stuff goes
  here)lt/samlAttributeAssertiongtltsamlAuthorizat
  ionDecisionAssertiongt (Authorization decision
  stuff goes here)lt/samlAuthorizationDecisionAsser
  tiongt

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 ltAssertiongt as a head element
• If the SAML assertion schema is changed to use
  substitution groups, extension schemas could
  still define new types and use xsitype

23
Examples user-defined assertions done two ways

• (new type derived from subject assertions can be
  used directly in instance if xsitype is
  used)ltxsdcomplexType nameSessionAssertiongt
  ltxsdcomplexContentgt ltxsdextension
  basesamlSubjectAssertionAbstractTypegt
  lt/xsdextensiongt lt/xsdcomplexContentgtlt/x
  sdcomplexTypegt(add this to schema to use new
  element as substitute for ltAssertiongt element
  without using xsitype)ltxsdelement
  nameSessionAssertion typeSessionAssertionTy
  pe substitutionGroupsamlAssertion/gt

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 XSDs abilities)

27
Example extending the NameIdentifierType type

• ltxsdcomplexType nameMyNameIdentifierTypegt
  ltxsdcomplexContentgt ltxsdextension
  baseNameIdentifierTypegt ltxsdsequencegt
  (after ltSecurityDomaingt and ltNamegt
  comes my new stuff) ltxsdelement
  nameMyHooHaa /gt lt/xsdsequencegt
  ltxsdextensiongt ltxsd/complexContentgtlt/xsdcomp
  lexTypegt

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., ltConditionsgt is defined both as
• Local to elements of AssertionAbstractType
• Local to elements of AttributeValueType
• They happen to have the same definition, but they
  neednt
• 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 xsitype
  required?

31
Recommendations and discussion
32
Major questions raised here

• Should substitution groups be used in the SAML
  assertion schema instead of the xsitype
  framework for extension?
• Should ltanygt 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
xsitype in our schema

• Attribute processing is more expensive than
  element processing substitution groups eliminate
  xsitype from pure SAML schemas
• Extensions to native assertions can enable
  smarter processing even when the derived type is
  unfamiliarltsamlAttributeAssertion
  typeMyAttributeAssertionTypegtlt/samlAttribute
  Assertiongt
• DocBook role and HTML class provide philosophical
  precedents

34
NO on 2 ltanygt wildcards for type extension

• The ltanygt option allows extensions to go
  unremarked with derived types, extension
  schemas clearly define their own types and
  elements
• This way, we dont have to do the design work of
  figuring out where/how to place the ltanygts
• 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? Isnt
  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 dont have this problem