[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes from XDI TC special meeting Friday 16 May 2008
I apologize for taking so long to post these notes from our XDI TC special meeting on May 16 -- I was tied at two conferences last week. ATTENDING IN PERSON Nat Sakimura Tatsuki Sakushima Markus Sabadello Drummond Reed ATTENDING VIA TELECON Bill Barnhill Andy Dale John Bradley 1) REPORT ON INTERNET IDENTITY WORKSHOP AND DATA SHARING SUMMIT Nat, Tatsuki, Markus, Drummond, Kermit Snelson, Victor Grey, Gabe Wachob, Andy Dale, and John Bradley all attended these events and held several sessions on XDI. They were well attended and well received. There was particularly strong interest in i-pages, the XDI-backed personal data sharing service developed by Andy Dale, John Bradley, and Steve Churchill; and in relationship cards (r-cards), the information card-based data sharing service using XDI being developed by the Higgins Project. 2) DISCUSSION OF RDF QUADS At the Data Sharing Summit, there was discussion of RDF quads and their use in the Linked Data model. Bill explained that some RDF practitioners are using it for reification, and some are using it for subgraphs. It started as Named Graphs and has now become part of SPARQL. 3) LINK CONTRACT REQUIREMENTS AND DESIGN IN THE ATI MODEL Andy reported that there was consensus in discussions at IIW that link contracts fall into two parts: the network enforceable part and the non-network enforceable part. * The network-enforceable half consists of operators on a set of XDI references to data. * The non-network enforceable half consists of policy that applies to the first set, and must include a reference to the jurisdiction of the contract. Andy explained that this differs from DRM in that it is not intended to be a mechanism for enforcement of rights over digital objects, rather simply a method for expression of the terms and conditions of a data sharing relationship. Andy and John went on to explain that in the XDI ATI model, access to data in an authority's graph is always provided through a single root node in a graph. You must find at that node a signed contract. The contents of that contract is a signed and countersigned set of references to the data that is governed by the contract. ooTao's implementation of this brings only the "permissioned graph" into memory. This is done by using a small number of queries or "pattern matching rules" for data sets. These queries can use the XDI query operators. The query language has been built out of three primitives: $all, $descendants, and $children. In conjunction with the XRI delimiters, this covers the way you crawl the tree. Andy's and John's view is that it is critical that the protocol and data model be very explicit about how that works so that permissioning is unambiguous. Example: doing a $set on an address of a node that has two links and a ref could have impacts beyond what is expected. With regard to the non-network enforceable half, here the outer structure is a container called $contracts that contains a $contract that contains a $social.policy and $network.policy. The $social.policy contains the URL where the document can be found together with a copy of the actual document. Bill pointed out that anyone who has access to data under a contract must have access to the contract itself. Contracts can reference data in other contracts. 3A) LINK CONTRACT SIGNATURES In the XDI ATI model, Andy explained there are two forms of signatures: one to a set of XRIs that cannot be changed without needing a new signature, one to an identifier of a data set that can change. The first authority (the provider of the contract) signs the contract and then the other authority signs it. You can just have the requester's signature, since the provider persists the contract. However countersigning is necessary if the requester wants a copy. One option for doing that is countersigning only when data is requested. 3B) LINK CONTRACT STRUCTURE The ATI model uses the XRIs $link and $contract. An instance of $link will contain an XRI to an authority - that's the other party to the contract. $link is linked to one or more $contracts. The signed contract ends out covering XDI data on the $link node. Andy suggested that we could use the policy work being done by Liberty. 3C) LINK CONTRACT NEGOTIATION Unfortunately Andy and John ran out of time to go over the negotiation protocol that Andy, Steve, and John have developed and had to leave the call. We agreed we'd like to do that in a future call. 4) LINK CONTRACTS IN THE XDI RDF MODEL We next went over the link contract structure illustrated in the Link Contract section on page 31 of the XDI RDF Model document: http://wiki.oasis-open.org/xdi/XdiRdfModel Markus explained the basic pattern of using a link contract template defined by the XDI subject originally developing the contract. This template is then instantiated by an XDI subject wishing to enter into a contract by adding the link contract XRI as a predicate. The object is a subcontext containing the XDI subjects granted permission under the contract and the predicates (operations) applying to each. The objects of these predicates are subcontexts defining the XDI graph ranges to which these permissions apply. 5) NRI LINK CONTRACT USE CASE Bill Barnhill had to leave the call at this point, so the final part of the session was devoted to Drummond and Markus reviewing with Nat and Tatsuki the link contract use case that NRI has for OpenID trusted data sharing: http://wiki.openid.net/Trusted_Data_Exchange Since the NRI team has already identified the necessary link contract elements in an XML schema, it was agreed that the XDI TC should undertake the job of analyzing how this could be converted to an XDI RDF link contract following the design pattern discussed here. # MARKUS to do a first pass strawman proposal. (DONE -- see http://lists.oasis-open.org/archives/xdi/200805/msg00039.html). # DRUMMOND to add this to the agenda for XDI TC calls in June.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]