Re: [security-services] Feedback on SAML 1.1 Assertions (sstc-sam l-core-1.1-cs-01.pdf)

[John Kemp <john.kemp@earthlink.net>]

Rob,

See other comments inline, but in general, I would just note that I approached my reading of the specification from the perspective of someone actually extending the assertion statement structure provided by SAML - at the schema level this is quite clear, but I think that the text surrounding the schema perhaps doesn't do complete justice to the extensibility of the SAML assertion statement structure. 

On Thursday, May 29, 2003, at 15:15 US/Eastern, Philpott, Robert wrote:

> 1. lines 324-326 note that three kinds of assertion are specified by SAML. When reading the schema, <Statement> and <SubjectStatement> are treated as if they might appear independently of these three kinds of assertion, which is not in fact the case - they are for extensions that specify additional kinds of assertion. I would recommend that this distinction is made clear in this introductory text.
>
> [Rob] Actually, line 325 states that the SAML specification defines three different kinds of assertion **statements**.� This, I think is technically accurate since the <Statement> and <SubjectStatement> elements are defined with abstract types and we only define 3 types of statements that are based on <SubjectStatement>.��� Or did I miss your point? Nonetheless, I do think we could clean up this non-normative description a bit.

Yes, I'm not saying that you state anything incorrectly. It is, however, a little confusing when reading the schema to see that <Statement> and <SubjectStatement> appear alongside the three assertion statement types mentioned in the introduction, when in fact <Statement> and <SubjectStatement> MUST be xsi:type-substituted in some external schema (to create statement extensions), and the other three are first-order SAML assertion statements, derived from the <SubjectStatement>. 


> �
>
> 2. line 331 states that "Assertions have a nested structure". 'Nesting' implies that one assertion may be contained within another, which as far as I can tell from the schema is not possible. I would recommend that this sentence be changed to note that an "assertion acts as a container for a number of assertion statements" or some similar text.
>
> [Rob] This could use a bit of clarification since the reference to nesting doesn't really apply to the subsequent sentence.� We'll work on cleaning that up.� Note, however, that assertions can actually be nested. This can occur when
>
> -������an <Assertion>element includes an <Advice> element, which can include an <Assertion> element
>
> -������an assertion contains an <AuthorizationDecisionStatement>element, which can include an <Evidence> element, which can include an <Assertion> element.
>
> -������Extensions are defined based on various extension points that can exist within assertions

OK - I missed that, but I think my point holds anyway, as I did think this paragraph was probably referring to the assertion holding common elements that applied to the statements made within. 

________________________________
John Kemp / john.kemp@earthlink.net
(+1) 413.458.9053    /    frumioj@AOL
Coordinating Editor   /   Project Liberty

PGP.sig