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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


      The PDP MUST return no <StatusDetail> element in conjunction
      with this status value.


      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>

      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
      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.

      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


    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