This creates false trust: the honest grid operator is trusting the protocol to transmit permissions to the dishonest one, but what happens on the remote side is not under his or her control. Granted, as soon as they find out, they’ll sever the connection: but the harm would already be done. What to do next? The resident who got their content stolen could, ironically, sue the honest grid operator because they didn’t protect their permissions. The honest operator, however, would claim in court that they did, indeed, send the object across to the dishonest operator with all perms intact. However, what happens on the other grid is not under the honest operator’s jurisdiction. A different grid works under a different ToS. And the dishonest operator could in fact argue very convincingly that he never signed an agreement not to strip metadata out of the protocol, but just to accept the assets “as is” — what he does on his own grid is his problem. Oh, and the original creator is not his customer, so he has no responsibility over it. Worse: he can even claim that the item arrived full perms on his servers, and show fake logs “proving” it. It would be the word of the honest operator against the dishonest one: each can, in turn, show their own logs and support their claims. Ironically, the dishonest operator has a slight advantage here: he could say that because the protocol enforces permissions, he can only have gotten a full perm copy of the asset and that the honest operator made a serious mistake.
IBM/LL’s system, on the other hand, make a quite different assumption: if data is cryptographically signed, you cannot tamper with it. So, using the above example, the honest operator would be allowed to say: “my logs are real and yours are fake, because I can prove through the digital signatures on all assets that they had no perms when they left my grid”. As you well know, if you change a document that was digitally signed, the signature will not check. So the honest operator would be able to make a strong case that he had, indeed, delivered all assets with the correct permissions, and that after these were received by the dishonest operator, the permissions were changed.
Granted, a dishonest operator might not argue that he got digitally signed no-perms assets, but he could still argue that “what happens on my grid is nobody else’s concern”.
Here is where LL’s policy-based intergrid connections solves the conundrum. Like the peering agreements between Internet operators, LL can enforce their policies using a contract between interconnected grid operators and LL itself; and using digital signatures, they can prove they’re sending assets with the correct set of permissions. It’s up to the foreign grids to comply with those permissions; if not, they’re in violation of the agreement with LL: and in the short term, it means revoking the digital signatures and not exchange any more assets with that particular grid; in the medium/long term, it means having all necessary proof for a strong case in a court of law.
From a purely technical point of view, this is, in fact, the best way to deal with this complex issue, which, as you can see, has few parallels on the Internet, where all content is pretty much exchanged “without permissions” (or, rather, with full copy permissions). There is, however, a good example with BGP routing. And there is a pretty good example on how this was actually solved.
