OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

 

  1. 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.
  2. 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. 
  3. 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.
  4. 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:rphilpott@rsasecurity.com

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC