Next in thread → Next in month →

RE: [security-services] Feedback on SAML 1.1 Assertions (sstc-saml-core-1.1-cs-01.pdf)

From
Philpott, Robert <>
Date
2003-05-29T19:02:42+00:00
ID
Thread
RE: [security-services] Feedback on SAML 1.1 Assertions (sstc-saml-core-1.1-cs-01.pdf)
Hello John,

 

Thanks for your review feedback.  My
comments are embedded below.

Rob Philpott 

RSA Security Inc. 

The Most Trusted Name in
e-Security 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: 

-----Original Message-----

From: John Kemp
[mailto:] 

Sent: Thursday, May 29,
 2003 2:41 PM

To:


Subject: [security-services]
Feedback on SAML 1.1 Assertions (sstc-saml-core-1.1-cs-01.pdf)

 

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.

 

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

Thanks,

- John Kemp

______________________________

John Kemp / 

(+1) 413.458.9053 / frumioj@AOL

Coordinating Editor / Project Liberty
Next in thread → Next in month →