← Prev in month
← Prev in thread
Next in thread →
Next in month →
[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
It would be more readable if the description of
processing conditions were moved after the definition of conditions.
That is, move 540-553 after the schema fragment.
The section uses multiple ways of referring to the result
of processing the <condition> elements of an assertion:
"assertion status", "validity status", etc.
Calling it an "assertion status" can get confused with a
<status> element in a response.
The font and description of "Valid, Invalid, or
Indeterminate" makes one think these are enumerated values defined somewhere
in the standard, which they obviously aren't since they aren't
transmitted in assertions or messages. Is this an accepted way to describe
processing logic? I found it confusing.
I'd like to suggest the following new text for
540-553:
"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:
← Prev in month
← Prev in thread
Next in thread →
Next in month →