Re: [ogpx] An Inquiry into the Nature and Causes of Web Capabilities

[Cenji Neutra <[e-mail]>]

On Thu, Jun 4, 2009 at 3:41 PM, Hurliman, John <[e-mail]> wrote:
>>1. All the capabilities have the same domain URL prefix.
> Where do you see this requirement?
> [...]
> > I don't know if this is specifically mentioned in the spec or not (if it isn't, it should) but I've been implementing capabilities to follow normal HTTP patterns as closely as possible. Meaning 302 redirects are followed.

I must have assumed it when I read "A web capabilities in OGP are in
the form of a 'well known' portion of a URL (something like
'http://service.example.org/s/';)".
So, the combination of flexibility in use of capability domain within
a grid coupled with redirects can provide a hierarchical 'load
balancing' for resource service end-points then.  That will help
scalability.

> [..] Using the capability as a data storage format instead of a simple lookup token seems out of scope of the intention.

Perhaps - I'm not certain of the scope/intention, but in literature
I'm familiar with (from Operating Systems area), the term 'capability'
is used to refer to the information about the
permissions/authorizations, not the token used to reference it - so
the the OGP use of the term was a little confusing to me at first.
Indeed, not all capability based system use the 'segregated'
capability protection scheme - so there may be no such token involved
in general.  When the 'password' or 'tagging' capability protection
models are used it is that actual permission/authorization data that
is passed around by clients in order to present for access to the
resource (hence, for those systems, a capability is the "storage" and
there are no other tokens).

If I understand correctly, the format of the path component of web
capabilities is opaque - which would leave it open for implementers to
use it as such a 'store' in order to eliminate the need for token
lookup.

> Revocation is also O(1) and immediate, meaning the design isn't susceptible to race conditions when a capability is revoked. It would be difficult to securely implement things like one time capabilities otherwise.

I assume that is only the case because the capability information is
stored entirely in one location - the host to which the capability
domain resolves, right? (i.e. the token is already known to the server
fielding the request before it is made, correct?)

> I don't proclaim myself as a security expert and I haven't implemented them in any other systems, but I do lead development on the OpenMetaverse library and the Cable Beach architecture and have had success with them in architecture design and when it comes time to write the actual code.

I've also implemented a capability based authorization system, but
didn't utilize tokens - instead embedding the authorization
information in the string itself and used a cryptographic scheme to
encode and sign it.  Our system doesn't provide the ability to revoke
permissions at all (though all capabilities expire - the expiry
timestamp being embedded into it).  I'm certainly no expert either
though.


On Thu, Jun 4, 2009 at 4:38 PM, Infinity Linden <[e-mail]> wrote:
> But... if you didn't pick
> it up from a read through the document, other people aren't either, so
> in the next rev we'll make it explicit.

Honestly, I didn't read it right before posting (though I've read
previous versions before).  Explicit is good though :)

My concern is with scalability.  Consider the DNS system.  It isn't
inherently scalable, but has managed thus far by having a
hierarchically decomposed 'load balancing' structure and, importantly,
allowing DNS servers to cache the results of 'recursive' delegation
chains (perhaps when there are a trillion people on earth it'll need
to be re-implemented using a distributed hash-table or something).
>From what you've both said, it sounds like the current OGP proposal
will allow a similar scheme - where the 'seed' cap server plays the
role of the 'root' and can delegate to a hierarchy of servers using
repeated HTTP redirects.  Now, since the URLs are to be treated as
opaque, they have no structure for caching intermediate redirect
results usefully like domains do.  However, a particular
implementation would be free to return URLs that actually use the
domain part to achieve it using a hierarchy of DNS servers (e.g. with
caps like http://a.c.b5. ... .f.e.inventory.myagentdom.org or
whatever).

Thanks for your replies - I understand it more clearly now.  It
appears the existing scheme can be scaled somewhat.

-David
(aka Cenji Neutra inSL)