July 9, 2008
Identity, trust and policy
This was originally gong to be a part of my post on the interop teleport work. But.. it got out of hand and demanded its own entry, so here it is.
The past few weeks, as I’ve been coding, have also been full of discussion and thought about other parts of the interoperability story. There have been a couple of very good chats at the AWGroupies meetings and Zero Linden’s office hours, about the technical aspects of managing to build out trust and policy between separately run grids. This tends to be a tedious area for discussion because it always happens at the intersection between the technology, and how one can use the technology. Goldie Katsu, has been very helpful in framing some good questions and thoughts, as has Latha Serevi, and many other people who have been in on the discussions.
Based on some of these discussions, here are some thoughts about both the technical approach, and some of the social/legal things that one might enable.
First, what we can, and should do
So, lets start with a few thoughts on the possible, and desirable in this space. We are bounded by the limits of technology, so let’s start with a few bounds:
- We shouldn’t be thinking about doing deep Digital Rights Management. Full up DRM is out of scope for what we can do, and mostly doesn’t work, it’s just a ongoing battle of stopgaps, measures and countermeasures, which annoy users, and don’t actually protect content.
- We shouldn’t be thinking of this as a single solution. There are a broad range of possible policies, and our goal should be to create the protocols and design points to permit people to deploy a range of solutions, and get a range of possible behaviors out of the system. Different uses of the technology, will require different policies and behaviors, we should not merely accept this, but we should embrace it. Some people will deploy environments with very strong content protection policies, others with very weak ones. Some regions will be willing to allow anyone to enter, others will be very restrictive.
- We should plan for trust to be short term, and short range. The longer we hold a trust token, the less reliable it is, and the more links in a trust relationship, the less reliable it is. (Hat tip to Morgaine Dinova, for reminding me of this)
- We should try to capture and make clear to all involved the intents of content creators, and have ways of marking content, and regions for compatibility, so content creators can say “I only want my content in regions which follow rules like X” where we provide for at least a good range of Xs. At the same time, we should not try to break out pick solving problems the semantic web community has not solved in a decade of effort.
- We should, make it as easy as possible for creators of content to properly mark their content, and then, if that content is stolen, we should make it as easy as possible, to show the theft, and allow legal recourse.
Second, a road map of possible technical steps:
So, with those bounds in place, here is a thought on the technical underpinnings we’d want:
- Define and implement a mechanism for establishing identity between components, and in particular, between collections of regions and services (domains) such that we can securely prove that service S, belongs to domain D. As much as possible, this should be built on top of existing, web based mechanisms.
- Define and implement a common mechanism for expressing avatar/user identities across domains/grids. Candidates for such mechanisms include OpenId.
- Create a policy language to allow us to express a range of behaviors between components. Again, as much as possible. based on existing work, Included in this work would be defining a set of policies which would met several common use cases, including permissions similar to those found in Linden Lab’s second life grid, fully open permissions, and use cases developed by the community.
- Design, and implement a set of services for storing, and fetching assets which uses the components built in 1-3.
Third some comments on code, services and choices
The whole space involving moving digital assets between virtual worlds has stirred up a lot of concern, from content creators, content users, and various residents. Some of these concerns are about content being stolen. Some are about people being forced to adopt standards, and others imply that because the OpenSimulator (OpenSim )is an Open Source project, any objects brought to an OpenSim region would instantly become Open Source themselves.
Open Source software refers to how the software is created and maintained. The OpenSimulator project is an Open Source project based on a very open License. Anyone is free to take the code and adapt it in any way they desire. Many people, myself included, view this as a collaborative process, and contribute back our work to the community. Various people contribute to the code, and they have a wide range of thoughts about how they will use the code. In the case of OpenSim, the code can be deployed to host regions, and many people are hosting private regions, or grids of regions. These deployments will be setup and run according to the taste and desires of the deployers.
Saying, interoperability will mean X, or using OpenSim means Y, or all OpenSim developers have agenda Z, is non-sensical. The protocols, the code and how they will be used are seperate things, and they are also separate from the personal beliefs of various developers. Certainly everyone in the process will bring their own interests to the table. But, the actual deployed systems will have policies which reflect the people deploying them. Some will likely have policies which closely mirror those of Linden Lab, others may have policies based on the belief that copyrighting digital objects is a bad idea. The software, and protocols won’t force anyone to use these grids, nor will it force people to put thier content out for use by them.
Service providers, including, perhaps Linden Lab, will, I assume, set policies about what they will permit, and what policies they will require of the grids that wish to connect to their grid. We will, likely see a large range of policies, a large range of opinions, and a process of people choosing which policies work for them. In general, the protocols and the code which implements them will be quite disjoint from the people making the policies. The range of polices that the ecosystem supports will reflect the best guesses of the designers. Most of us, I suspect, know that we don’t know enough to simply get it right with one policy, or one set of policies. I certainly am striving to allow a broad range of choices, and I hope and expect that will be the overall approach taken by the community.
Next steps for interop testing
As you’ve most likely seen by now and IBM and Linden Lab (TM) have announced the completion of testing with a proof of concept version of the AWG(link) protocol. I’m going to dive into some of the details of what’s been done, as well a some discussion of next steps.
The code supporting this proof of concept work, has been posted to the OpenSim mantis.
This is a series of additional steps, beyond the login via aditi work I discussed last month. In particular, it combines additional viewer support, with fuller support for the rez/derez avatar capabilities in both the OpenSim code, and the Linden Lab(TM) beta grid codebase. For the technically inclined, this means that you can login to either an OpenSim Region, or Linden Lab hosted region (currently on a very small number of test grid regions) and then teleport your avatar between sims in both environments.
This teleport preserves your identity, in the form of your avatar’s UUID, which is its unique identifier. Appearance, assets and inventory don’t move. Thus, the collection of generic ruth like avatars seen in the machinema Torley Linden did of some of our testing. In order to manage names and UUIDs sensibly, the OpenSim suffixes your avatars name with a tag, to mark it as having been authenticated via an external agent domain. If you haven’t seen the rather nice machinema Torley pulled, take a look here.
What does this mean?
So, what does all this mean? In the short term, its an exercise in working out technology. A proof of concept, is just what it sounds like. Build enough to see how the design works, find problems, and refine the design. Getting the basic code working gives us an understanding of how to build it properly, and lets us discover problems before they get deeply baked into the implementation.
Does this mean people will be teleporting between OpenSim hosted regions and the main Linden grid, with mad abandon any time soon? Probably not. The code to support this, is deployed in a very specific testbed, and is under active development. Further, while the teleport/login protocol is an important part of an overall story about how the protocol space may evolve, it’s only part of the puzzle. There has been a very active discussion of how to manage assets, permissions and inventory. These discussions have technical, legal, and social implications, and are happening in a fairly large number of places, from blogs and forums to inworld meetings, to casual one on one chats.
As usual, a bunch of cleanup. Code working is not code the way you want it. So, some cleanup is planned, with updates to the community. Beyond that, some discussion on things we learned, and working with the community to do wider testing. For those interested, Whump Linden, is leading up this work at Linden.
Beyond the proof of concept on teleport, is a whole range of issues about managing trust, allowing creators to express the terms they wish to apply to the use of thier objects, and then design, protocol and code which actually enables assets to be moved in a fashion that respects desires of the creators. This topic got so big I broke it into a seperate entry.
June 5, 2008
At about 11:00 AM, Linden, Ruth arrived on an OpenSim server, quite quietly. and to her surprise. We had been testing some code, and I’d asked Layla Linden to try to log on again, to see how the bug looked on the client side. But.. the latest fix, put on moments earlier, was, in fact, the last one we needed. I logged in as well, and several other folks from Linden lab joined us. Here we have Me, Layla Linden and Tess Linden.
What’s to unusual about logging into OpenSim? Nothing. But.. this wasn’t a normal login. All three Avatars had been logged on via the Agent Domain in the Linden Lab Aditi test grid. The Agent Domain took a “place_avatar” request from the client, and issued a “rez_avatar” request to the OpenSim, which handed the Agent Domain the necessary details so it could relay it to the client, and permit a login. We’re all Ruth, because we’re not yet syncing the agents with openSim inventory yet. That’s just a small matter of programming… (Well, that’s what we programmers always say.) We have no inventory, and we’re stuck on the single region. But.. It’s a very nice first step.
Next steps will include better syncing with the OpenSim environment, handling teleport in and our requests, and then starting in on how to fetch assets from the test grid. As the code gels a little more, it will get posted to the OpenSim tree, so that people who want to explore this function, can enable it for testing.
Perhaps as importantly, we’re starting to generate concrete feedback to the protocol and architecture work, based on actually coding to it.
* * * * Added June 8th * * * *
Just to clarify a few points after talking to a number of people. This is very preliminary testing, and very much a “Oh, ok, so we can make this work, now we need to solve these three or four problems.” And, of course, when I say get posted to the OpenSim tree, it means submitted to the community, for the usual review process. Additionally, one of the things which needs to happen for me to feel comfortable with the shape of the code, is making it very easy to chose whether or not to run it, and how to manage it. Trying to be a good open source community member and all.
For those wondering about the implications of this work in terms of how Second Life is going to evolve? I’m certainly not the person to speak to about such things. Linden Lab runs Second Life, and they are the only people who can speak to their plans. I will point out, that this is a very first step, along a fairly long path that’s been discussed repeatedly by Linden and participants in the Second Life Architecture Working Group. There are a large number of steps from simple hacked code, to anything resembling a set of inter operating worlds. Discussion and proposals on how to manage trust, content protection (Bounded by technical reality) and similar issues, are part of the ongoing discussions.
As always, feedback, comments, and thoughts are more than welcome. Here, in world, or via e-mail
April 11, 2008
Disclaimer: I work for IBM, some of this material directly relates to my day job. I am not, however speaking in an official capacity. Your mileage may vary. Contents may have settled during shipping.
As many people have noticed, IBM and Linden Lab have announced a project where we are hosting a small number of regions inside the IBM firewalls, as part of exploring secure Second Life regions and future interoperability issues. (Press Release:)
I’ve had a couple of chats with people inside SecondLife, and at VW2008, about how this is happening, and what it might mean in terms of the grid, content creation, the interoperability work that is being done at the Architecture Working Group, and the OpenSim project. This entry is an attempt to summarize those thoughts
Let’s start with the very basics of what we’re doing. IBM and Linden Lab are setting up a small set of regions to run on a single IBM BladeCenter, behind the IBM firewall, with a small local asset server. The asset server, just like the beta grid, is a write-local asset server. What that means is that assets created on these regions end up in the local asset server. Things put into inventory on these regions end up on the local asset server. When the regions, or avatars on the regions fetch an asset, they go to the local asset server. If it has the asset, it serves it up. If it doesn’t, it fetches it from the main grid asset server. We plan to setup a local Vivox voice cluster. The rest of the region services come from the main linden grid. (Beta at the moment, main grid, as we validate the environment.) Note that the behind the firewall asset server won’t be visible from the main grid. Assets created on that asset server won’t be visible on the main grid.
Effectively, these regions form a set of island which are more secure than a regular island because chat, local rezzed assets, and stored assets can live in a region IBM controls. They are otherwise on the grid. They share the Linden asset cloud, they share Linden’s central services, and utilities. Users will log on with their main grid identity. Users logged into the regions will appear online to the main grid, able to receive IMs. Finally, these regions will fully honor the Linden mod/copy/transfer rules. (With an odd twist, playing with non-copy objects on these regions will end up with the asset trapped behind the firewall.)
This is a separate work item from any of our interoperability work. Its a chance for IBM and Linden to explore some of the things which happen when we can run islands which meet corporate needs for secure assets and chat. I am sure that we will learn some things about managing sub-grids, and about how the space gets used, which will inform some of the interoperability efforts, but. other than things of that nature, it is an unrelated project. IBM and Linden Lab have an ongoing collaboration, this is one of the efforts which had emerged from that work.
Several people have wondered if this would allow IBM to snag copies of assets from the main grid. Since this all happens inside the Linden Grid, the answer is no. An object on one of the private regions is as much on the grid as an object on any other private estate.
Someone suggested an Asset server would define a grid. In fact, I think that’s not the right way to think about what makes up a grid. An asset server is in the business of storing, and allowing grid components to fetch digital assets. An asset server can enforce some properties, such as only allowing one copy, of a non-copy asset to be on the grid or meta-gried, An asset server may chose which grid components it wishes to talk to. In a larger mesh of grids, asset servers are likely to be willing to talk to any region which they share a trust relationship. If this is the case, then that doesn’t help us define a grid at all.
I’d argue, tho, fairly softly, that a grid is going to be defined by the boundaries of its trust. Grids will most likely share core policies, and have a common trust policy. and.. we will probably see people define a broad range of grids, with different policies on assets, property rights and how they share objects.
Again, softly, I would argue that we are going to see many regions and grids which talk to multiple sets of asset servers. In the future, I might well have my clothing and shape fetched from a Linden Lab asset server, while rezzing objects from my personal virtual world hosting server’s asset server, on a landscape filled with trees from another “grid’s” asset server. Just like web pages today, some regions will be very homogeneous, filled with locally created and hosted content. Other regions will be filled with content linked in from across the greater set of grids
Finally, I’d observe that, while kicking off some thought about what we mean by “grid” didn’t fall isn’t part of why we are doing work like hosting a secured region, the fact that such questions come up, and get some attention, is desirable. Doing projects like this give the community concrete examples of some of the ways people will build out the virtual worlds space over the next few years.
March 26, 2008
So.. SL:Dale Innis twittered away a few days ago, that I should start blogging some of the things I mentioned in my twitter. So Dale gets blamed. Well, Dale did that, and then I went to one of SL:Sophrosyne Stenvaag’s salons and had a bunch of things I had opinions on. and I thought, maybe I ought to blog that. So.. maybe Soph gets the blame. Well, then I said something in passing which someone said “you ought to blog that.” So.. maybe you all get the blame.
I don’t promise to blog on any regular basis. Anyone who knows me won’t be shocked by that. I’ll mostly be talking about Virtual Worlds stuff, especially thoughts on the technical and social sides of the emerging cloud of virtual worlds and social collaborative spaces.