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: FW: Comments on the use of Substitution groups,and Phil's proposal to decouple the assertion header from the statements.

Title: Re: Comments on the use of Substitution groups, and Phil's proposal to decouple the assertion header from the statements.
-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Thursday, August 30, 2001 11:55 AM
To: Chris McLaren
Cc: eve.maler@sun.com
Subject: Re: Comments on the use of Substitution groups, and Phil's proposal to decouple the assertion header from the statements.

Hi Chris,

[Can you please forward this to the list?  My posts are bouncing right
now.  Thanks!]

At 06:00 PM 8/29/01 -0300, Chris McLaren wrote:
>First, on Phil's proposal: I think it's a good idea for all the reasons we
>have discussed. For example having the <Assertion> element contain the
>statements allows us to easily do things like "grab all assertions". The
>additional degree of freedom of extending from statements, or from assertion
>itself is also helpful.

I agree that allowing the "factoring out" of metadata from one (or,
particularly, multiple!) assertions can make sense, and since Phill has
particular extension scenarios in mind that make use of multiple assertions
grouped together, we've perhaps got a concrete reason to want to do this.

The two-level terminology is something that we've struggled with for
months.  I have to say that "Assertion" (high-level metadata wrapper) vs.
"Statement" (low-level thing that actually contains the substance of the
assertion) really doesn't help things, and is similar to the old
"Assertion" vs. "Claim" language that caused so much confusion.

This week, Phill used something like "assertion package" to describe the
higher-level wrapper, which is pretty similar to some of the names Dave and
I were batting around in our draft.  In accordance with the SSTC domain
model and all the discussions we've had to date, I think the lower-level
construct has to be (or end in) "Assertion".  For the higher-level
construct, I would find the following terms workable:

AssertionPackage (preferred because it doesn't discriminate against
   single-assertion innards)

>The second issue is that of how we will specify in schema the various
>statement types. As I understand it we have three options:
>1) Use type substitution. All things will be of the form <Statement
>2) Use subsitution groups. Statements will look like
><AuthenticationStatement>. (This contains the implicit notion that we will
>block the ability of extension schemas to add to the subsitution groups--per
>our discussion at the F2F.)
>3) Explicit definition of the type of the assertion as a choice between a
>pre-defined list of types. My understanding from Eve is that this is
>functionally equivalent to the use of substitution groups with blocking. I'm
>not going to discuss this as a separate option, but rather assume that it's
>another way (and perhaps a better one) to arrive at the same result as 2.

It's actually a choice among elements, not types.  I'll expound on this to
the whole list only if some others clamor for it. :-)

>Now after the F2F we are leaning towards the use of substitution groups with
>blocking. My understanding is that this gets us the following benefits:
>1) The actual documents are easier to read. Clearly
><AuthenticationStatement> is more easily understood by people who aren't
>schema-heads than <Statement xsi:type="AuthenticationStatementType">.

A small benefit, but teachability is one sign of a good standard.

>2) We get better "ancestor" processing for cases where an extension is not
>understood by the processor. That is, if I get an <AuthenticationStatement
>xsi:type="McLarenSpecialAuthenticationType"> I can still deal with it as an
>AuthenticationStatement even if I don't know what a
>"McLarenSpecialAuthenticationType" is. In the type substitution case if what
>I got was a <Statement xsi:type="McLarenSpecialAuthenticationType">, still
>assuming I don't know what the definition of
>"McLarenSpecialAuthenticationType" is, then I could only deal with it as an
>instance of "StatementType" and not as an instance of


>It seems to me that those two arguments are enough to swing the decision in
>favour of this solution, and that seemed to be the general feeling of the
>However, I do feel the need to point out a couple of things about this
>solution, just to make sure everyone understands the potential downsides of
>this solution:
>1) It is much harder to work with "Statements" at the top level of
>abstraction. For example if you wanted to write some code to get the
>"statement" inside an <Assertion>--something everyone will have to do, and
>frequently--you would have to look for an instance of the <Statement>
>element, or an instance of the <AuthenticationStatement> element, or an
>instance of the <AttributeStatement>, or an instance of the
><AuthorizationDecisionStatement>. In other words, every time you want to
>work with the general class of statements you have to handle the fact that
>there are N (where N=4 in this case) different things you have to look for.

Well, yes, but if you have access to types, you should theoretically be
able to key off of "all elements whose type is Assertion or a descendant of
Assertion".  Also, I would think that the most interesting processing of
the various assertions is the stuff that's *different* between them.  If we
factor out the metadata into a package-level element, then that processing
can happen on occurrence of that element.  The remaining commonalities are
things like the Subject element, which I would guess is probably going to
be processed differently depending on whether it's in (e.g.) an AuthN
assertion or an Attrib assertion.

>If, in the future you can have multiple statements in an <Assertion>, or
>multiple <Assertion>s in some package, this problem continues and gets worse
>by another order of magnitude.

I've worked with DTDs that have many dozens of choice options in some
contexts.  This is child's play. :-)  Seriously, as long as these elements
have a common ancestor type, I don't see the worry.

>Under the type substitution paradigm, on the other hand, you only look for a
><Statement> element. It is easier to work at the abstract level.
>2) The addition of a new Statement type by the TC (as opposed to the
>addition of a new type by other parties via extension) results in an
>increase to the value of N, which essentially would break all existing code.
>For example, assuming we add a "SessionStatement", and this is made
>substitutable, then every place where we perform an operation on a statement
>needs to be re-written to understand that a <SessionStatement> is also a
>statement. Back to the example of getting a statement out of an <Assertion>,
>the code to get the statement now requires a re-write to also check for the
>Under the type substitution paradigm these changes by us to our schema don't
>break processors that operate at the general level of statements. Only the
>new code to handle the new type is necessary, not any changes to the
>processors at the more abstract levels.

It doesn't break them "syntactically", but semantically they still won't
have a clue (unless, again, they have access to the common ancestor type of
interest).  I see what you're driving at, but it seems like an impossible
goal to build perfect silent upgradeability into any XML language, and
adding new assertion support in one's and two's seems reasonable.

FWIW, I'm not sure this would help, but maybe we should consider publishing
new revisions in two forms: A real update to our SAML schemas, plus a
"temporary extension" schema that mimics the changes but uses the xsi:type

>I don't know if these flaws with the processing at the abstract level of
>statements are enough to swing the decision back, but I do feel that we need
>to point them out. If I am wrong about these problems, I'd love to
>understand why.
>If we can address these problems inside the framework of the subsitution
>group solution (or Eve's type choice variant), that would clearly be the
>ideal solution.


Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

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

Powered by eList eXpress LLC