RE: [security-services] Action Item A23

[Irving Reid <Irving.Reid@baltimore.com>]

> From: Eve L. Maler [mailto:eve.maler@sun.com]
> At 04:55 PM 12/5/01 -0400, Chris McLaren wrote:
... 
> >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.
> 
> This is my question, I guess: What's the rationale for 
> AbstractAssertion 
> (your name) to exist?  Since SAML statements that go inside assertion 
> wrappers can be extended in every way, shape, and form (and 
> don't even have 
> to contain subject information), I don't see how the additional 
> extensibility of offering a generic AbstractAssertion does us 
> any good.
> 
> If whoever championed this (Phill?) can just articulate a 
> rationale for its 
> existence that's consonant with what we're trying to do, then 
> I'll shut up...

I wasn't the champion of this, but...

My understanding was that the abstract <Assertion> element in core-19
existed so that it could be specialized to <SingleAssertion> and
<MultipleAssertion>. Now that we no longer have the distinction, I believe
we no longer need the <AbstractAssertion> element. I suggest we fold its
contents into Chris' new <Assertion> element and remove <AbstractAssertion>.

 - irving -


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.