RE: [security-services] Action Item A23

[Chris McLaren <cmclaren@netegrity.com>]

> Sorry to be potentially out of touch with reality, but has
> this proposal
> already been approved as is?  I just have a few questions,
> but in general
> support it.

Not formally approved as is. I mentioned it at the F2F and got buy-in from
the room. The discussion stemming from my post is intended to lead up to
making it official.

> - I have to admit I find it a little weird to naming elements
> <AbstractFoo>
> since any element that actually occurs in an instance will be
> disturbingly
> concrete.  What is the rationale for the existence of (the new)
> <AbstractAssertion>, when (the new) <Assertion> allows any desired
> configuration?

Well, I want the element that someone puts in their document to contain an
assertion to be called <Assertion>. That's why I propose renaming
<MultipleAssertion> to <Assertion> once we had done away with
<SingleAssertion>.

However, I'm not 100% clear on why the <Assertion> element, as it exists
before anything I am proposing, is in the schema today. The best answer I
could come up with was that it is a generic extension hook created to allow
you to specify the inclusion of something that has an assertion header, but
not necessarily statements... Hence the proposal to call it abstractX. If
there is another reason for the current <Assertion> element existing it
might suggest a better candidate for a new name.

> - I've tried this suggestion several times, but I'm not sure
> if everyone's
> politely wishing it will go away or desperately hoping that
> others will
> speak up for it: If (the new) Assertion can potentially
> contain multiple
> statements and if its main function in life is to provide
> common metadata
> etc., then I think a good name for it would be something like
> <AssertionPackage>.  It doesn't imply singularity or
> multiplicity, and it
> alerts a human that the statements all semantically "go
> together" with the
> common information.

While I completely agree with this, it is not related to the specific action
item I had. Write it as a separate proposal to the list and I'll agree to
it. (Of course, if we make the <Assertion> an <AssertionPackage>, then one
could argue that all the <XStatement> elements should then be renamed to
<XAssertion> elements...)

> - Have we indeed settled all our semantic issues about cases
> where multiple
> statements appear in an assertion?

Yes. Multiple statements appearing within an single assertion have the same
semantics as if each one appeared alone in an assertion with the same header
data. Presumably this extends to multiple assertions within a documents.

We explicitly say nothing about the interpretation of multiple statements,
particularly contradictory ones. That is a policy issue and out of scope for
SAML.

C.