OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC