2.12.2 Matching Pledges to Sticky Policies and Obligations

When delivering response to data request, the Responder outbound PEP compares the pledges that were received in the request and checks that the sticky policies and obligations that are attached to the data coming from the backend repository can be satisfied given the pledges. This ensures that the Responder will never ship out data unless the Requester has clearly committed itself to respect the sticky policies and obligations.

Example

Consider the following request

  <e:Envelope>
    <e:Header>
      <!-- WS-Addressing headers and wsse:Security with DSIG not shown -->
      <b:UsageDirective id="USE">
        <xa:Obligation ObligationId="urn:tas3:sol1" FulfillOn="Permit">
          <xa:AttributeAssignment
              AttributeId="urn:tas3:sol1:pledge"
              DataType="http://www.w3.org/2001/XMLSchema#string">
            urn:tas3:sol:vers=1
            urn:tas3:sol1:delon=1255555377
            urn:tas3:sol1:use=urn:tas3:sol1:use:purpose
            urn:tas3:sol1:share=urn:tas3:sol1:share:group
            urn:tas3:sol1:repouse=urn:tas3:sol1:repouse:oper
         </>
        </>
      </>
    </>
    <e:Body id="BDY">
      <idhrxml:Query>...</></></>

Now, backend returns the following data

  <dataItem id="1">
    <tas3sol:Obligations xmlns:tas3sol="http://tas3.eu/tas3sol/200911/">
      urn:tas3:sol:vers=1
      urn:tas3:sol:delon=1255555378
      urn:tas3:sol1:use=urn:tas3:sol1:use:transaction
    </>
    <data>value</>
  </>

  <dataItem id="2">
    <tas3sol:Obligations xmlns:tas3sol="http://tas3.eu/tas3sol/200911/">
      urn:tas3:sol:vers=1
      urn:tas3:sol:delon=1255555376
      urn:tas3:sol1:use=urn:tas3:sol1:use:purpose
      urn:tas3:sol1:repouse=urn:tas3:sol1:repouse:all
    </>
    <data>value</>
  </>

  <dataItem id="3">
    <tas3sol:Obligations xmlns:tas3sol="http://tas3.eu/tas3sol/200911/">
      urn:tas3:sol:vers=1
      urn:tas3:sol:delon=1255555378
      urn:tas3:sol1:use=urn:tas3:sol1:use:purpose
      urn:tas3:sol1:repouse=urn:tas3:sol1:repouse:oper,repouse=urn:tas3:sol1:repouse:stat:weekly
    </>
    <data>value</>
  </>

The first data item would have to be filtered out because its usage policy is "transaction" while requester pledged usage for intended "purpose". Intended purpose can span many transactions, therefore its broader that the allowed use. Note that the delon constraint would be compatible with the request.

The second data item has to be filtered out for two reasons: (i) its delon is stricter that what requester pledged, and (ii) the repouse constraint is more onerous than requester is willing to perform.

The third data item's obligations are compatible with the requester's pledges. It is returned to the requester.

N.B. This is just an example. The way in which the obligations are attached to the data can be quite different from the illustrated, e.g. internal C data structure rather than XML. It is also possible that obligations are not stored with the data, but rather generated by a PDP based on data dependent sticky-policies.

Once the Responder Outbound PEP has filtered the data, it is sent, with the obligations, to Requester which MAY pass the obligations to Obligations Service for enforcement.