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

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 / 

(+1) 413.458.9053    /    frumioj@AOL

Coordinating Editor   /   Project Liberty

PGP.sig