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

[Cenji Neutra <[e-mail]>]

In my mind the number one requirement for any resource
authentication/authorization system to be used by a virtual world is
scalability.  By "scalability" I mean inherently theoretically
scalable to arbitrary sizes, not just 'quite large if you throw a lot
of hardware at it and do not think too far into the future' scalable.
:)

A few observations about the Web capabilities as I understand they're
designed from Infinity's description:

1. All the capabilities have the same domain URL prefix.  So, the only
way request volume can be scaled (currently) is using round-robin DNS
entries.  I doesn't seem like that would get you very far.   How do
you envision implementations getting around that limitation?
(For example, if only requests for the seed capability were directed
to that domain, issuing secondary capabilities with different domains
would allow get you a bit farther by utilizing DNS itself for resource
location).  Does that imply that you envision the future internet
being a large number of 'grids' each with its own associated domain to
which seed cap requests are directed? (so that if any one grid starts
to hit limits to scalability, it can just be split into multiple? -
don't want to discuss how that interplays with identity here..).
Just a thought, perhaps the key part of the cap URL should be a
subdomain so that DNS can be used to distribute/locate the resources
(e.g.   http://A.5.F.2.6.7.3 ... 4.E.B.caps.mygrid.com could be a cap
- except a digit isn't a valid domain part, so it would need to be
prefixed with a character.)

2. Are client requests for capabilities required to respond to HTTP
redirects?  If so, that might provide an alternative way to implement
a 'DNS-like' recursive delegation tree - if clients were able to cache
those redirections for a finite period (e.g. analogous to the DNS
record TTL scheme).

3. The capability is not self-contained / has no intrinsic meaning:
Is it 'cheap' / O(1) to check the validity of a capability?  Since the
capability itself identifies the service end-point for the resource,
depending on the design of the grid, it may be that the service has
all the information it needs to check the capability and what
permissions it grants to whom for what.  Can anyone think of a useful
implementation for which that information may not be co-located with
the resource and hence might require additional (expensive) look-up
processes?  That could be a serious impediment to scalability.
If so, perhaps a better implementation of capabilities might include
all the information about what it grants to whom for which resources
encoded as part of the capability itself.  The information can be
cryptographically signed to provide the same protection against
generation of capabilities, but has the added benefit that no lookup
is required at the service end-point.  The capability could also gain
some measure of 'readability' too - though if that isn't desirable
that URL part can also be encrypted.  Such capabilities would likely
be much longer URLs.
The obvious drawback to a scheme like this is that revocation becomes
expensive.  It could be argued that the amount of information that
needs to be distributed and maintained to implement distributed
revocation lists is much less than the amount needed to be maintained
to implement the reverse (effectively distributed authorization) as
revoked capabilities are the exception rather than the norm,
presumably.

4. The capability intrinsically identifies the resource, the service
end-point and authentication in one string.  That might considerably
complicate natural use-cases where more than one resource is involved
in a single operation.  If I have two capabilities identifying two
resources, which one do I use as the service end-point URL?  How is an
operation on two (or more) resources represented? For example, suppose
my friends Joe and Emma wish to grant me the capability to trigger a
payment from Joe's account to Emma's account for L$20.  It can
obviously be implemented, but less 'naturally' than a design where the
resources, service end-point and authentication are separated.

5. Capabilities are a very old idea - any experts out there happen to
be familiar with existing systems that use them and their trade-offs
and lessons?

-David
(Cenji Neutra inSL)