Re: [security-services] Action Item A23

["Eve L. Maler" <eve.maler@sun.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.

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

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

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

         Eve

At 03:05 PM 12/4/01 -0400, Chris McLaren wrote:
>Proposal:
>Eliminate the <SingleAssertion> Element and SingleAssertionType.
>Rename the <Assertion> element to <AbstractAssertion>.
>Rename <MultipleAssertion> to <Assertion> and MultipleAssertionType to
>AssertionType.
>
>Rationale:
>In the current core the <Assertion> element is of type AssertionAbstractType
>and contains assertion header data and no statements. <SingleAssertion> is
>of type SingleAssertionType and contains assertion header data and exactly
>one statement. <MultipleAssertion> is of type MultipleAssertionType and
>contains assertion header data and ZERO or more statements.
>
>There are a number of problems with this.
>
>First of all it is entirely possible to construct a SAML assertion
>containing one statement in two valid ways: as either a <SingleAssertion>,
>or as a <MultipleAssertion> that contains exactly one element. In general we
>want to avoid creating languages that allow you to say the same thing
>different ways--primarily to avoid the possibility of implementers drawing a
>distinction between the two cases.
>
>I would suggest doing away with the <SingleAssertion> element and type
>altogether, since it's functionality is entirely incorporated into the
><MultipleAssertion> element and type.
>
>Theoretically we lose the benefit of being able to make slightly more
>efficient systems for cases where it is KNOWN that only single statements
>will be contained in the assertions passed. I would assert that this benefit
>is illusory, but that even if it were real in some cases it's loss is
>certainly outweighed by the fact that general SAML systems would not have to
>handle both <SingleAssertion> and <MultipleAssertion> elements--without even
>considering the general gain of avoiding the "two ways to say one thing"
>problem.
>
>Secondly there is the problem of the <Assertion> element. I assume that it
>is declared to allow people to specify that other elements will contain an
>"assertion", and that the intention is that in practice this will be
>populated with an descendant type that is identified via the xsi:type
>notation. In other words, I think the intention is that no one will even
>create an <Assertion> element that actually has the "AssertionAbstractType"
>type--they will only ever use it as a placeholder to indicate that a
>descendant of the "AssertionAbstractType" should be inserted. If this is the
>case then I suggest that we make this explicit by renaming the <Assertion>
>element to <AbstractAssertion>.
>
>Thirdly, we can now rename <MultipleAssertion> to <Assertion> and
>"MultipleAssertionType" to "AssertionType".
>
>The result:
>A core where the <AbstractAssertion> element is of type
>"AssertionAbstractType", and contains only assertion header data, and the
><Assertion> element--which is of "AssertionType" contains assertion header
>data and zero or more statements.
>
>No new schema is required, only changes to this:
>
>         <element name="AbstractAssertion" type="saml:AssertionAbstractType"/>
>         <complexType name="AssertionAbstractType" abstract="true">
>                 <sequence>
>                         <element ref="saml:Conditions" minOccurs="0"/>
>                         <element ref="saml:Advice" minOccurs="0"/>
>                 </sequence>
>                 <attribute name="MajorVersion" type="integer" 
> use="required"/>
>                 <attribute name="MinorVersion" type="integer" 
> use="required"/>
>                 <attribute name="AssertionID" type="saml:IDType" 
> use="required"/>
>                 <attribute name="Issuer" type="string" use="required"/>
>                 <attribute name="IssueInstant" type="dateTime" 
> use="required"/>
>         </complexType>
>
>and this:
>
>         <element name="Assertion" type="saml:AssertionType"/>
>         <complexType name="AssertionType">
>                 <complexContent>
>                         <extension base="saml:AssertionAbstractType">
>                                 <choice minOccurs="0" maxOccurs="unbounded">
>                                         <element ref="saml:Statement"/>
>                                         <element 
> ref="saml:SubjectStatement"/>
>                                         <element 
> ref="saml:AuthenticationStatement"/>
>                                         <element 
> ref="saml:AuthorizationStatement"/>
>                                         <element 
> ref="saml:AttributeStatement"/>
>                                 </choice>
>                         </extension>
>                 </complexContent>
>         </complexType>

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