OpenSimulator - User contributions [en]

Security vulnerability brought by non-check inventory service

2008-08-12T06:47:46Z

Lulurun: /* RegionServer side */

== Problem ==

With the following conditions, one can simply take over the full control(CRUD) of other user's inventory.
# InventoryServer is exposed to the public.
# user's UUID is given

Simply describe in the following figure:
*InventoryServer is a normal http server, the normal way to use it is:
**user get the authentication from UserServer
**user control its inventory through RegionServer
*But since the InventoryServer accepts any request without check if the user is authenticated, or, even it does not check if the request is from a RegionServer.
*So, if you know other users' UUID, you can send CRUD http requests directly to the InventoryServer without login.

[[Image:secure_inventory_1.PNG]]

And [[Avatar_portability_version_2|AvatarPortability]] needs a public inventory server,
so we have to make a secure one.

== Solution ==

* every inventory operation packet contains a "session_id" field, but it is never used.
* so, a secure inventory service could be like this
[[Image:secure_inventory_2.PNG]]
* "session_id" is a important information, that is(should be) only transfered in a login session.
**"expect_user" transfer "session_id" from UserServer to RegionServer only when the authentication is OK, so "expect_user" is safe.
**method, such like "get_agent_by_uuid" is very dangerous.

== Configuration ==

=== RegionServer side ===
* in OpenSim.ini, [Network] section,
inventory_server_url = http://127.0.0.1:8004
'''secure_inventory_server''' = true / false
* if the inventory server specified by "inventory_server_url" is a "secure" inventory server,set "secure_inventory_server = true", then inventory request from the regionserver will be attached a session_id
* else, set secure_inventory_server = false, in this case, session_id is not attached with every inventory request.
** This option is only useful when you want your regionserver to connect to a '''old inventoryserver''' - an inventory server do not expect a session_id.

=== InventoryServer side ===
* in InventoryServer_Config.xml,
'''session_lookup''' = true / false
(* for the session_lookup please also refer the above picture.)
* if you want inventory server to validate the incoming session_id, set session_lookup = true
* else, set session_lookup = false
** this makes inventory server accept any request, just like before.

=== *NOTE* ===
* no matter '''session_lookup''' is true or false, '''new inventoryserver''' requires session_id in every inventory request. if you want your regionserver to connect to a '''new inventoryserver''', you should always set '''secure_inventory_server = true''' in OpenSim.ini.
* here '''new inventoryserver''' means inventoryserver after svn revision 5600.

Security vulnerability brought by non-check inventory service

Security vulnerability brought by non-check inventory service

2008-07-22T16:08:12Z

Lulurun: /* Problem */

Security vulnerability brought by non-check inventory service

2008-07-22T16:03:01Z

Lulurun: /* Problem */

Avatar portability version 2

2008-07-22T15:40:41Z

Lulurun: /* Implementation */

[[User:Lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# '''(If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)'''
#* '''This is discussed in this page'''
# [[security vulnerability brought by non-check inventory service|Security]]

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented the 2nd and the 3rd, and would like to explan my idea:

== Basic Idea ==

=== definition ===
*User U1 resgitered at GridService G1
** U1's inventory information is stored in InventoryServer I1
** U1's assets are stored in AssetServer As1
** U1's appearance information is served by AvatarService Av1

*RegionServer R2 serves a sim at GridService G2
** R2 fetches assets from Assetserver As2 by default.
** R2 gets inventory information from InventoryServer I2 by default.
[[Image:avatar_portability_v2_1.PNG]]

=== avatar portability ===

AvatarPortability (or called "grid interoperability") is
*U1 login to R2
**U1's appearance at G1 can be seen from any other client which is connecting to R2.
**U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.

This means, (in the fig. 2) R2 should have the ability to connect not only its default
UGAI server, but also external Inventory, Asset, Avatar service.

[[Image:avatar_portability_v2_2.PNG]]

'''Then "AvatarPortability" can be subdivided into 2 goals:'''
# '''How to''' let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
# '''How to''' enable R2 to interact with mutilple Inventory/Asset/Avatar services ?

==== Answer to the 1st How to - XRDS ====

more information can be found at:
*http://en.wikipedia.org/wiki/Yadis
*http://en.wikipedia.org/wiki/XRDS

A sample XRDS for U1 can be like:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://opensim.org/profileservice/1.0</Type>
<URI>http://osgrid.org:8002/GetUserProfile/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/authservice/1.0</Type>
<URI>http://osgrid.org:8002/session/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/assetservice/1.0</Type>
<URI>http://osgrid.org:8003</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/inventoryservice/1.0</Type>
<URI>http://osgrid.org:8004</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/avatarservice/1.0</Type>
<URI>http://osgrid.org:8005</URI>
</Service>
</XRD>
</xrds:XRDS>

*There are more than one way can be considered to pass U1's XRDS file to R2
**[[OpenID for data portability in virtual world]]

REASONS for proposing XRDS
# There are "UserAssetUrl" and "UserInventoryUrl" in "Users" table, they are cab be used to specify users' storage services, but it's '''lack of scalability''', to think we may have "friend service", "currency service", ... we can not simply add a column for each service.
# XRDS is widly used, many languages has libs for discovering/parsing it. To use XRDS can '''increase the compatibility　with existing(web) service'''
# '''XRDS is just a proposal''', still, we have many other choices.

==== Answer to the 2nd How to - ForeignAssetHashTable ====

Why it is a problem ? The asset download process is described below:
*RegionServer sends user/prims' Texture UUID to the client.
*Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
*RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.
[[Image:avatar_portability_v2_3-1.PNG]]
*Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
*Here '''ForeignAssetHashTable''' is used to solve this problem. (The detailed implementation is shown in following section.)
*#when U1 login to R2, R2 register U1's owned asset UUIDs to "ForeignAssetHashTable".
*#Client sends a RequestImagePacket
*#R2 looks up into "ForeignAssetHashTable" to find the AssetServerUrl,(if not found, returns the default url)
*#R2 use the returned AssetServerUrl to get asset data.
[[Image:avatar_portability_v2_3.PNG]]

== Implementation ==

*All the implementation described here are already finished
**The testing environment will be made public after solving the "[[security vulnerability brought by non-check inventory service|security]]" issues.
*Just for appearance portability, asseturl and inventoryurl are enough, so temporarily just use the 2 existing properties.
*XRDS is not implemented

=== 1 Implementation - ForeginAssetHashTable.Add ===

[[Image:avatar_portability_4-1.PNG]]

=== 2 Implementation - ForeginAssetHashTable.Get ===

[[Image:avatar_portability_4-2.PNG]]

=== 3 Implementation - ForeginAssetHashTable.Remove ===

[[Image:avatar_portability_4-3.PNG]]

Security vulnerability brought by non-check inventory service

2008-07-22T15:31:31Z

Lulurun: /* Problem */

Security vulnerability brought by non-check inventory service

2008-07-22T15:27:24Z

Lulurun: /* implementation */

Security vulnerability brought by non-check inventory service

2008-07-22T15:27:13Z

Lulurun: /* solution */

Security vulnerability brought by non-check inventory service

2008-07-22T15:26:15Z

Lulurun:

OpenID for data portability in virtual world

2008-07-22T15:24:47Z

Lulurun:

[[User:Lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# '''How to enable foreign user login - Authentication'''
#* '''This is discussed in this page'''
# (If a foreign user can login)[[Avatar_portability_version_2|How to get a foreign user's belongings]](including appearance, inventory)
# [[Security vulnerability brought by non-check inventory service|Security]]

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented the 2nd and the 3rd, and would like to explan my idea:

== What is OpenID ==
For OpenID related knowledge:
http://en.wikipedia.org/wiki/OpenID

== Foreign user login ==

In virtual world,
To enable a foreign user authentication, What I can imagine is that there are 3 ways can be used.
*Import account from one GridService to another
*Use a central OpenID provider
*UserServer(OpenSim) acts as both RP and OP - this is the '''final goal'''
Detailed explanations are following:

=== Import (copy an account information from one to another) ===

This is the most simple way, just copy an account from its original Gridservice to another.

this can be done through webpages, and current OpenSim's Userserver already has a similar XMLRPC method (GetUserProfile) to do such thind, even though some security holes need to be filled.

*Advantages:
*# Quick, direct solution, easy to develop / use.

*Disadvantage:
*# The same user profile copied many times, can not manage them(in the case you change your profile in 1 gridservice, it does not affect other grids)
*# User have to remember too many password(even though you can always use the same)
*# If your name has been taken, you have to change to another - no name portability
*# other bad points ...

=== Use a central OpenID provider ===

Just like in the web world, there are already lots of website enabled both legacy login and openid login,
*Example: https://sourceforge.net/account/login.php

UserServer can also support OpenID login, in this case, authentication can be delegated to OpenID providers.

* Advantages:
*# User auth information is stored only in 1 place.
*# no worry about your favorite name has been take.
*# ... some other OpenID advantages

* '''Disadvantages''':
*# Current client need to be changed.(ver 1-18-6 is OK)
*# In data portability theory [Avatar portability], not only the auth information, but also others (UUID, inventoryurl, asseturl) are needed.
***OpenID has 2 extensions:
***# ax: http://openid.net/specs/openid-attribute-exchange-1_0.html
***# sreg: http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
***These 2 extensions supports OpenID user to store its additional information, but there are only a few OpenID providers enabled these functions. as far as I searched,
***# only myopenid.com: https://www.myopenid.com/ enabled both extensions.
***# yahoo.com does not support any of the 2 extensions.

=== UserServer acts as both RP(Relying Party) and OP(OpenID Provider) ===

UserServer can not only delegate an authentication to another UserServer, but also
accept an incoming authtication request from another UserServer.

That means,
*If a local user login to an UserServer, the UserServer use legacy way(password checking) to confirm the user's identity,
*If a foregin user login to an UserServer, UserServer delegates the authtication.
**user input its OpenID url(probably its Grid's UserServer url), then follow the OpenID authentication protocol -> [[Yadis for UGAI services discovery]]
*When an authtication request comes, UserServer checks the user's identity, if OK, UserServer returns the user profile(include name, uuid, inventoryurl, asseturl).

*Advantages
*#User auth information is stored only in 1 place.
*#no worry about your favorite name has been take.
*#... some other OpenID advantages
*#UserServer supports "UserAssetUrl", "UserInventoryUrl", "UUID" by standard
*#Help the OpenID expansion, minor

*Disadvantages
*#More changes needed
*#Current OpenSim's httpserver is not fully functional(environment variable supports, module supports, compared with apache)
***you can choose '''OpenUGAI''':http://openugai.sourceforge.net/, that is born for this purpose.

Security vulnerability brought by non-check inventory service

2008-07-22T15:23:11Z

Lulurun:

Avatar portability version 2

2008-07-22T15:22:39Z

Lulurun: /* Agenda */

[[User:Lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# '''(If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)'''
#* '''This is discussed in this page'''
# [[security vulnerability brought by non-check inventory service|Security]]

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented the 2nd and the 3rd, and would like to explan my idea:

== Basic Idea ==

=== definition ===
*User U1 resgitered at GridService G1
** U1's inventory information is stored in InventoryServer I1
** U1's assets are stored in AssetServer As1
** U1's appearance information is served by AvatarService Av1

*RegionServer R2 serves a sim at GridService G2
** R2 fetches assets from Assetserver As2 by default.
** R2 gets inventory information from InventoryServer I2 by default.
[[Image:avatar_portability_v2_1.PNG]]

=== avatar portability ===

AvatarPortability (or called "grid interoperability") is
*U1 login to R2
**U1's appearance at G1 can be seen from any other client which is connecting to R2.
**U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.

This means, (in the fig. 2) R2 should have the ability to connect not only its default
UGAI server, but also external Inventory, Asset, Avatar service.

[[Image:avatar_portability_v2_2.PNG]]

'''Then "AvatarPortability" can be subdivided into 2 goals:'''
# '''How to''' let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
# '''How to''' enable R2 to interact with mutilple Inventory/Asset/Avatar services ?

==== Answer to the 1st How to - XRDS ====

more information can be found at:
*http://en.wikipedia.org/wiki/Yadis
*http://en.wikipedia.org/wiki/XRDS

A sample XRDS for U1 can be like:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://opensim.org/profileservice/1.0</Type>
<URI>http://osgrid.org:8002/GetUserProfile/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/authservice/1.0</Type>
<URI>http://osgrid.org:8002/session/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/assetservice/1.0</Type>
<URI>http://osgrid.org:8003</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/inventoryservice/1.0</Type>
<URI>http://osgrid.org:8004</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/avatarservice/1.0</Type>
<URI>http://osgrid.org:8005</URI>
</Service>
</XRD>
</xrds:XRDS>

*There are more than one way can be considered to pass U1's XRDS file to R2
**[[OpenID for data portability in virtual world]]

REASONS for proposing XRDS
# There are "UserAssetUrl" and "UserInventoryUrl" in "Users" table, they are cab be used to specify users' storage services, but it's '''lack of scalability''', to think we may have "friend service", "currency service", ... we can not simply add a column for each service.
# XRDS is widly used, many languages has libs for discovering/parsing it. To use XRDS can '''increase the compatibility　with existing(web) service'''
# '''XRDS is just a proposal''', still, we have many other choices.

==== Answer to the 2nd How to - ForeignAssetHashTable ====

Why it is a problem ? The asset download process is described below:
*RegionServer sends user/prims' Texture UUID to the client.
*Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
*RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.
[[Image:avatar_portability_v2_3-1.PNG]]
*Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
*Here '''ForeignAssetHashTable''' is used to solve this problem. (The detailed implementation is shown in following section.)
*#when U1 login to R2, R2 register U1's owned asset UUIDs to "ForeignAssetHashTable".
*#Client sends a RequestImagePacket
*#R2 looks up into "ForeignAssetHashTable" to find the AssetServerUrl,(if not found, returns the default url)
*#R2 use the returned AssetServerUrl to get asset data.
[[Image:avatar_portability_v2_3.PNG]]

== Implementation ==

*All the implementation described here are already finished
**The testing environment will be made public after solving the "[[security vulnerability brought by non-check inventory service|security]]" issues.
*Just for appearance portability, asseturl and inventoryurl are enough, so currently just use the 2 existing properties.
*XRDS is not implemented

=== 1 Implementation - ForeginAssetHashTable.Add ===

[[Image:avatar_portability_4-1.PNG]]

=== 2 Implementation - ForeginAssetHashTable.Get ===

[[Image:avatar_portability_4-2.PNG]]

=== 3 Implementation - ForeginAssetHashTable.Remove ===

[[Image:avatar_portability_4-3.PNG]]

Security vulnerability brought by non-check inventory service

2008-07-22T15:22:09Z

Lulurun: /* Agenda */

[[User:lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# (If a foreign user can login)[[Avatar_portability_version_2|How to get a foreign user's belongings]](including appearance, inventory)
# '''Security'''
#* '''This is discussed in this page'''

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented the 2nd and the 3rd, and would like to explan my idea:

Security vulnerability brought by non-check inventory service

2008-07-22T15:21:45Z

Lulurun: /* Agenda */

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# (If a foreign user can login)[[Avatar_portability_version_2|How to get a foreign user's belongings]](including appearance, inventory)
# '''Security'''
#* '''This is discussed in this page'''

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented the 2nd and the 3rd, and would like to explan my idea:

2008-07-22T14:58:31Z

Lulurun: /* Answer to the 2nd How - ForeignAssetHashTable */

[[User:Lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# (If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)
#* '''This is discussed in this page'''
# [[AvatarPortability - Security]]

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented 2nd, and would like to explan my idea:

== Basic Idea ==

=== definition ===
*User U1 resgitered at GridService G1
** U1's inventory information is stored in InventoryServer I1
** U1's assets are stored in AssetServer As1
** U1's appearance information is served by AvatarService Av1

*RegionServer R2 serves a sim at GridService G2
** R2 fetches assets from Assetserver As2 by default.
** R2 gets inventory information from InventoryServer I2 by default.
[[Image:avatar_portability_v2_1.PNG]]

=== avatar portability ===

AvatarPortability (or called "grid interoperability") is
*U1 login to R2
**U1's appearance at G1 can be seen from any other client which is connecting to R2.
**U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.

This means, (in the fig. 2) R2 should have the ability to connect not only its default
UGAI server, but also external Inventory, Asset, Avatar service.

[[Image:avatar_portability_v2_2.PNG]]

Then "AvatarPortability" can be subdivided into 2 goals
# How to let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
# How to enable R2 to interact with mutilple Inventory/Asset/Avatar services ?

==== Answer to the 1st How - XRDS ====

more information can be found at:
*http://en.wikipedia.org/wiki/Yadis
*http://en.wikipedia.org/wiki/XRDS

A sample XRDS for U1 can be like:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://opensim.org/profileservice/1.0</Type>
<URI>http://osgrid.org:8002/GetUserProfile/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/authservice/1.0</Type>
<URI>http://osgrid.org:8002/session/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/assetservice/1.0</Type>
<URI>http://osgrid.org:8003</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/inventoryservice/1.0</Type>
<URI>http://osgrid.org:8004</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/avatarservice/1.0</Type>
<URI>http://osgrid.org:8005</URI>
</Service>
</XRD>
</xrds:XRDS>

*There are more than one way can be considered to pass U1's XRDS file to R2
**[[OpenID for data portability in virtual world]]

REASONS for proposing XRDS
# There are "UserAssetUrl" and "UserInventoryUrl" in "Users" table, they are cab be used to specify users' storage services, but it's '''lack of scalability''', to think we may have "friend service", "currency service", ... we can not simply add a column for each service.
# XRDS is widly used, many languages has libs for discovering/parsing it. To use XRDS can '''increase the compatibility　with existing(web) service'''
# '''XRDS is just a proposal''', still, we have many other choices.

==== Answer to the 2nd How - ForeignAssetHashTable ====

Why it is a problem ? The asset download process is described below:
*RegionServer sends user/prims' Texture UUID to the client.
*Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
*RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.
[[Image:avatar_portability_v2_3-1.PNG]]
*Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
*Here '''ForeignAssetHashTable''' is used to solve this problem.
*#when U1 login to R2, R2 register U1's owned asset UUIDs to "ForeignAssetHashTable".
*#Client sends a RequestImagePacket
*#R2 looks up into "ForeignAssetHashTable" to find the AssetServerUrl,(if not found, returns the default url)
*#R2 use the returned AssetServerUrl to get asset data.
[[Image:avatar_portability_v2_3.PNG]]

=== implemetation ===

== Avatar Portability ==

In "users" table, "UserInventoryURL" and "UserAssetURL" have been there for a long time, and they are not used yet. My idea starts from the 2 properties;

=== 1 UserInventoryUrl UserAssetUrl ===
[[Image:avatar_portability_1.PNG]]
*U1 is an user of GridService G1, so probably, U1's "UserInventoryURL" and "UserAssetURL" are pointing to G1's default Inventory/Asset server.
*R2 is a regionserver in GridService G2, so R2 fetches assets from G2's Asset server by default.
----

=== 2 Fetch data from multiple Inventory/Asset Data ===
[[Image:avatar_portability_2.PNG]]
*U1 login to R2, If U1 want to also bring in its apearance, R2 should have the ability that can '''get U1's appearance from U1's "UserInventoryUrl" and get U1's assets(textures) from "UserAssetUrl"'''.
*So, in this case, because an asset request("RequestImagePacket") only sends asset UUID to R2, R2 has to '''determine which asset server provides the reuqested UUID'''.

----

=== 3 ForeginAssetHashTable ===

[[Image:avatar_portability_3.PNG]]

>R1 has to determine which asset server provides the reuqested UUID
*At the right-bottom of this picture, "ForeginAssetHashTable" is used to solve this.
*When an user login,
*#region gets its "inventoryurl", "asseturl" from its "profile"
*#region gets its appearance(UUIDs) from its "inventoryurl", and add the UUIDs into "ForeginAssetHashTable"
*#Then when client send a "RequestImage(UUID)", RegionServer can look up into "ForeginAssetHashTable" to get the proper "AssetUrl"

== Implementation ==

=== Authentication ===

[[not prepared yet]]

=== Avatar Portability ===

==== 1 Implementation - ForeginAssetHashTable.Add ====

[[Image:avatar_portability_4-1.PNG]]

==== 2 Implementation - ForeginAssetHashTable.Get ====

[[Image:avatar_portability_4-2.PNG]]

==== 3 Implementation - ForeginAssetHashTable.Remove ====

[[Image:avatar_portability_4-3.PNG]]

Avatar portability version 2

2008-07-22T14:53:20Z

Lulurun: /* Answer to the 2nd How - ForeignAssetHashTable */

[[User:Lulurun]]

== Agenda ==

To enable user avatar travel from a grid service to another grid service,
There are 3 problems to be considered:
# How to enable foreign user login - [[OpenID for data portability in virtual world|Authentication]]
# (If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)
#* '''This is discussed in this page'''
# [[AvatarPortability - Security]]

To achieve the 1st, client side changes are needed. SO, so far, I have
only implemented 2nd, and would like to explan my idea:

== Basic Idea ==

=== definition ===
*User U1 resgitered at GridService G1
** U1's inventory information is stored in InventoryServer I1
** U1's assets are stored in AssetServer As1
** U1's appearance information is served by AvatarService Av1

*RegionServer R2 serves a sim at GridService G2
** R2 fetches assets from Assetserver As2 by default.
** R2 gets inventory information from InventoryServer I2 by default.
[[Image:avatar_portability_v2_1.PNG]]

=== avatar portability ===

AvatarPortability (or called "grid interoperability") is
*U1 login to R2
**U1's appearance at G1 can be seen from any other client which is connecting to R2.
**U1 can CRUD(Create/Read/Update/Delete) its inventory/appearance through R2.

This means, (in the fig. 2) R2 should have the ability to connect not only its default
UGAI server, but also external Inventory, Asset, Avatar service.

[[Image:avatar_portability_v2_2.PNG]]

Then "AvatarPortability" can be subdivided into 2 goals
# How to let R2 know where are U1's storage services(Inventory,Asset,Avatar,...) ?
# How to enable R2 to interact with mutilple Inventory/Asset/Avatar services ?

==== Answer to the 1st How - XRDS ====

more information can be found at:
*http://en.wikipedia.org/wiki/Yadis
*http://en.wikipedia.org/wiki/XRDS

A sample XRDS for U1 can be like:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://opensim.org/profileservice/1.0</Type>
<URI>http://osgrid.org:8002/GetUserProfile/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/authservice/1.0</Type>
<URI>http://osgrid.org:8002/session/12345678-1234-1234-1234-12345678abcd</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/assetservice/1.0</Type>
<URI>http://osgrid.org:8003</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/inventoryservice/1.0</Type>
<URI>http://osgrid.org:8004</URI>
</Service>
<Service priority="0">
<Type>http://opensim.org/avatarservice/1.0</Type>
<URI>http://osgrid.org:8005</URI>
</Service>
</XRD>
</xrds:XRDS>

*There are more than one way can be considered to pass U1's XRDS file to R2
**[[OpenID for data portability in virtual world]]

REASONS for proposing XRDS
# There are "UserAssetUrl" and "UserInventoryUrl" in "Users" table, they are cab be used to specify users' storage services, but it's '''lack of scalability''', to think we may have "friend service", "currency service", ... we can not simply add a column for each service.
# XRDS is widly used, many languages has libs for discovering/parsing it. To use XRDS can '''increase the compatibility　with existing(web) service'''
# '''XRDS is just a proposal''', still, we have many other choices.

==== Answer to the 2nd How - ForeignAssetHashTable ====

Why it is a problem ? The asset download process is described below:
*RegionServer sends user/prims' Texture UUID to the client.
*Client extract the UUIDs, and sends a "RequestImagePacket" to request the actual asset data.
*RegionServer receives the AssetUUID and passes it to AssetServer to get the asset.
[[Image:avatar_portability_v2_3-1.PNG]]
*Considering only 1 GridService, there is no problem, but if RegionServer knows more than 1 asset server, RegionServer has to determine which assetserver should be used.
[[Image:avatar_portability_v2_3.PNG]]

=== implemetation ===

== Avatar Portability ==

In "users" table, "UserInventoryURL" and "UserAssetURL" have been there for a long time, and they are not used yet. My idea starts from the 2 properties;

=== 1 UserInventoryUrl UserAssetUrl ===
[[Image:avatar_portability_1.PNG]]
*U1 is an user of GridService G1, so probably, U1's "UserInventoryURL" and "UserAssetURL" are pointing to G1's default Inventory/Asset server.
*R2 is a regionserver in GridService G2, so R2 fetches assets from G2's Asset server by default.
----

=== 2 Fetch data from multiple Inventory/Asset Data ===
[[Image:avatar_portability_2.PNG]]
*U1 login to R2, If U1 want to also bring in its apearance, R2 should have the ability that can '''get U1's appearance from U1's "UserInventoryUrl" and get U1's assets(textures) from "UserAssetUrl"'''.
*So, in this case, because an asset request("RequestImagePacket") only sends asset UUID to R2, R2 has to '''determine which asset server provides the reuqested UUID'''.

----

=== 3 ForeginAssetHashTable ===

[[Image:avatar_portability_3.PNG]]

>R1 has to determine which asset server provides the reuqested UUID
*At the right-bottom of this picture, "ForeginAssetHashTable" is used to solve this.
*When an user login,
*#region gets its "inventoryurl", "asseturl" from its "profile"
*#region gets its appearance(UUIDs) from its "inventoryurl", and add the UUIDs into "ForeginAssetHashTable"
*#Then when client send a "RequestImage(UUID)", RegionServer can look up into "ForeginAssetHashTable" to get the proper "AssetUrl"

== Implementation ==

=== Authentication ===

[[not prepared yet]]

=== Avatar Portability ===

==== 1 Implementation - ForeginAssetHashTable.Add ====

[[Image:avatar_portability_4-1.PNG]]

==== 2 Implementation - ForeginAssetHashTable.Get ====

[[Image:avatar_portability_4-2.PNG]]

==== 3 Implementation - ForeginAssetHashTable.Remove ====

[[Image:avatar_portability_4-3.PNG]]

File:Avatar portability v2 3-1.PNG

2008-07-22T14:52:29Z

Lulurun: