Also, it seems like in a cluster, you'd need the ability for any server to generate many auth cookies that will work on any other server when the client makes its next request.
That's one possible implementation. 128 crypto-random bits should be enough.
Another possible implementation is to say that the interface can only be accessed through the same connection over which the pointer was sent. In this case you don't need any crypto (other than SSL on the connection, perhaps). The interface pointer can just be an integer, sequentially counting from zero.
The latter approach of course means that in case of network failure you lose all your pointers. Depending on the use case this may be fine -- perhaps you just need to fetch them again on re-connect. If it's not fine, then yes, you need some sort of unguessable capability string.
> Also, it seems like in a cluster, you'd need the ability for any server to generate many auth cookies that will work on any other server when the client makes its next request.
For long-lived capabilities, yes, you'll probably want them to be backed by data in a database so that they can easily relocate to a different machine.
But for the all-pointers-break-when-the-connection-closes approach, there's no issue.
I expect the first iteration of the RPC system will only support this latter approach. The former approach clearly requires help from the application, so will take longer.