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] Proposal to make CompletenessSpecifier go away


I took an action to write a proposal to make the CompletenessSpecifier 
attribute on AuthenticationQuery disappear, and to replace it with a 
tightening up of the protocol for handling responses to such queries.  In 
this proposal, the requester doesn't have control over response 
completeness, but the responder now discloses information about response 
completeness.

Though CompletenessSpecifier was a feature that was asked for strongly by 
some who read this list, the TC has tentatively decided that the 
alternative proposed below is preferable.  WE SEEK INPUT on whether the 
alternative will really break something that somebody wants.

The changes I describe below are in the context of the core-21 draft:

   http://www.oasis-open.org/committees/security/docs/draft-sstc-core-21.pdf

- Remove Section 3.2.1, Simple Type CompletenessSpecifierType, lines 
742-759.  Also, from the complete schema listing, remove the declaration of 
this type (1413-1418).

- In Section 3.4.4, Element <AttributeQuery>, remove lines 897-902.  Also, 
from the schema fragment here and in the complete listing, remove the lines 
(916-917 and 1479-1480) that declare this attribute.

- To Section 3.2.2, Simple Type StatusCodeType, starting on line 760, add a 
new status code of "Incomplete".  Define it as follows: "The request 
produced incomplete results due to reasons other than processing failure. 
Such a failure might be caused, for example, by the nonexistence of a 
requested attribute or by the fact that the policy in effect at responder 
site does not allow the requester to see the attribute requested."

- Change the schema fragment and complete schema listing to reflect the new 
status code (lines 772-779 and 1419-1426).  The new declaration will look 
like this:

<simpleType name="StatusCodeType">
     <restriction base="string">
         <enumeration value="Success"/>
         <enumeration value="Incomplete"/>
         <enumeration value="Failure"/>
         <enumeration value="Error"/>
         <enumeration value="Unknown"/>
     </restriction>
</simpleType>

- To Section 3.4.4, Element <AttributeQuery>, change lines 904-905 by 
saying that "If no attribute designators are supplied in the query, then 
all available attributes for the subject will be returned with a status 
code of Success."

ISSUE: Should a status of "Incomplete" apply to more than just attribute 
queries?  I could see it being useful for the others as well.  I have made 
the language defining "Incomplete" to be nonspecific, though the examples 
are currently all from the attribute domain.

ISSUE: We still need to get more specific about which status code should be 
used in case of processing failure (for example, a back-end resource that 
needed to be consulted was temporarily unavailable).  Should this be 
Failure or Error?  The general area of status codes is already an 
outstanding issue.

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com



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


Powered by eList eXpress LLC