Re: Comments on the use of Substitution groups,and Phil's proposal to decouple the assertion header from the statements.

[George Robert Blakley III <blakley@us.tivoli.com>]

All

>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.
>
>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 think in most cases a relying party receiving an assertion will know from
context
which type of assertion it's received, and will therefore know which type
of Statement to look for.

If this is not the case, we could always put an explicit assertion-type
indicator
element into the Assertion schema to tell the relying party which Statement
type
is included in the Assertion.


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

Again, I think at least half of this isn't a serious problem.  Certainly
any reasonable programmer faced with the necessity
to walk through a list of Statement types would write the code as:

     for I=1 to NUM_STMT_TYPES do
          {
          get (*stmt-type)
          if *stmt-type not NULL then break
          }

rather than as:

     for I=1 to 4 do
          {
          get (*stmt-type)
          if *stmt-type not NULL then break
          }

As far as knowing that SessionStatement is a Statement, new code will need
to do more than just know that
SessionStatement "is a statement" -- it will need to know lots of things
about how to process and use it.
So maybe even this isn't a problem.

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


Chris McLaren <chris.mclaren@ieee.org>@netegrity.com> on 08/29/2001
04:30:34 PM

Sent by:  Chris McLaren <cmclaren@netegrity.com>


To:   "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, "Eve Maler (E-mail)"
      <eve.maler@sun.com>, dorchard@jamcracker.com
cc:   security-services@lists.oasis-open.org
Subject:  Comments on the use of Substitution groups, and Phil's proposal
      to decouple the assertion header from the statements.



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.

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
xsi:type="AuthenticationStatementType>

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.



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

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
"AuthenticationStatementType".




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

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.

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.

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

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.



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.

C.


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>