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

[Infinity Linden <[e-mail]>]

On Thu, Jun 4, 2009 at 12:19 PM, Cenji Neutra <[e-mail]> wrote:
> 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.)

you can do round robin if you like, but i think we're anticipating
capabilities living on machines other than the one you log into. The
verbiage "Other than for the security considerations below, the client
must not rely on any assumed structure of the capability URL." in
section 2.3 of the OGP : Base implies this. 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.

>
> 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).

yes. clients SHOULD respond to 301's and 302's.

>
> 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.
>

capabilities, as portable "authentication" tokens are supposed to
eliminate or reduce the requirement to resolve a requester's identity
an then map it to a set of permissions. the concept of capabilities
does not REQUIRE the underlying resource to model permissions in this
way, but it does allow it. and obviously, if you had a network service
that defined subject-verb-object tuples, caching that mapping local to
the underlying resource (should) give you better performance and
better scaling behavior than caching the identity local to the
underlying resource and then querying the network SVO store.

> 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.
>

mmm... we actually have experience doing exactly this. yes, it is less
obvious how it's done than say an XML-RPC style interface, but it's
certainly doable. lemme dig through our list of services and provide
some more examples of this.

> 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?
>

Mark Miller is about as close to an expert on capabilities as you can
find out there these days. And while i'm not sure modeling protocol
interactions as a collection of caps mediated contracts is the
clearest way to represent things, it's clear he's though through the
use cases. You can find documentation he's written by googling +"mark
miller" +capabilities. Also.. the reference i gave,
http://video.google.com/videoplay?docid=-8527120258517176598 , is a
google talk he gave. The other google tech talk reference i gave with
Tyler Close is good too.

> -David
> (Cenji Neutra inSL)
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>