Review of the XACML Obligation Profile for Healthcare

[Steven Legg <steven.legg@viewds.com>]

Hi Mohammad and the TC,

Overall, I don't see a compelling need for obligation families in respect of
the obligations in the "XACML Obligation Profile for Healthcare", either for
sequencing or overrides. This profile could dispense with obligation families
and be simpler as a result.

When considering the relative ordering of pairs of the obligations, I find
that, apart from one exception that I will come back to, the order is either
immaterial, or the semantics of the obligations means that only one ordering
of the pair is useful. For example, why would anyone ever choose to redact
a field after encrypting the record containing it? Giving administrators the
ability to choose the order in which a pair of obligations are processed when
there is only one sensible order is just giving them the opportunity to specify
the stupid alternative.

This profile could just nominate a processing order for these obligations as
a requirement on PEPs and save a lot of hassle, especially for the PDP. I
suggest wording something like this:

    "The PEP MUST process the obligations in this profile such that the final
    outcome is identical to processing the received obligations in the following
    order:
        Human Approval
        Version-Range
        Redact
        Aggregate-Field
        Abstract-Field
        Pseudonymize-Field
        Anonymize-Record
        Mask-Field
        Encrypt-Field
        Encrypt-Record
        Audit-Trail
        Delete after Use
        Delete
        No-Redisclosure
        Enforce Policy

    Of course, this requirement is satisfied if the PEP actually does process the
    obligations in this order, but the PEP may reorder individual obligations where
    that reordering does not alter the final outcome. For example, Redact and
    Encrypt-Field obligations applying to different fields could be processed in
    any order."

We can leave it up to implementations to fiddle with partial ordering if they
choose.

The one exception mentioned above is the pair of Aggregate-Field and Abstract-Field.
Either order makes sense, but they can produce different results. However, there
is another issue with these obligations. Although the sample functions for
Abstract-Field operate on independent data-types and the sample functions for
Aggregate-Field are commutative, they are both extensible, so there is no guarantee
that those properties will continue to hold. Thus the ordering of multiple instances
of Aggregate-Field or multiple instances of Abstract-Field may become significant.
I note that the syntax for sequential obligation classes doesn't have the
expressive power to reliably impose an order between two obligations with the same
identifier. Rather than extend the syntax of obligation schema, I suggest you
just add an integer "precedence" attribute to these obligations so that policy
writers (or a cognisant PAP) can impose an absolute ordering for the different
functions, or the same function with different parameters (it may be more convenient
to have a "secondary precedence" attribute to order instances of the same function
with different parameters). To address ordering issues between Aggregate-Field and
Abstract-Field obligations I suggest you merge them into one obligation, perhaps
called Transform-Field. The "Precedence" attribute then allows an absolute ordering
of the combined list of functions.

On the subject of ordering, the [HOP]:order attribute is unnecessary. Half of the
obligations require it to be present with the value [HOP]:order:pre. Rather than
require the PDP to provide this attribute it would be easier to make this ordering
part of the semantics of these obligations by adding a statement like:

    "This obligation MUST be processed before the requested access is performed."

The Encrypt-Field, Encrypt-Record, Delete after Use, Delete, Audit-Trail,
No-Redisclosure and Enforce Policy obligations are already clear about when their
effects are to be applied so no further statement is required for them. Since
the profile is vague about actions, specifying ordering with respect to those
actions can be confusing for these latter obligations anyway.

The situation with respect to overrides isn't so clear-cut and you haven't used
overrides in any examples to motivate the need for them. From my view point,
the obligations are mostly independent of each other so there is no compelling
need for overrides in those cases. For example, would anyone ever really need to
have a Redact obligation override a No-Redisclosure obligation, or vice versa?
While in principle someone could, for example, define Aggregate-Field to override
Redact, I'm more inclined to say that Redact always wins just to make things
simpler. Likewise for any other combinations. A separate, future profile could
always introduce overrides if a case for them arises.

With or without overrides, it wouldn't hurt to describe what happens when
obligations operate on the same field, particularly fields that may have been
redacted. For example, in the description of the Encrypt-Field obligation say
something like:

    "If the field to be encrypted is not present, e.g., because it has been redacted,
    then this obligation is trivially satisfied without performing any processing."

Statements should also be added to address instances where the same obligation
is applied multiple times to the same field or record. For example, what happens
if there is more than one Encrypt-Record obligation for a record and those
obligations nominate different cipher suites? In that particular case I would
say the strongest suite wins, where "strongest" is implementation-defined.

Finally, I'll end with an observation. If site A is storing its medical records
in the cloud, and site B is storing its medical records in the cloud, then they
don't really need to be exchanging medical records anymore, only references to
medical records. If medical records can be accessed in situ by all participants,
then a significant part of this profile becomes redundant. Technological trends
may obsolete this profile before you finish it, especially if it gets bogged
down waiting for obligation families to be sorted out.

Regards,
Steven