The doc looks interesting. At
first blush I'll note a few things:
1. The details on policy representation are
interesting, but I'd be against creating our own schema when we can reuse an
existing one that's further along in the standards process..be it XACML or
something else. I will flesh out my ideas on a XACML/DSA union and distill them
into a posted doc before the next telecon. I'm also still wondering if there's a
benefit to leveraging xlink, combined with XACML, in here somewhere.
2. I LIKE the idea of steering clear of
link contracts as a term. Jamie Clark was the one that first sent up a flag on
this and I think his points still very valid, contract denotes enforceable and
legally binding, which a digital document in itself cannot be right now.
Agreement is a softer term, but conveys the same basic meaning, so I'd propose
we adopt Andy's DSA (Data Sharing Agreement) as the std term for what we've
referred to as a Link Contract.
3. I think we need a set of XDI
authorization services that encapsulate policy retrieval, policy update, and
policy enforcement and I'd like those services (and others) to be as xri-centric
(x-centric ?) as possible. There seems to be a correlation between REST urls and
a DataWeb version of REST that uses XRIs. A very rough example of which is the
policy retrieval mechanism I mentioned in the previous email, where you create
an XRI from a $policy template that combines the i-name of the subject, the
action, and the target of the action. This XRI would return a policy
fragment in the schema we adopt, such as XACML or whatever.
4. I don't like the idea of treating the
XDI resources controlled as attributes of a DSA, or even of the DSA that
expresses the controlling policy being an attribute of the resource being
controlled. For me the policy is an attribute of an arc between the accessor's
i-name and the resource being acted on. There could be multiple arcs, one for
each type of action, or one overall access arc. I'd also suggest giving
some though to the distinction of policy control based on i-name versus policy
control based on i-number. For example, a person may have rights to data
they access while wearing a particular hat and an org may need to make
it clear that they only have access to that data when they are representing that
community by accessing that data using that's communities i-name.
Essentially they can only access the data while using the org's resources, which
has legal ramifications and could be very important.
More thoughts later,