<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: SLGA: Capabilities explained (technical)</title>
	<atom:link href="http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/feed/" rel="self" type="application/rss+xml" />
	<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/</link>
	<description>Web2.0, Plone, Second Life, New Marketing, Data Portability</description>
	<pubDate>Wed, 10 Mar 2010 21:14:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: The Thieves Motherload - Page 42 - SLUniverse Forums</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-6265</link>
		<dc:creator>The Thieves Motherload - Page 42 - SLUniverse Forums</dc:creator>
		<pubDate>Fri, 30 Oct 2009 17:57:34 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-6265</guid>
		<description>[...] to the &#34;Approach&#34; subsection)  Maxping - Inside the Opensim Asset Server  SL specific:  mrtopf.de » Blog Archive » SLGA: Capabilities explained (technical)  Image Pipeline - Second Life Wiki  Here's an example of the flowchart of the image pipeline...    [...]</description>
		<content:encoded><![CDATA[<p>[...] to the &quot;Approach&quot; subsection)  Maxping - Inside the Opensim Asset Server  SL specific:  mrtopf.de » Blog Archive » SLGA: Capabilities explained (technical)  Image Pipeline - Second Life Wiki  Here&#8217;s an example of the flowchart of the image pipeline&#8230;    [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christian Scholz</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-5530</link>
		<dc:creator>Christian Scholz</dc:creator>
		<pubDate>Sun, 29 Mar 2009 20:07:11 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-5530</guid>
		<description>Right, the asset server does not do a check anymore.. This is intentional by Linden Lab AFAIK because they want to leave this whole security thing to one central component.
The point here is though that the asset server is inside an internal network and cannot be reached except via this capability proxy. So as long as you cannot access the internal network you should be safe. The UUID btw is just assigned randomly and remembered inside a database in the proxy and expiring after some time. Guessing it should be quite hard.

And yes, it's an additional request to the service to first get the UUID-mapped URL. You can retrieve multiple capabilities at once though.

And I must say that I am also not a big fan of this. I personally would still check the request on each sub-service and having some sort of header based auth would also be easier to implement with most web frameworks. There are also mechanisms like OAuth now which are already used by many parties, have library implementations and a growing community. They might not be perfect for that job yet but changes can always be made by participating in these communities.

Your suggestion might actually work as long as you only request one capability. But then again, why not simply put the seed cap into a header field and use this as a session and you might still be able to implement this capability mechanism internally.

But we have to see what actually will come out of the MMOX discussion at the IETF as also Linden Lab employees are looking more at OAuth these days. A final result will take some time though.</description>
		<content:encoded><![CDATA[<p>Right, the asset server does not do a check anymore.. This is intentional by Linden Lab AFAIK because they want to leave this whole security thing to one central component.<br />
The point here is though that the asset server is inside an internal network and cannot be reached except via this capability proxy. So as long as you cannot access the internal network you should be safe. The UUID btw is just assigned randomly and remembered inside a database in the proxy and expiring after some time. Guessing it should be quite hard.</p>
<p>And yes, it&#8217;s an additional request to the service to first get the UUID-mapped URL. You can retrieve multiple capabilities at once though.</p>
<p>And I must say that I am also not a big fan of this. I personally would still check the request on each sub-service and having some sort of header based auth would also be easier to implement with most web frameworks. There are also mechanisms like OAuth now which are already used by many parties, have library implementations and a growing community. They might not be perfect for that job yet but changes can always be made by participating in these communities.</p>
<p>Your suggestion might actually work as long as you only request one capability. But then again, why not simply put the seed cap into a header field and use this as a session and you might still be able to implement this capability mechanism internally.</p>
<p>But we have to see what actually will come out of the MMOX discussion at the IETF as also Linden Lab employees are looking more at OAuth these days. A final result will take some time though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Turas</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-5510</link>
		<dc:creator>Ben Turas</dc:creator>
		<pubDate>Thu, 19 Mar 2009 14:34:40 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-5510</guid>
		<description>Thinking some more about this capabilities architecture, getting a  proxy once and use it many times is risky. The asset server doesn't validate the request anymore. So the moment someone manages to break the algorithm of going from a UUID to the URL for the asset server, anything can be asked for. This means that only stuff that is free to use for everyone can be acquired with this "get once use many" proxy.

All other stuff needs to be done by first going to the caps server to get a proxy and then fire the request to the second server. The first call checks access and more, the second call delivers the data. 

Why not have the caps server forward the request to the asset server and returns the answer in one turn around ! This will save one network request and have the same result.

greetings, Ben</description>
		<content:encoded><![CDATA[<p>Thinking some more about this capabilities architecture, getting a  proxy once and use it many times is risky. The asset server doesn&#8217;t validate the request anymore. So the moment someone manages to break the algorithm of going from a UUID to the URL for the asset server, anything can be asked for. This means that only stuff that is free to use for everyone can be acquired with this &#8220;get once use many&#8221; proxy.</p>
<p>All other stuff needs to be done by first going to the caps server to get a proxy and then fire the request to the second server. The first call checks access and more, the second call delivers the data. </p>
<p>Why not have the caps server forward the request to the asset server and returns the answer in one turn around ! This will save one network request and have the same result.</p>
<p>greetings, Ben</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RANT: Sharks in the water. - Page 7 - SLUniverse Forums</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-3684</link>
		<dc:creator>RANT: Sharks in the water. - Page 7 - SLUniverse Forums</dc:creator>
		<pubDate>Fri, 18 Jul 2008 05:53:03 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-3684</guid>
		<description>[...] have no DRM. And surprise, neither do scripts.   again, capabilities for people who missed it.  SLGA: Capabilities explained (technical) &#8212; mrtopf.de   [...]</description>
		<content:encoded><![CDATA[<p>[...] have no DRM. And surprise, neither do scripts.   again, capabilities for people who missed it.  SLGA: Capabilities explained (technical) &#8212; mrtopf.de   [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RANT: Sharks in the water. - Page 6 - SLUniverse Forums</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-3683</link>
		<dc:creator>RANT: Sharks in the water. - Page 6 - SLUniverse Forums</dc:creator>
		<pubDate>Thu, 17 Jul 2008 17:33:53 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-3683</guid>
		<description>[...] by capabilities, and I don't see why not.  anyway, here is the explanation of capabilities for SL  SLGA: Capabilities explained (technical) &#8212; mrtopf.de  __________________ &#34;To begin with,&#34; said the Cat, &#34;a dog's not mad. You grant [...]</description>
		<content:encoded><![CDATA[<p>[...] by capabilities, and I don&#8217;t see why not.  anyway, here is the explanation of capabilities for SL  SLGA: Capabilities explained (technical) &#8212; mrtopf.de  __________________ &quot;To begin with,&quot; said the Cat, &quot;a dog&#8217;s not mad. You grant [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Setting up a framework for a Python implementation of the Open Grid Protocol (technical) &#8212; mrtopf.de</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-2471</link>
		<dc:creator>Setting up a framework for a Python implementation of the Open Grid Protocol (technical) &#8212; mrtopf.de</dc:creator>
		<pubDate>Sat, 17 May 2008 22:44:06 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-2471</guid>
		<description>[...] I tried to get the capsserver from Linden Lab to run which is included in mulib (more about Capabilities here). [...]</description>
		<content:encoded><![CDATA[<p>[...] I tried to get the capsserver from Linden Lab to run which is included in mulib (more about Capabilities here). [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Open grids and distributed asset systems &#171; justincc&#8217;s opensim blog</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-2327</link>
		<dc:creator>Open grids and distributed asset systems &#171; justincc&#8217;s opensim blog</dc:creator>
		<pubDate>Thu, 24 Apr 2008 21:06:59 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-2327</guid>
		<description>[...] to the region). However, with the new CAPS method of retrieving inventory (see here for an explanation of CAPS), it might be possible to provide a capability which routes inventory requests directly to a grid [...]</description>
		<content:encoded><![CDATA[<p>[...] to the region). However, with the new CAPS method of retrieving inventory (see here for an explanation of CAPS), it might be possible to provide a capability which routes inventory requests directly to a grid [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: UgoTrade &#187; Blog Archive &#187; Open Source Virtual Worlds Pushing the Envelope</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-2128</link>
		<dc:creator>UgoTrade &#187; Blog Archive &#187; Open Source Virtual Worlds Pushing the Envelope</dc:creator>
		<pubDate>Wed, 26 Mar 2008 04:22:28 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-2128</guid>
		<description>[...] &#8220;Capabilities&#8221; server is designed to take in the Linden Lab vision of an open grid read Christian Scholz&#8217;s (Tao Takashi&#8217;s blog). I will write more in another post as I have already heard a variety of opinions on the [...]</description>
		<content:encoded><![CDATA[<p>[...] &#8220;Capabilities&#8221; server is designed to take in the Linden Lab vision of an open grid read Christian Scholz&#8217;s (Tao Takashi&#8217;s blog). I will write more in another post as I have already heard a variety of opinions on the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SLGA: Linden Lab releases Capabilities Server as Open Source (technical) &#8212; mrtopf.de</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-2052</link>
		<dc:creator>SLGA: Linden Lab releases Capabilities Server as Open Source (technical) &#8212; mrtopf.de</dc:creator>
		<pubDate>Wed, 19 Mar 2008 13:54:38 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-2052</guid>
		<description>[...] The capabilities server is one of the core modules needed for the Second Life Grid to run and will play a big part in the interconnectivity protocol which the AWG is working on. If you want to know more about Capabilities please have a look at my summary. [...]</description>
		<content:encoded><![CDATA[<p>[...] The capabilities server is one of the core modules needed for the Second Life Grid to run and will play a big part in the interconnectivity protocol which the AWG is working on. If you want to know more about Capabilities please have a look at my summary. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Morgaine Dinova</title>
		<link>http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/comment-page-1/#comment-2024</link>
		<dc:creator>Morgaine Dinova</dc:creator>
		<pubDate>Sat, 15 Mar 2008 09:15:11 +0000</pubDate>
		<guid isPermaLink="false">http://mrtopf.de/blog/vlog/slga-capabilities-explained-technical/#comment-2024</guid>
		<description>This is an excellent article, Tao, very "tutorial".

In AWG we learned about caps by gradual osmosis and so the understanding gradually seeped in, but for newcomers to our sessions the concept might appear quite obscure.  I think this tutorial will help remedy that.

Well done.</description>
		<content:encoded><![CDATA[<p>This is an excellent article, Tao, very &#8220;tutorial&#8221;.</p>
<p>In AWG we learned about caps by gradual osmosis and so the understanding gradually seeped in, but for newcomers to our sessions the concept might appear quite obscure.  I think this tutorial will help remedy that.</p>
<p>Well done.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
