Bill, quickly:
1) Yes, the XDI TC call is at noon EST tomorrow, so if that fits
your lunch break, we'd love to have you.
2) All the terms in the Service Dictionary
should be $words. +words (often call +tags now) are defined by practice not by
spec.
3) XACML could make lots of sense for
machine-readable policies, however I suspect many link contracts won't need
them, just an XRI reference to a standard well-known policy.
4) Much to talk about on link contract
structure. We'll start on tomorrow's call.
Best,
=Drummond
From: Barnhill William
[mailto:barnhill_william@bah.com]
Sent: Tuesday, November 08, 2005
3:47 PM
To: Victor Grey; XDI TC
Subject: RE: [xdi] Re: Proposed
XDI TC Charter Revision v1
--My apologies if this is double posted, I'm having a
problem with our webmail.--
I've also always considered link contracts to be the most important aspect of
XDI, and the best value added to the XRI spec.
I'd suggest that rather than re-inventing a policy language and framework we
look at another OASIS spec, XACML. I think that the spec as it is may fit our
needs, and if not the spec is very extensible and so we can add as needed to
get what we want, similar to what Toktar et al. did for using XACML to
policy control RSVP (see thrid link below). Here are some links on XACML:
http://dev2dev.bea.com/pub/a/2004/02/xacml.html
http://www.computerworld.com.au/index.php?id=997396262&fp=16&fpid=0
http://www.ppgia.pucpr.br/pesquisa/sisdist/papers/2004-policy-toktar-jamhour-maziero.pdf
If consensus is to explore XACML further I suggest we contact Rebeka Metz
(metz_rebekah@bah.com) , one of the very active personnel on the XACML TC, and
someone who I believe we have consulted before.
Whether we go with XACML or another policy language we need to determine how to
tie it to the resource accessed. My first thought was one of the following, in
order from what I thought least elegant to most:
a. A policy element that's a child of the resource controlled
b. a resource child of the resource controlled with a special $ word relative
XRI
c. a resource child of the resource controlled with a special + relative xri as
defined by the service dictionary
But then I realized that the link contract is not an attribute of the resource
being controlled, but rather an attribute of the arc between the resource being
accessed and the entity doing the accessing, as identified by their i-name or
better yet i-number.
With that in mind I'd like to toss out the following idea:
A +word as defined by the XDI Service Dictionary deliverable that sits at the
root of each XRI authority, when that authority offers the XDI local access
service. A rough example of the XRI used to access the policy resource that
controls xri://=bob accessing xri://@communitivity*foo*bar/baz*bak/bok would be
xri://@communitivity*foo*bar*(@xdi*(+policy))/(=bob)/baz*bak/bok
which would return an XDI document containing the policy information in the
data element of the root resource. You could even use synonyms to have .../(=bob)/...
go to
xri://@communitivity*foo*bar*(@xdi*(+policy))/(@communitivity*groups/longtimeusers)/baz*bak/bok
You'd need to control access to these resources as well, since most sites won't
want their policy publicly available. This has the added benefit of not being
tied to the XDI schema in any way other than that an XDI resource has a single
data element.
Unfortunately I am in training all day tomorrow, so unless I can convince
everyone to break at the right time I won't be able to join the call. A well-timed
lunch break is possible though as I think the call is at noon EST, but will
have to check. If not, my apologies in advance.
Thanks Victor, great points!
=Bill.Barnhill
-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org]
Sent: Tue 11/8/2005 1:49 PM
To: 'XDI TC'
Subject: [xdi] Re: Proposed XDI TC Charter Revision v1
There is a real disconnect for me in the current proposed XDI charter.
As an implementer, the most important part of XDI to me is the concept
of "link contracts". These, as the proposed charter states, are to
support features including those to "govern authorization, access
control, usage control, synchronization, and rights management."
However, the list of deliverables does not even mention link contracts!
What's more, the proposed charter says "As a data sharing service, XDI
is intended to be very simple and generalized." The one example I have
seen so far of an attempt to implement anything like XDI is, imho,
anything but simple and generalized. What's more, it doesn't include
any actual implementation of link contracts.
Link contracts are the one thing that I would need to try to do any
useful implementation, even experimentally. I think that the lack of
work and attention to this aspect has been a huge drag on progress.
Therefore I would like to propose something rather radical -- that we
stand our approach to XDI on its head, and start from the link
contracts end, rather than the schema end. A link contract, in my
conception, would look quite a bit like an XRID (perhaps an XDID?), and
would gain from our recent experience with crafting an XRID spec that
is simple enough that it may actually be useful to non-XRI
technologies.
An XDID would be a (simple as possible, all elements optional) schema
capable of describing authorization, access control, usage control,
synchronization, and rights management. It would be returned in
response to a data query, similar to the way an XRID is returned in
response to an authority query. It would contain a section analogous to
the <service> section of an XRID, but would instead be a
<serialization> section, where the available data structures could be
discovered. This would allow data in -any- XML format (and any other
format really -- anything serializable) to be addressed with XRI and
controlled with XDI.
If there is a demand for the uber-XML format that the XDI TC has been
struggling with for two years, work on this could continue, but
progress and implementation experience would not have to be held
hostage to that ambitious undertaking.
=vg