Thinking about trust, Part 1: Service Level and User Level

While social networks and virtual worlds might share a lot of things except maybe the 3D part there is at least one thing which more care needs to be taken of when thinking about virtual worlds: Trust.

Trust in terms of which services do I trust to let the objects I created go. As there is a huge economy in Second Life around selling virtual goods, it’s very important to content creators that their content is not copied.

This issue is of course even more important when thinking about a distributed grid where everybody can hook up their own servers. We call this the Open Grid Protocol.

A lot of discussions happened already, many more will happen. That was reason for us (that’s me and Dirk Krause/Bartholomaeus Kleiber) to sit together an afternoon thinking about use cases, requirements and so on. We wanted to concentrate in general on what is needed for objects to travel the grid.

The short summary: It’s all very confusing ;-)

In this 2-part series I want to first look at the easier issues of service and user level trust before I dig into the issues of transferring objects from service to service.

But let’s start at the beginning.

Some ways of looking at things

When it comes to trust first of all we need to define what „trust“ means. We also need to define between which parties we define trust.

You might look at some sort of service level trust which involves servers. One domain could wonder if it should trust another domain (e.g. if some Region Domain trusts some Agent Domain or vice versa or even AD-AD or RD-RD etc.).

Then there is something I would call user level trust which defines if user A trusts user B.

But in virtual worlds we also have objects so probably we also need something which defines if an object (representing the creator and thus a user) trusts some domain. So we could call that user-service level trust.

These are just words though but maybe it helps to have these.

Service Level Trust

So what is service level trust?

In this area questions like this come:

  • How do we make sure you cannot fake some agent domain and thus maybe impersonate some other person?
  • How can the agent domain be sure that it gives out some object to the region domain it thinks it is?

The answer to these questions is probably simple: Use SSL (or in more general terms certificates). Then at least you can be sure that the service at the other end has that certificate. Usually this party is also the owner of the certificate (in a legal sense).

Then there is the question: Once I identified the domain to be the one I think it is, how do I decide which services I offer to it? E.g. if I should take objects from it, or avatars?

The discussion we had at some AWGroupies meetings tended to end up in letting the implementation define this and IMHO this makes much sense.

There might be different criteria to do such a decision:

  • Do we have a contract with that domain?
  • Does some reputation service say that this is a good domain? (and do we trust that service?=
  • Do we maybe follow some chain of trust and can ask some other domain? (sort of a reputation service I guess)

Implementations can be manyfold, using whitelists, blacklists and so on.

As for the Open Grid Protocol this does also not just apply between Agent Domains and Region Domains but might also apply between external service. IMHO it makes sense anyway to move as many services as possible out of the predefined domains to make them more interoperable and more easily exchangeable.

User Level Trust

This actually is something which is maybe more discussed in the social networking. One group which’s aim is to discuss such things is the DataPortability group (Disclaimer: While I am voting member of the Steering Group there these here are just my personal thoughts)

Things you might want to do here might include:

  • not showing your complete profile to somebody
  • showing e.g. your email address to only certain other users
  • muting/banning users
  • not showing up in searches for some particular user

Such decisions can be made by checking if it’s some contact, some specially tagged contact, an individual whitelist/blacklist, some reputation service etc. It might even involve service level decisions like that a user might want to say that he never wants her email address to be transferred to AD Y or RD X.

Of course you as a user need to trust the service you have chosen to comply to your preferences. And you need to be aware of the fact that services which have access to data (or your contacts) might spread it further. But there is no way around this except maybe adding a license to it which defines what is allowed and not. And which hopefully has some power to pursue people legal wise if you wish so. We hope to get some talk about such approaches soon going again in the DataPortability forum.

I think here is much to benefit from both scenes, web and VWs, as both have their slightly different details and demographics but also much in common. I also assume that both worlds will grow together even more over time and you maybe only want to maintain one account for all your virtual worlds and your social networks, instant messaging services etc.

And this is it for this part, please check back soon (or subscribe to my blog) to read part 2 about the issues regarding object transfers.

Technorati Tags: , , ,

Teile diesen Beitrag

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email