[vos-d] VOS requirements

[Karsten Otto]

>> [...]
>> My idea is to create a user profile once, and let the user carry it
>> around with them. The profile is a small VOS graph. It describes the
>> user, capabilities, current inventory, game state, RPG stats,
>> whatever, each aspect in a distinct subgraph. A server can add,
>> modify, and remove a subgraph independent from other subgraphs; most
>> importantly, it can also *sign* it cryptographically, to certify its
>> authenticity.
>> When a user wishes to join a particular world, he uploads the profile
>> to the server. The server looks for subgraphs it understands/
>> requires, and verifies that it is certified by itself *or another
>> trusted server*. The big assumption here is that neighboring servers
>> know and trust each other. If the profile lacks prerequisite parts or
>> cannot be verified, access is denied.
>> When the users leaves the server, he downloads the (modified)
>> profile, to provide it to another server on its way. He can also keep
>> multiple copies of the profile on its private computer, sort of as a
>> "saved game" (thats what the idea was originally designed for).
>
> I like this idea.  It harkens back to the original VOS design which  
> was
> a lot more of a peer-to-peer system and users would "host" their own
> avatar.  It also reminds me of web cookies.
>
Web cookies were an inspiration, yes. However, they are opaque, so  
you cannot really pass them around. There are two problems, which the  
profile approach attempts to solve: Trust and (partial)  
understanding. A web server usually only accepts its own cookies, but  
not those issued by some completely different web server. Also, a web  
server usually does not understand another server's cookies. Even if  
it does, it cannot add its own (application specific) data to it  
without breaking the cookie for the original issuer.

> It seems to me there are a
> few issues, though.  For one, if you don't store a copy on the server,
> and the user disconnects unexpectedly, they may not have a up-to-date
> information (or maybe nothing at all).
>
In the original design, both client and server have a copy, with a  
synchronization protocol to keep things up-to-date, so loss is  
limited to the latest modifications. At any rate, the client could  
always revert to a previous "saved game". Translating this to VOS, I  
think the profile should be treated in the same manner as an avatar  
(maybe they're even the same?). I.e. you either upload it to the  
server, or keep it on your client site, granting write access to the  
server for changes.

> Also, this means the user can't log in from anywhere, but has to  
> always
> use the same account on the same computer because that's where their
> identity is saved, unless they also store their data on a server
> somewher where they can get it.
>
Well, I used to carry saved games on floppy disks to my friends  
place; nowadays I guess USB sticks serve this purpose. Apart from  
physical transport, you could also keep the profile on some server  
(which does guarantee privacy and regular backups), and when you need  
the profile, you first download it from there. You'll need to  
authenticate at this point, but once you got the profile, you're done.

> However, I do like the idea of some kind of single-sign-on identity,
> which could be client managed (i.e. something like a PGP key).  Then
> creating an account or logging into a site is just a matter of sending
> your public key and authenticating yourself, no "please choose a login
> name and password" bullshit required for every single site
>
The original design used RDF, with a unique URI (UUID-URN) as  
toplevel node, identifying the profile and by implication its user; I  
think for VOS we might need just the UUID as a property since you  
cannot arbitratily choose VOS URIs. Of course, you have to create an  
profile once, which could be a lengthy process akin to setting up a  
free mail account. Once you have a profile, you only need to upload  
it, which a client can manage transparently without user interaction.  
Btw. I used OpenPGP (GnuPG) for the trust mechanism, since it seemd a  
good idea to re-use an already deployed key infrastructure.

> Alternately, it would also be nice to integrate existing directory
> services like LDAP into VOS, so you could use existing user  
> accounts for
> a particular site.
>
Well... you could either "export" the existing accounts as profiles,  
or include a subgraph in a generic profile that says "on site xyz,  
use account name abc". You'll still have to enter the password, but  
that is probably ok for such a special site. If you need this  
functionality, the site probably isn't one you pass through casually  
anyway.

> Ironically, identity management is probably the *easy* (or at least,
> mostly-already solved) part of security in VOS.
>
This is not only about identity, but also about associating  
application/domain specific data with an identity, and possibly re- 
using the same data on different sites. Another use is as a personal  
"inventory" for carrying items from one site to another.

>   I'm very much
> struggling over how s5 security is going to look (access control  
> lists?
> capabilities?  role-based security?)
>
The profile fits nicely with capabilities (signed subgraph = asserts  
that you may perform a certain action), as well as with role-based  
security (signed subgraph = assertion that you are eligible for a  
given role). While pure ACLs are easy to understand and maintain, I'd  
recommend against it. They require knowledge of every single subject,  
highly unlikely in a true open system!

> as well as the very practical
> challenges of sandboxing scripts, both client side (sent by a
> potentially harmful server) and server side (sent by a potentially
> harmful client).
>
This is a different issue really, though trust (in client and server)  
is a factor. Applet security comes to mind, as well as bundle  
security in the OSGi container. Both use the Java security focussing  
on codebase. I am not sure if this is a viable model for VOS though.

> [...]
> Please do post a link to the paper, I would like to look at it,
> especially if you addressed the concerns I have raised here :-)
>
I don't have it online, but I attached a copy.

Regards,
Karsten Otto (kao)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pods.pdf
Type: application/pdf
Size: 144945 bytes
Desc: not available
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070202/540166dd/attachment-0001.pdf