Re: Proposed XDI TC Charter Revision v1

[Victor Grey <victor@idcommons.org>]

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