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

From: Cenji Neutra <[email-masked]>
Date: Thu, 4 Jun 2009 15:19:46 -0400

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)

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 4 Jun 2009 13:41:25 -0600

Comments inline.

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

>those redirections for a finite period (e.g. analogous to the DNS

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.

>revoked capabilities are the exception rather than the norm,

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.

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

>be familiar with existing systems that use them and their trade-offs

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

---

From: Infinity Linden <[email-masked]>
Date: Thu, 4 Jun 2009 13:38:20 -0700

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

> those redirections for a finite period (e.g. analogous to the DNS

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

> revoked capabilities are the exception rather than the norm,

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.

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

> be familiar with existing systems that use them and their trade-offs

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Cenji Neutra <[email-masked]>
Date: Thu, 4 Jun 2009 20:36:44 -0400

On Thu, Jun 4, 2009 at 3:41 PM, Hurliman, John <[email-masked]> wrote:
> Where do you see this requirement?
> [...]

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 ha…

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 <[email-masked]> wrote:
> But... if you didn't pick

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)