2.12 TAS³ Simple Obligations Language (SOL)

TAS³ Architecture foresees that a Service Requester needs to express obligations and policies that it is willing and able to respect, and on the other hand the personal data will have associated with it obligations and policies ("sticky policies") under which the data can be or is released.

In general the obligations and sticky policies can be expressed in any convenient language. Unfortunately no standard language has emerged in the industry for this type of application despite many being proposed. TAS³ is committed to supporting multiple such languages, but for purposes of pilots and other simple applications we define "TAS³ Simple Obligations Language nš1" (SOL1) with potential future versions to follow.

SOL obligations MAY be used in XACML obligations as described in [TAS3D71IdMAnAz]. In particular, D7.1 Appendix A1.2 provides an example. In short, they MUST appear in an Obligation/AttributeAssignment element. When passed in <b:UsageDirective>, <xa:Obligation> element MUST be used as a wrapper. Use of <xa:Obligation> element as a wrapper in other XML contexts is RECOMMENDED.

N.B. Since SOAP headers in TAS³ are generally signed, the <b:UsageDirective> header constitutes signed pledge to honour the obligations. This is similar to Signed Acceptance of Obligations (SAO) concept of Obligation of Trust (OoT) protocol described in [Mbanaso09] et al. Put another way, the pledge expresses the Capabilities. We effectively optimize the OoT Protocol Scheme (sec 3.2) by avoiding iterative discovery of capabilities and moving directly to the signed pledge phase (5 in fig. 5).

The ObligationId XML attribute of <xa:Obligation> element is used to specify the obligations processor (module that the PDP should invoke to evaluate the obligation). Some processors may be simple in which case the ObligationId completely identifies the nature of the obligation.

When using SOL, however, the sematics of the obligation depend on the actual SOL expressions passed in the <xa:AttributeAssignment> child element of <xa:Obligation>. In this case the ObligationId merely identifies the obligations processing engine. The SOL1 obligations processor is identified by ObligationId value "urn:tas3:sol1". The actual SOL1 expressions are held in <xa:AttributeAssignment> elements with following AttributeId XML-attributes:

urn:tas3:sol1:pledge

Obligations that WSC pledges to honour if it receives them in any response data.

urn:tas3:sol1:require

Obligations that the emitting party requires to be honoured. Typically this is used to attach obligations to the data that is returned.

There MUST only be one <xa:AttributeAssignment> with each AttributeId, i.e. there can only be zero, one, or two <xa:AttributeAssignment> elements in <xa:Obligation> element. There MUST only be one <xa:Obligation> element with ObligationId "urn:tas3:sol1" and there MUST only be one <b:UsageDirective> in the SOAP message.

The DataType XML attsibute of the <xa:AttributeAssignment> MUST always have value
"http://www.w3.org/2001/XMLSchema#string". The FulfillOn XML attribute of <xa:Obligation> element SHOULD, in absence of more specific guidance, be set to "Permit".

The urn:tas3:sol:vers Query String parameter allows for versioning of the obligations language. The actual obligations are expressed using URL Query String Syntax with attribute value pairs expressing the obligations. Newline (0x0a) MAY be used as separator instead of an ampersand. Should escaping be needed, the URL encoding MAY be used.

Example

  <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:forpurpose
            urn:tas3:sol1:share=urn:tas3:sol1:share:group
            urn:tas3:sol1:repouse=urn:tas3:sol1:repouse:oper
      </xa:AttributeAssignment>
    </xa:Obligation>
  </b:UsageDirective>

As can be seen from the example, the attributes are actually URNs and each attribute tends to express an obligation that is required by data or that the Requester promises to honour.