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

Some new YouServ related papers

Expand Messages
  • Bert
    In our (futile?!) quest to make p2p the preferred method of information sharing (and by that I don t mean porn and MP3 s :-) within the corporate enterprise,
    Message 1 of 7 , Nov 19, 2002
    • 0 Attachment
      In our (futile?!) quest to make p2p the preferred method of information
      sharing (and by that I don't mean porn and MP3's :-) within the
      corporate enterprise, we've added some new features to the YouServ p2p
      webhosting system and described them in a pair of papers.

      (1) One describes experiences in developing and deploying a (hybrid) p2p
      search method that doesn't suck.

      (2) Another describes a system for sharing web applications as opposed
      to static content, allowing easy development & propagation of meta p2p
      apps atop the base infrastructure.

      They can be downloaded from here assuming our external website works:

      http://www.almaden.ibm.com/cs/people/bayardo/userv/

      Though typically quite reliable, since I actually need to use it today,
      the server seems to be suffering from sporadic outages. Here are some
      alternate download locations in case you have any problems:

      (1) http://www-db.stanford.edu/~bawa/Pub/usearch.pdf
      (2) http://bayardo-userv.userv.web.cmu.edu/secret/adina/plugin.html
    • Lucas Gonze
      ... A thing about yooserv that s a little funny is the use of dynamic DNS for identity, because it implies an admistrative bottleneck. But maybe that s just
      Message 2 of 7 , Nov 21, 2002
      • 0 Attachment
        On Tue, 19 Nov 2002, Bert wrote:
        > In our (futile?!) quest to make p2p the preferred method of information
        > sharing (and by that I don't mean porn and MP3's :-) within the
        > corporate enterprise, we've added some new features to the YouServ p2p
        > webhosting system and described them in a pair of papers.

        A thing about yooserv that's a little funny is the use of dynamic DNS for
        identity, because it implies an admistrative bottleneck. But maybe that's
        just kneejerk reaction. Can you say how this has worked out in practice,
        Bert?

        - Lucas
      • Nikolaj Nyholm
        ... The idea is not so far out. Dynamic DNS will in essence run identity and discovery for 3G (layer 2/link layer mobility). On a smaller note, ENUM
        Message 3 of 7 , Nov 22, 2002
        • 0 Attachment
          > A thing about yooserv that's a little funny is the use of
          > dynamic DNS for
          > identity, because it implies an admistrative bottleneck. But

          The idea is not so far out.

          Dynamic DNS will in essence run identity and discovery for 3G (layer 2/link
          layer mobility).

          On a smaller note, ENUM delegations (use telephone number in DNS as
          identity) are finally starting to happen, using SIP for presence and
          message/session initiation.
          All current efforts are, however, on the purely experimental basis.

          On an even smaller note, we've done work on building extended identity
          functions on top of any of the above two 'identity layers'.

          /n
        • Lucas Gonze
          ... neat. can you give examples, Nikolaj? - Lucas
          Message 4 of 7 , Nov 24, 2002
          • 0 Attachment
            Nikolaj Nyholm wrote:
            > On an even smaller note, we've done work on building extended identity
            > functions on top of any of the above two 'identity layers'.

            neat. can you give examples, Nikolaj?

            - Lucas
          • Bert
            ... We run BIND to handle DNS, and configure it to accept dynamic DNS updates only from localhost. A YouServ coordinating service also runs on this machine
            Message 5 of 7 , Nov 24, 2002
            • 0 Attachment
              Lucas Gonze wrote:

              >>By administrative do you mean "involving human adminstration"? There is
              >>certainly no such bottleneck as the domains are assigned and registered
              >>automatically using an injective mapping from the user's (authenticated)
              >>e-mail address. Securing the base domain (userv.ibm.com in the case of
              >>the IBM deployment) certainly involves some administrative involvement
              >>but it only has to be done once (+ whatever is required for keeping it
              >>from expiring).
              >>
              >>
              >
              >Bear with me while I'm being stupid, Bert. The answer to my question is
              >the one you give in your message, that the dynamic domains are assigned
              >and registered automatically. Can you describe this process a little
              >more? How do you know that someone applying for a dynamic domain is a
              >youserv node? Is it ok with you if people use these addresses for
              >non-youserv purposes?
              >
              >

              We run BIND to handle DNS, and configure it to accept dynamic DNS
              updates only from localhost. A YouServ "coordinating" service also runs
              on this machine to receive requests from YouServ clients.

              When a user starts his client, he provides his userID/Password, this
              gets sent to the coordinator along with the node's IP address. The
              protocol for sending this information is YouServ-specific. Once
              received, the coordinator verifies the userid & password, and if it is
              valid, the IP/domain name mapping is set up by sending the appropriate
              DNS update command to the BIND service.

              Some people have in fact used the YouServ simply as a Dynamic DNS
              service for their Apache webservers, and in fact there is a
              user-configurable mode that allows YouServ to be used for this purpose.
              Since it's just a neglible additional load on the server, this hasn't
              been a concern. If needed, we can always reject a user from the service
              if they are found not to be playing nice. This could be somewhat
              automated, although there's always the possibility that someone could
              reverse engineer the YouServ protocols to mimic a real YouServ node just
              enough to avoid detection.
            • Lucas Gonze
              ... What kind of stuff, Nikolaj? Is that in relation to youserv?
              Message 6 of 7 , Nov 27, 2002
              • 0 Attachment
                On Fri, 22 Nov 2002, Nikolaj Nyholm wrote:
                > On an even smaller note, we've done work on building extended identity
                > functions on top of any of the above two 'identity layers'.

                What kind of stuff, Nikolaj? Is that in relation to youserv?
              • Nikolaj Nyholm
                ... Sorry for the tardy response... Our work is not related to YouServ, which I must admit I know too little about to qualify to write about. The work we have
                Message 7 of 7 , Dec 3, 2002
                • 0 Attachment
                  On Wed, 27 Nov 2002, Lucas Gonze wrote:
                  > On Fri, 22 Nov 2002, Nikolaj Nyholm wrote:
                  > > On an even smaller note, we've done work on building
                  > extended identity
                  > > functions on top of any of the above two 'identity layers'.
                  >
                  > What kind of stuff, Nikolaj? Is that in relation to youserv?


                  Sorry for the tardy response...

                  Our work is not related to YouServ, which I must admit I know too little
                  about to qualify to write about.


                  The work we have done, relates to DNS and its universal (any ip enabled
                  device can look up any DNS record), yet distributed, mechanisms to create a
                  common security domain.


                  Having established a common security domain, enables a user, application,
                  device, etc., to start considering authentication and authorisation. And
                  since we have a distributed security domain, authentication and
                  authorization can be equally distributed.

                  While we have our own XML and SOAP schemas for authentication and
                  authorization, others could easily be used. (I actually fancy some of the
                  schemas coming out Microsoft's GXA pull (SOAP extensions like WS-Security
                  and WS-Authorization), even though work should be done to take down the
                  level of complexity).


                  Once authentication and authorization are in place, we can start looking at
                  exchanging information, which again can be in metadata or more loosely
                  regulated formats.


                  The common security domain is btw the single biggest weakness of SAML, and
                  will pose a huge dilemma in the user scenario. SAML was and is designed with
                  the enterprise user scenario in mind, where explicit trust between security
                  domains is very tightly managed/regulated.


                  Over the last 1½ years, digital identity has truly become a buzzword,
                  totally muddling the different uses.
                  At the Digital ID World conference (http://www.didw.com) in October, I tried
                  to outline three main categories:
                  o Enterprise user (Keywords: SAML, WS-Security, Novell, TrustBridge,
                  Active Directory, Netegrity, Oblix)
                  o Extended CRM (Keyword: Liberty)
                  o Private user (Keywords: PindId.org (not the .com flavour, however), SIP,
                  Jabber and other presence like protocols)


                  As Doc Searls notes (http://www.linuxjournal.com/article.php?sid=6382), most
                  of the work is going on in the first two categories, and what we really need
                  is someone to address the needs of the user.

                  While I believe this might be SIP, Jabber or other presence protocols, I am
                  working on clarifying the intellectual properties behind our own work (which
                  is not exclusively our property), in order to come with a basic proposal.
                  I hope to be able to send something out soon.


                  Best regards
                  Nikolaj
                Your message has been successfully submitted and would be delivered to recipients shortly.