July 9, 2008

Identity, Trust and Policy

Posted in AWG, Musings, SecondLife tagged , , , at 8:30 pm by zhaewry

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:

  1. 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.
  2. 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.
  3. 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)
  4. 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.
  5. 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:

  1. 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.
  2. Define and implement a common mechanism for expressing avatar/user identities across domains/grids. Candidates for such mechanisms include OpenId.
  3. 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.
  4. 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.

~ Zha



  1. Alex said,

    I would suggest… if I may (I’m in the ‘digital ID’ space since 1998)… please… PLEASE… be careful with the ‘OpenID’ hype. It’s NOT an ‘ID’ in any sense of the word. I would say – it’s even less on an ‘ID’ than the free web-based e-mail address (because it doesn’t give the ID consumer the channel of communication to the ID owner)…
    Please be careful with this overhyped s…t. It’s completely USELESS for the VW problem, but you will spend time on it instead of something really helpful.

    The idea of ‘deteriorating trust’ is not new, and it’s NOT TRUE. Example: financial industry (which I belong to), commerce… mmm… business in general. Business reputation gets BETTER with time if ‘nothing bad happens’ or nothing happens at all. So, business-wise this idea is FALSE. Information-wise it is true, because the data tends to change and becomes irrelevant very fast. Kinda’ ‘entropia’ obviously (and you can even do the math by the way). See the difference?

    Also, I was going to write you for some time already. We’ve launched a digital ID / payment platform lately and would like to cooperate with you on OpenSIM project. Could you possibly drop me a line from your valid address to p (at) yolto (dot) com ?

  2. Edward Artaud said,

    In your prescriptions for what should be done, it is highly desirable for content creators to be allowed to use whatever technology-based protections they choose, just as they can on the Web. Interoperability on the Web and the Internet does not preclude DRM, and as the last few days of iPhone mania have shown us, tens of millions of users can and will rally around internet services based on technologies such as DRM and code-signing without hesitation. If the true goal is the growth and long-term viability of a true open metaverse, then at this stage, it’s important that the fundamental architecture neither restricts those who want to implement secure content and applications infrastructure nor imposes such infrastructure on those who wish to forgo access to such content and services. I’m comfortable with the idea that Open Grid efforts don’t seek to provide features like DRM as long as such capabilities can be implemented by third parties. I believe many developers will see a huge market opportunity in creating such technologies to protect digital assets.

  3. Prokofy Neva said,

    I’ve taken on Zha’s post line by line, of course, because I think she, like others gathering around this discussion, are failing to explain a simple thing: why can’t copy/mod/transfer be preserved and extended? and why can’t “trusted” mean those grids that recognize, respect, *and implement* copy/mod/transfer permissions? It’s simple, and I find an enormous amount of ideological and political obfuscation being thrown up around this in the name of the faddish opensourceish movements around AWG, and faddish things like OpenID.

    I am so glad that two smart people showed up here in the comments, one to debunk OpenID on technical grounds, which correlates with reservations any ordinary user will have with it who isn’t drinking the Kool-Aid, but more important, questioning of this all-or-nothing approach to DRM. Edward’s post and ideas on the JIRA seem brilliant, but I’ve heard plug-ins get batted away before as not doable on the SL Dev list and I’d like Zha to really go through it. Sounds like a great solution.

    My problem with it is that I don’t see why *Linden Lab itself* cannot be the developer that “sees a huge market opportunity in creating such technologies to protect digital assets” and leading the way on this, instead of undermining IP with vague promises and engineering that is not sequenced to protect first, but connects first and merely makes vague promises to add on protections later.

    Why not have LL take the lead on this, and those third parties that don’t seek to protect DRM can fork off — and then be trusted or not.

    The iPhone is a good example. Some extremist geeks complain they can’t rip it and try to break it apart, but as Edward said, tens of millions have rallied around it. That’s what’s important to watch.

  4. Reality said,

    Here is your reality Check for the day Prokofy: The iPhone is nothing more than the new status symbol – like the iPod before it.

    Any time you see such a large number of sales being directed at such a restricted piece of Technology you are seeing little more than a host of sheep that believe the hype concerning such devices and treating it like the Messiah.

    “Oh> where is your iPhone? even Danny Nobody down the street has one! Now he is Danny Somebody. What? You do not have one? You do not WANT one? Well then Sam, looks like you’re a Nobody.”

    Do not believe me? Just ask any teenager in High School today that has an iPhone or iPod. Anyone without these devices is a Loser and a Nobody – just as it was when Cellphones first came out, before Cellphones? There was the CD Player. Before that? The Walkman Portable Radio/Tape Player.

    No industry should be held up to the standards of a Fad and Status Symbol.

  5. […] – bookmarked by 5 members originally found by scootermac315 on 2008-09-27 Identity, Trust and Policy https://zhaewry.wordpress.com/2008/07/09/identity-trust-and-policy/ – bookmarked by 4 members […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: