Sorry for the unclear PDF confused you.<br>Here, I want to explan my idea in detail.<br><br>First, I did not say any a word about to make user server to support<br>OpenID login only, I am sure I think OpenID should remain an option, just<br>
like today a lot of websites already have been doing.<br>And, Thanks very much to Ryan McDougall's opinion about the asset security<br>problem, <br>> Anyone who can read your data can copy or modify it<br>I am agree with you.<br>
AssetDataPortability's main purpose is to enable user bringing their<br>"appearance" across different VWs. It dose not mean they can freely<br>add/modify/take things(prims, assets) on your region without your permission.<br>
<br>I wrote a more detailed PDF file,<br><a href="http://lulurun.sakura.ne.jp/Data%20Portability%20in%20VirtualWorld.pdf">http://lulurun.sakura.ne.jp/Data%20Portability%20in%20VirtualWorld.pdf</a><br>including some comments, wish this can give you a better image.<br>
<br>The purpose of my idea is to do 3 things:<br>1. Enable Avatar portability<br>2. Enable Asset Data portability<br>3. Facilitate a future "metaverse" of many small or large interoperable<br>Virtual World systems across the Internet.<br>
<br>Avatar portability means that one person can use one credential<br>(name/password key) across all interoperable VWs.<br><br>Asset data portability means that that Avatar retains the same assets<br>(clothing, hair, animations) across each VW he can log into.<br>
<br>And to do the above, means to fundamentally alter the current state of<br>affairs, where each VW is a walled garden.<br><br>1. The problem with Avatar portability is obvious: if you register with<br>VW X, you have to reregister with VW Y in order to enter Y. <br>
<br>OpenID provides a solution to this problem by delegating authentication<br>to a trusted 3rd party, ie the OpenID server.<br><br>To implement OpenID to solve 1., we offer the user an alternate method<br>of authentication by providing a dialog box where the user can input his<br>
preregistered OpenID (in addition to the old name/pass method).<br><br>Using HTTP, we redirect viewer's HTML renderer to the OpenID escrow,<br>they do old-fashioned challenge-response, and when the escrow is<br>satisfied, it returns 200, OK to the User server.<br>
<br>2. The problem with Avatar Asset portability is also obvious: since we<br>have no centralized means of specifying how to get assets, even well<br>intended region servers cannot get access to your Avatar's assets.<br>
<br>To enable Avatar Asset portability, we suggest that assets be stored in<br>one URL accessible server, that is attached to your Avatar's OpenID as a<br>set of attributes, which various VWs can access when you authenticate<br>
with them.<br><br>The immediate problem is that currently, there is bad data portability<br>among VWs, so for the time being, we will either assume:<br> a. Assets are stored in a portable format which all VWs can read<br>
 b. All VWs in question are OpenSimulator<br><br>This limitation naturally leads us to a discussion of:<br><br>3. How can we make this scheme work outside of OpenSim? What will a<br>"metaverse" of VWs look like under such a scheme?<br>
<br>There will be a new VW independent "User server" implemented as a thin<br>web service, and pointing to the grid it serves.<br><br> 1. The client viewer directs users to their User server, which is<br>rendered as an HTML page. <br>
<br> 2. The user server authenticates using OpenID using the preferred<br>OpenID server.<br><br> 3. The OpenID server returns the 200,OK, as well as a list of<br>attributed, specifically the URL for the Avatar's Asset server.<br>
<br> 4. The User server then returns a CircuitCode, or as its know in SL<br>parlance, a capability, to the viewer and region/grid server.<br><br>In order to manage this, it obviously takes a lot of modifications to<br>the current infrastructure, but the most serious issues are the<br>
following:<br><br>* OpenID 2.0 only supports fixed attributes, and sreg.AssetServerUrl is<br>not one of them. We can:<br> - run our own VW OpenID server that hijacks an existing attribute<br> - modify an existing OpenID server to add our pet attribute<br>
 - modify an existing OpenID server to add custom attributes<br><br>* How do we encourage other VWs to join our system?<br>* How do we handle non-OS VW data formats? Common data formats:<br> - <a href="http://dataportability.org">dataportability.org</a><br>
 - <a href="http://collada.org">collada.org</a><br><br>I think a lot of people are having the same sort of ideas as I am, and<br>we are thinking in a common direction, but what we need to do now is<br>move from head-nodding into some sort of detail, and then hopefully into<br>
prototypes for testing.<br><br>I wrote a more detailed PDF file,<br><a href="http://lulurun.sakura.ne.jp/Data%20Portability%20in%20VirtualWorld.pdf">http://lulurun.sakura.ne.jp/Data%20Portability%20in%20VirtualWorld.pdf</a><br>
including some comments, wish this can give you a better image.<br><br>Can we have some discussion on this matter, so we can move forward into<br>an implementation?<br><br>Look forward to hearing your concerns and opinions.<br>
<br>Cheers,<br>lulurun