RE: Use of Substitution groups?

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

"Its not a bug - its a feature"

I had some thoughts too,

1) We are assuming that Eve and Dave were not proposing substitution groups
because they did not like them, they may have had other reasons for not
proposing them, like being worried about what the group will accept. Hence
best wait for them to return from their holidays to ask their position.

2) It appears to me from the Schema specs (!) that the two mechanisms are
not exclusive. Specifying substitution groups in the SAML spec does not
preclude extension specs using the xsi:type attribute, and vice versa.

2a) So I can use my substitution groups in XTAML even if SAML does not use
them.

2b) If SAML does use them XACML could still decide not to use them.

3) Chris's point about schemas is interesting. It could even be used as a
switch. If you want the extended schema to be processable without knowing
the extension schema you would use the xsi:type attribute, if you wanted to
prevent that you would use a substitution group.

3a) A generalized assertion processor is not going to be able to do anything
with a new assertion type except to check the conditions to see if it is
valid. Buth that might be a legitimate use case.

3b) Taking Chris's argument and turning it arround, say I have an
'ExtendedAttributeAssertionType' type. I might well want the SAML engine to
know that this is still an <AttributeAssertion> and so have something like
<AttributeAssertion xsi:type="ExtendedAttributeAssertionType">

4) Using substitution groups for the Conditions element would ensure that
the conditions semantics were observed at the schema validation level!

5) I think we are now getting to understand why XML Schema has this somewhat
odd system. Last night I was pondering the fact that XML appears to have to
interdependent type systems. Elements are types and XMLSchema types are meta
types. That is why drawing the schema diagrams is hard.

6) I am down to five pages of core 11 on the 'merge process'. Almost
anything is more fun than describing the <Subject> element concisely.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Chris McLaren [mailto:cmclaren@netegrity.com]
> Sent: Thursday, July 26, 2001 1:10 PM
> To: 'Hallam-Baker, Phillip'; 'Security-Services (E-mail) (E-mail)'
> Subject: RE: Use of Substitution groups?
> 
> 
> I've been thinking about this issue some more on a mental 
> back-burner over
> the last couple of days and I think I've come to a 
> realization that puts me
> squarely in the "type-substitution" camp even after we get a 
> consensus draft
> out.
> 
> Here's the realization I had: With type substitution a SAML 
> processor has a
> chance to deal intelligently with a message containing an "unknown"
> assertion type, whereas with a substitution group the 
> processor would have
> to more-or-less throw its hands up in the air. "Unknown" in 
> this case means
> "defined in a schema that the processor is not aware of".
> 
> For example let's assume, for the sake of argument, that 
> sometime after SAML
> 1.0 is accepted we publish an extension to the schema for Session
> Assertions. If we use type substitution a SAML1.0 aware processor that
> doesn't understand the new schema can still: identify an 
> <saml:Assertion
> xsi:type="samlX:SessionAssertionType"> element as an 
> assertion, and work
> with the attributes (version, ID, etc.) that are common to 
> all assertions.
> 
> This also means that a piece of software that identifies 
> assertions within
> other XML documents would not need to undergo any code 
> changes to support
> new assertion types.
> 
> In the best case our processor can isolate the assertion and 
> pass it along
> to another component that might understand 
> samlX:SessionAssertionType. Worst
> case it should be able to make a statement that it found an 
> assertion of
> type "samlX:SessionAssertionType" that it doesn't know how to 
> deal with.
> 
> Contrast this with the same example where we use substitution 
> groups. Now
> our SAML1.0 processor encounters a <SessionAssertion> 
> element. It has no way
> to know, since it doesn't know about the schema extension, 
> that the element
> is part of the Assertion substitution group. It can do 
> nothing, really.
> 
> Thoughts?
> 
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Tuesday, July 24, 2001 5:23 PM
> > To: 'Chris McLaren'; Hallam-Baker, Phillip;
> > 'Security-Services (E-mail)
> > (E-mail)'
> > Subject: RE: Use of Substitution groups?
> >
> >
> >
> > On the timing, I am currently editing the core doc on the 
> basis of the
> > consensus schema with some reordering of elements but without
> > substitution
> > groups.
> >
> > I will probably punt on the description of certain linkages 
> within the
> > schema for now since one of the reasons I would like to make
> > the change is
> > to make some things easier to explain.
> >
> > There are a couple of other changes that would make the
> > explanation somewhat
> > easier, for example declaring all elements that are of a saml
> > specific type
> > as toplevel elements would allow the prose to refer only to
> > elements rather
> > than having to switch back and forth between elements and types.
> >
> > I don't think we should come to a decision on this topic
> > before I release
> > the 11 draft, and even if we did reach a decision I won't get
> > arround to
> > editing it until the next revision cycle. However I don't
> > think we need to
> > avoid discussion. Parallel processing is a good thing.
> >
> > 		Phill
> >
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> > > -----Original Message-----
> > > From: Chris McLaren [mailto:cmclaren@netegrity.com]
> > > Sent: Tuesday, July 24, 2001 4:12 PM
> > > To: 'Hallam-Baker, Phillip'; 'Security-Services (E-mail) (E-mail)'
> > > Subject: RE: Use of Substitution groups?
> > >
> > >
> > > I hope your intention is to open this as an issue for
> > > discussion _after_ the
> > > consensus schema is accepted by the TC. I agree that it 
> needs to be
> > > discussed (this is the reason it is called out as an issue in
> > > the discussion
> > > doc), but I think we can leave it until after the committee
> > > accepts the
> > > consensus doc.
> > >
> > > Assuming that is the case, a few other notes for everyone to
> > > consider on
> > > this issue, in preparation for that discussion:
> > >
> > > 1) Note that either solution provides the same features, 
> it's only a
> > > question of howl the SAML document looks.
> > >
> > > 2) The "W3C XML Schema Design principles" section of the
> > > Orchard-Mahler
> > > proposal is really required reading for this discussion. Also
> > > it links to
> > > many interesting readings on the topic.
> > >
> > > 3) The decision of how to do inheritance affects more 
> than just the
> > > assertion types. In the proposed schema we have type substitution
> > > inheritance taking place in the <Assertion> element, in the
> > > <Condition>
> > > element, and in the <SAMLQuery> element. As Phil notes, the
> > > <Condition>
> > > element would need to be promoted in order to become the head of a
> > > substitution group. I would assert that it makes sense to
> > use the same
> > >
> > > In general, I can see arguments for both sides, and I would
> > > like to see a
> > > broader discussion within the TC on this point--ideally with
> > > some commentary
> > > from people who have worked with both substitution groups and type
> > > substitution in the past on other XML languages.
> > >
> > > C.
> > >
> > > > -----Original Message-----
> > > > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > > > Sent: Tuesday, July 24, 2001 4:21 PM
> > > > To: Security-Services (E-mail) (E-mail)
> > > > Subject: Use of Substitution groups?
> > > >
> > > >
> > > >
> > > > All,
> > > >
> > > > 	Starting from the core-schema-assertion-10.xsd
> > > > proposal, I suggest
> > > > that we use substitution groups in place of the current 
> mechanism.
> > > >
> > > > [Incidentaly we have traced the cause of the previous
> > > > problem, I was working
> > > > from the documents sent to me by Prateek which had
> > > > <AttributeAssertion>
> > > > elements in the examples, it turned out that I had been sent
> > > > an earlier
> > > > version of the document than the one that went to the list
> > > > and had assumed
> > > > that the two were the same except for the Visio documents.]
> > > >
> > > >
> > > > The practical imporance of this is what the toplevel elements
> > > > look like,
> > > > whether it should be
> > > >
> > > > <Assertion xsi:type="AttributeAssertionType">
> > > >     ...
> > > >
> > > > or
> > > >
> > > > <AttributeAssertion>
> > > >     ...
> > > >
> > > >
> > > > In order to make this change we would have to add in the
> > > > following element
> > > > definitions:
> > > >
> > > > <element name="AuthenticationAssertion"
> > > > 	type="saml:AuthenticationAssertionType"
> > > > 	substitutionGroup="saml:Assertion"/>
> > > > <element name="AuthorizationDecisionAssertion"
> > > > 	type="saml:AuthorizationDecisionAssertionType"
> > > > 	substitutionGroup="saml:Assertion"/>
> > > > <element name="AttributeAssertion"
> > > > 	type="saml:AttributeAssertionType"
> > > > 	substitutionGroup="saml:Assertion"/>
> > > >
> > > > [The condition type would also need modification to match,
> > > this would
> > > > involve promoting condition to a toplevel element first since
> > > > substitution
> > > > groups have to be top level elements]
> > > >
> > > > The one complication to extension is that the extension
> > > > schema would have to
> > > > remember to include to include the line adding the 
> element to the
> > > > substitution group.
> > > >
> > > > On the plus side this would simplify DOM type programming
> > > > since one can pull
> > > > out assertions of a particular type with a single selector
> > > rather than
> > > > having to first select on the element name and then filter on
> > > > xsi:type.
> > > >
> > > >
> > > > 		Phill
> > > >
> > > >
> > > >
> > > > Phillip Hallam-Baker FBCS C.Eng.
> > > > Principal Scientist
> > > > VeriSign Inc.
> > > > pbaker@verisign.com
> > > > 781 245 6996 x227
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

Phillip Hallam-Baker (E-mail).vcf