[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Issue/editorial comment: Description of<Condition> processing in core-28
I wasn't sure if this would be considered just editorial since I recommend some rewording:
Lines 540-553: The discussion of condition and assertion status is confusing
"If an assertion contains a <Conditions> element, the validity of the assertion is dependent on the sub-elements and attributes provided. When processing the sub-elements and attributes of a <Conditions> element, the following rules MUST be used in the order shown to determine the overall validity of the assertion: 1. If no sub-elements or attributes are supplied in the <Conditions> element, then the assertion is considered to be valid. 2. If any sub-element or attribute of the <Conditions> element is determined to be invalid, then the assertion is invalid. 3. If any sub-element or attribute of the <Conditions> element cannot be evaluated, then the validity of the assertion cannot be determined. 4. If all sub-elements and attributes of the <Conditions> element are determined to be valid, then the assertion is considered to be valid."
Personally, I feel that we should also state exactly what it means when the validity of an assertion is invalid or cannot be determined. For example, if invalid, "the assertion MUST NOT be used". But I wasn't sure what to say for the indeterminate case.
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:rphilpott@rsasecurity.com
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC