[no subject]

<Response>
  <Result>
    <Decision>Permit</Decision>
    <Status>
      <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </Status>
    <Obligations>
      <Obligation ObligationId="urn:FIXME:obligation:authorize-results"
FulfillOn="Permit">
        <AttributeAssignment AttributeId="urn:FIXME:attribute:results"
DataType="urn:FIXME:data-type:results">
          <Result ResourceID="service/fmvfmv42/service1">
            <Decision>Permit</Decision>
            <Status>
              <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
            </Status>
            <Obligations>
             <Obligation
ObligationId="urn:FIXME:obligation:authorize-issuer" FulfillOn="Permit">
               <AttributeAssignment
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string";>admaaa01</AttributeAssignment>
               <AttributeAssignment
AttributeId="urn:FIXME:attribute:policyId"
DataType="http://www.w3.org/2001/XMLSchema#anyURI";>admaaa01__6a8c8ba5009dd78a_762bddc6_1071ce30367_-7f5d</AttributeAssignment>
               <AttributeAssignment
AttributeId="http://www.sics.se/distra/issueInstant";
DataType="http://www.w3.org/2001/XMLSchema#dateTime";>2005-10-23T09:50:46+00:00</AttributeAssignment>
             </Obligation>
           </Obligations>
         </Result>
        </AttributeAssignment>
      </Obligation>
    </Obligations>
  </Result>
</Response>

The "authorize-results" obligation contains all permit results from
policies by non-trusted issuers. In this case there is only one result
since only one policy matched, but there could be several. The
delegation obligation handler will generate an administrative request
for each of these results until it finds one that reduces to the trusted
issuer. It is the DelegationObligationHandler which keeps this state of
which administrative requests to generate.

The "authozire-results" obligation is generated by the combining
algorithm. (I am not sure whether this kind of manipulation of the
results is really allowed for a combining algorithm according to the
spec, but it works for me. ;-))

The obligation that is nested inside the result, "authorize-issuer",
roughly corresponds to the PolicyIssuer element in the delegation
profile. It has been generated during policy loading. The subject-id
attribute is the issuer identity, which is taken from the signature of
the SAML assertion the policy arrived in. The issue instant is also
taken from the SAML assertion (although in a real system it would come
from a time stamp authority). The issue instant is needed to resolve
"historic" issuer attributes later on in the processing model, but when
I generated this example today, the PDP was actually running in
"current" issuer attribute mode, so in this case the issue instant is
not used. The policy id is there so we can detect loops later on.

The administrative request that is generated by the
DelegationObligationHandler based on this response is:

<Request>
  <Subject
SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
    ...
  </Subject>
  <Resource>....</Resource>
  <Action>...</Action>
  <Environment>
    <Attribute AttributeId="urn:FIXME:environment:delegationChain"
DataType="urn:FIXME:data-type:delegationChain">
      <AttributeValue>
        <ChainStep
PolicyId="admaaa01__6a8c8ba5009dd78a_762bddc6_1071ce30367_-7f5d">
          <Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string";>
            <AttributeValue>admaaa01</AttributeValue>
          </Attribute>
        </ChainStep>
      </AttributeValue>
    </Attribute>
  </Environment>
</Request>

Since I was constrained by XACML 1.1, I could not add new elements to
the context, so I put the delegates inside an environment attribute. The
ChainStep element is about the same as the request Delegate element in
the delegation profile. In this case there are no indirect delegates,
but if there were, there would be more of the ChainStep elements. They
are ordered and the first one is the Delegate and the remaining are
indirect delegates.

We can see that the delegation obligation handler has passed on both the
issuer id and the policy id in the request. The issuer id is used to
match against the Delegate in the policies (actually in the form of a
delegation chain constraint on the environment attribute since I could
not add more target elements). The ChainStep also contains the id of the
policy. The combining algorithm will skip this policy, to prevent loops.

If the PDP would have been operating in "historic" issuer attribute
mode, the issue instant would have been passed on as well.

Here is an attempt at an ASCII drawing illustrating the situation:

                                  +-----+
                                  | PEP |
                                  +-----+
                                     |
                                     |
                                     |
                                     V
+---------------+      +-------------------------------+
| XACML 1.1 PDP |<-----| Delegation obligation handler |
|               |<---->|                               |
|               |----->|                               |
+---------------+      +-------------------------------+

The PEP sends a regular XACML 1.1 access request to the delegation
obligation handler. The delegation obligation handler sends the access
request to the PDP, which responds with the response above, containing
an obligation with issuers whose authority needs to be verified. The
delegation obligation handler tries with each issuer, passing along the
information that the combining algorithm needs to skip policies to
prevent loops. The whole process my recurse as needed and in the end if
we reach a permit without an obligation to authorize it, we can return a
permit to the PEP.

I have not included the context handler in this picture. It is there and
it is used by the PDP to resolve attributes.

Erik