Loading ...
Sorry, an error occurred while loading the content.

Re: [caplet] Interconnect

Expand Messages
  • Tyler Close
    ... Typically, we don t do access control at the vat level, but at the reference level. Typically, the vat identifier is just a self-authenticating identifier,
    Message 1 of 3 , Jun 5, 2007
    • 0 Attachment
      On 6/5/07, Douglas Crockford <douglas@...> wrote:
      > I think that takes the form of some kind of vat manager, which assigns
      > unique, unguessable IDs to each vat, and routes messages which are
      > addressed with those IDs.

      Typically, we don't do access control at the vat level, but at the
      reference level. Typically, the vat identifier is just a
      self-authenticating identifier, like a fingerprint of the Vat's public
      key. Since the communication channels in this case are local, we don't
      need crypto to secure them, so really, any old string is perfectly
      fine as a vat identifier. This is fortunate, since the Gears API
      doesn't seem to give us any control over the worker ID.

      Looking at the Gears API, it also appears that the messaging system
      does not allow forging of the sender's worker ID. If this is so, we
      can implement an actual object-capability protocol, using a per-sender
      clist, and so we won't need any crypto at all. Each worker keeps a
      clist for each of its clients and an inter-Vat reference is just the
      pair ( worker ID, clist index). It seems likely that we could borrow a
      lot of the design of E's CapTP protocol for managing these clists.

      Tyler

      --
      The web-calculus is the union of REST and capability-based security:
      http://www.waterken.com/dev/Web/

      Name your trusted sites to distinguish them from phishing sites.
      https://addons.mozilla.org/firefox/957/
    • Douglas Crockford
      ... Naturally. One of the peculiar aspects of widget architecture is that you have multiple vats that represent a common interest, but which initially have no
      Message 2 of 3 , Jun 7, 2007
      • 0 Attachment
        > Typically, we don't do access control at the vat level, but at the
        > reference level. Typically, the vat identifier is just a
        > self-authenticating identifier, like a fingerprint of the Vat's public
        > key. Since the communication channels in this case are local, we don't
        > need crypto to secure them, so really, any old string is perfectly
        > fine as a vat identifier. This is fortunate, since the Gears API
        > doesn't seem to give us any control over the worker ID.

        Naturally. One of the peculiar aspects of widget architecture is that
        you have multiple vats that represent a common interest, but which
        initially have no knowledge of each other, which want to communicate,
        but cannot rely on the page to do the introduction.

        They could manage the introduction through their common server, but
        that will add a couple of roundtrips to the startup time, something
        we'd like to avoid.

        An alternative would be if the vat manager could facilitate such
        introductions. For example, it could accept requests of the form:
        Please introduce me to all of the services that were vended from the
        same domain as myself.
      Your message has been successfully submitted and would be delivered to recipients shortly.