[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] 6.15 status detail formats. Forwarded message from SethProctor.
------- start of forwarded message ------- From: Seth Proctor <seth.proctor@Sun.com> TEXT LOCATION: Following last sentence of Section "6.15 Element <StatusDetail>", p. 68, line 2820. TEXT CHANGE: Append following: Inclusion of a <StatusDetail> element is always optional. However, if a PDP returns one of the following XACML-defined <StatusCode> values AND returns a <StatusDetail> element, then the format of the <StatusDetail> element MUST be as follows: urn:oasis:names:tc:xacml:1.0:status:ok The PDP MUST return no <StatusDetail> element in conjunction with this status value. urn:oasis:names:tc:xacml:1.0:status:missing-attribute A PDP MAY choose not to return any <StatusDetail> information or MAY choose to return a <StatusDetail> message containing one or more <xacml-context:Attribute> elements. If AttributeValues are included in an Attribute, then the PDP is specifying one or more acceptable values for that Attribute. If no AttributeValues are included, then PDP is simply naming attributes that it failed to resolve during its evaluation. The list of Attributes may be partial or complete. There is no guarantee by the PDP that supplying the missing values or attributes will be sufficient to satisfy the policy. urn:oasis:names:tc:xacml:1.0:status:syntax-error A PDP MUST return no <StatusDetail> element in conjunction with this status value. A syntax error is either a problem with the policy being used or with the Request document submitted. The PDP MAY return a <StatusMessage> describing the problem. urn:oasis:names:tc:xacml:1.0:status:processing-error A PDP MUST return no <StatusDetail> element in conjunction with this status value. This status code indicates an internal problem in the PDP. For security reasons, the PDP MAY choose to return no further information to the PEP. In the case of a divide-by-zero error or other computational error, the PDP MAY return a <StatusMessage> describing the nature of the error. DISCUSSION: When status data is returned from the PDP, it may be as result of any number of things, four of which are defined in the specification. For these standard cases, the PEP (or some other entity) will need to be able to handle any extra data that is returned in the status. But the format of status data associated with the four standard status codes is not defined, which is a problem. Here, therefore, is a very simple proposal for what the formats should like. There are undoubtedly more complex solutions, but this seems like the most straightforward approach, and will let different implementions act in similar ways. ------- end of forwarded message -------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC