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

["Hurliman, John" <[e-mail]>]

Comments inline.

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Cenji Neutra
>Sent: Thursday, June 04, 2009 12:20 PM
>To: [e-mail]
>Subject: Re: [ogpx] An Inquiry into the Nature and Causes of Web
>Capabilities
>
>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.
>

Where do you see this requirement? This is definitely not how I am using them currently. In fact, capabilities make it easy to implement load balancing by handing out capabilities pointing to different domains/servers that are tied to the same backend infrastructure.

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

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.

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

The capabilities server in the OpenMetaverse.Http library uses O(1) lookups to pull up metadata about the request including permissions. Using the capability as a data storage format instead of a simple lookup token seems out of scope of the intention. 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.

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

I think the sentence about capabilities representing everything in one string is being read too literally. A capability acts as a proxy to a service endpoint and can optionally store authentication, authorization, and/or other metadata where the capability acts as a lookup key for this data. A typical use case would be a service endpoint that you authorize access to and grant a capability. What you actually do at that service point would be handled at another layer of the protocol. Maybe you would be sending a message that says "transfer money from account X to account Y", but that's another discussion.

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

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.

John