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

Re: [decentralization] Simple External Authentication or Single Sign-on for the rest of us

Expand Messages
  • Daniel Harris
    ... At this stage I start to think about a trust model because that s what you re asking here: can the user trust alpha.com with their password? So, a
    Message 1 of 16 , Sep 24, 2003
    • 0 Attachment
      On Wednesday, September 24, 2003, at 07:41 am, Julian Bond wrote:
      > The real security question is whether the end user is comfortable
      > giving
      > ID+Password+URL to alpha.com. Arguably, alpha.com is building a
      > database
      > of these triples in the knowledge that they *might* be useful
      > elsewhere.[2]

      At this stage I start to think about a trust model because that's what
      you're asking here: can the user trust alpha.com with their password?
      So, a distributed authentication system would be greatly enhanced if
      married with a trust model where we could all comment/rate each other
      and each other's services.

      So, the user could do a trust lookup and find out if alpha.com had ever
      been dodgy before submitting their details. The trust model is another
      goal for KendraBase.

      Cheers Daniel
    • Jeffrey Kay
      What you really want is a setup where alpha.com doesn t get the password -- merely an authentication token. This is the basic idea behind passport. The point
      Message 2 of 16 , Sep 24, 2003
      • 0 Attachment
        What you really want is a setup where alpha.com doesn't get the password --
        merely an authentication token. This is the basic idea behind passport.
        The point of it is not that the external authentication handles the access
        control, but that the user is definitively identified. So a token from the
        service plus the password and user id are transmitted to the third party
        validation service. A token is returned and presented back to the
        requesting service indicating that the user is validated. The service then
        can use that token to determine the access privileges of the user.

        This is similar to using a signed certificate to authenticate a user, except
        that a third party is managing the process. The bigger question is whether
        alpha.com can trust bravo.com. Passport is trusted because it's Microsoft
        (more or less). But I'm not sure I'd build an application that trusts a
        third party server to authenticate the user without some serious assurances
        that the authenticating service was secure and trustworthy itself.

        Cheers -- jeff

        On 9/24/03 2:41 AM, "Julian Bond" <julian_bond@...> wrote:

        > Lucas Gonze <lgonze@...> wrote:
        >> I think SEA would be very useful in low security situations like web
        >> discussion groups, on blogs in particular, and questionable in
        >> ecommerce sites.
        >>
        >> On Mardi, sep 23, 2003, at 16:24 America/New_York, Lucas Gonze wrote:
        >>
        >>> The main security issue is the degree to which a user is already using
        >>> the same username and password on multiple sites.
        >
        > Ignore the actual protocol for a moment. Site alpha.com validates with
        > Site bravo.com. Site Alpha knows that UserID="foo" + Password="bar" +
        > URL="bravo.com/sea/" = True. The remaining security question is the
        > reputation or authenticity of the web service at bravo.com/sea/ This is
        > the added value that centralized single sign-on systems claim to
        > provide. I guess my argument is that there are very large numbers of
        > situations where that last layer of authentication is not needed. So if
        > it's not needed, stop trying to solve that problem and come up with the
        > simplest solution that is "good enough" to answer the layer below.
        >
        > The real security question is whether the end user is comfortable giving
        > ID+Password+URL to alpha.com. Arguably, alpha.com is building a database
        > of these triples in the knowledge that they *might* be useful
        > elsewhere.[2]
        >
        > In terms of protocol, I'm probably getting it wrong and ignoring prior
        > art. I'm sure there are challenge-response approaches where the password
        > never goes down the wire (SPA? APOP?). And if necessary the whole
        > authentication transaction can be hidden with TLS[1].
        >
        > In terms of UI, the user would need to provide ID;Password;URL;Protocol
        > Where protocol is one of SEA, Drupal, Blogger, Delphi Forums, Manila,
        > Yahoo, Jabber and LDAP[2]. And URL may be part of ID for some protocols.
        >
        > [1]Such a shame that there's a commercial lock on TLS certificates.
        > [2]Several of these take advantage of an existing API that includes
        > password. I suspect that a bit of screen scraping and cURL could extend
        > this to Passport, AOL, and quite a few others. Clearly,
        > ID+Password+Passport is worth quite a bit more than ID+Password+Manila
        > but also has much more potential for abuse.

        jeffrey kay
        weblog <k2.com> pgp key <www.k2.com/keys.htm> aim <jkayk2>
        share files with me -- get shinkuro -- <www.shinkuro.com>

        "first get your facts, then you can distort them at your leisure" -- mark
        twain
        "if the person in the next lane at the stoplight rolls up the window and
        locks the door, support their view of life by snarling at them" -- a biker's
        guide to life
        "if A equals success, then the formula is A equals X plus Y plus Z. X is
        work. Y is play. Z is keep your mouth shut." -- albert einstein
      • Julian Bond
        ... A trivial version of this is A collects an ID+Password+URL from the user. It passes ID to URL and gets MD5(the current known password) back. If this
        Message 3 of 16 , Sep 24, 2003
        • 0 Attachment
          Jeffrey Kay <jeff@...> wrote:
          >What you really want is a setup where alpha.com doesn't get the password --
          >merely an authentication token. This is the basic idea behind passport.
          >The point of it is not that the external authentication handles the access
          >control, but that the user is definitively identified. So a token from the
          >service plus the password and user id are transmitted to the third party
          >validation service. A token is returned and presented back to the
          >requesting service indicating that the user is validated. The service then
          >can use that token to determine the access privileges of the user.

          A trivial version of this is A collects an ID+Password+URL from the
          user. It passes ID to URL and gets MD5(the current known password) back.
          If this matches MD5(password collected from user), the user is
          validated. At least the password never on the wire between the systems.

          What I was hoping for was that we could all run our own validation
          service in the spirit of the name of this mailing list
          (de-centralization).

          >This is similar to using a signed certificate to authenticate a user, except
          >that a third party is managing the process. The bigger question is whether
          >alpha.com can trust bravo.com.

          Well I (the person logging in) can trust bravo.com because that's my own
          site running my own password management system. Or it's something like
          the jabber server I use. Or it's my Blogger account. Or whatever, I'm
          explicitly telling Alpha.com that *I* trust it and the ID+URL will
          return repeatable results with appropriate passwords.

          >Passport is trusted because it's Microsoft
          >(more or less). But I'm not sure I'd build an application that trusts a
          >third party server to authenticate the user without some serious assurances
          >that the authenticating service was secure and trustworthy itself.

          I'll just say it again. This is not supposed to provide industrial
          strength authentication. It's designed to deal with those situations we
          all hit every day when we go to yet another website wanting to enter a
          comment or post an entry. We just need to identify ourselves in some
          repeatable way. Now if this leads to a decentralised, distributed,
          industrial strength, authentication system to rival Passport, Liberty,
          PingID all well and good. But that's not the immediate goal.

          --
          Julian Bond Email&MSM: julian.bond@...
          Webmaster: http://www.ecademy.com/
          Personal WebLog: http://www.voidstar.com/
          M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
        • Jeffrey Kay
          ... I think a better way to approach is that A forwards user and return-to URL to SEA service. SEA interacts directly with the user to validate and then
          Message 4 of 16 , Sep 24, 2003
          • 0 Attachment
            On 9/24/03 11:22 AM, "Julian Bond" <julian_bond@...> wrote:

            > Jeffrey Kay <jeff@...> wrote:
            >> What you really want is a setup where alpha.com doesn't get the password --
            >> merely an authentication token. This is the basic idea behind passport.
            >> The point of it is not that the external authentication handles the access
            >> control, but that the user is definitively identified. So a token from the
            >> service plus the password and user id are transmitted to the third party
            >> validation service. A token is returned and presented back to the
            >> requesting service indicating that the user is validated. The service then
            >> can use that token to determine the access privileges of the user.
            >
            > A trivial version of this is A collects an ID+Password+URL from the
            > user. It passes ID to URL and gets MD5(the current known password) back.
            > If this matches MD5(password collected from user), the user is
            > validated. At least the password never on the wire between the systems.
            >
            > What I was hoping for was that we could all run our own validation
            > service in the spirit of the name of this mailing list
            > (de-centralization).

            I think a better way to approach is that A forwards user and "return-to URL"
            to SEA service. SEA interacts directly with the user to validate and then
            returns user to A with authentication token. The key is that A wants to
            know that the user is authenticated so that A can offer services, data, etc.
            >
            >> This is similar to using a signed certificate to authenticate a user, except
            >> that a third party is managing the process. The bigger question is whether
            >> alpha.com can trust bravo.com.
            >
            > Well I (the person logging in) can trust bravo.com because that's my own
            > site running my own password management system. Or it's something like
            > the jabber server I use. Or it's my Blogger account. Or whatever, I'm
            > explicitly telling Alpha.com that *I* trust it and the ID+URL will
            > return repeatable results with appropriate passwords.

            The problem is that alpha.com doesn't know if it can trust bravo.com as an
            SEA. Why should alpha presume that bravo is telling the truth? It doesn't
            matter if the user trusts the SEA -- all the user cares about is that the
            SEA will respond affirmatively when asked if the user is valid. In essence,
            there's no security there.

            >> Passport is trusted because it's Microsoft
            >> (more or less). But I'm not sure I'd build an application that trusts a
            >> third party server to authenticate the user without some serious assurances
            >> that the authenticating service was secure and trustworthy itself.
            >
            > I'll just say it again. This is not supposed to provide industrial
            > strength authentication. It's designed to deal with those situations we
            > all hit every day when we go to yet another website wanting to enter a
            > comment or post an entry. We just need to identify ourselves in some
            > repeatable way. Now if this leads to a decentralised, distributed,
            > industrial strength, authentication system to rival Passport, Liberty,
            > PingID all well and good. But that's not the immediate goal.

            I understand the objective, but the problem is that this doesn't really
            offer any true authentication of the individual. In order for alpha to be
            assured that the user is who he says he is, alpha must trust bravo. If
            alpha has no means for determining that bravo is trustworthy, then the
            system fails.

            I could introduce you to a stranger on the street, but since that stranger
            doesn't know me, he can't confirm that I'm telling the truth about your
            identity. OTOH, if I introduce you to a friend of mine, my friend has
            confidence that I am who I say I am and therefore you are who I say you are.

            The basic idea behind authentication are that you have to trust the
            authenticating authority. If you can't then the system fails.

            Cheers -- jeff

            jeffrey kay
            weblog <k2.com> pgp key <www.k2.com/keys.htm> aim <jkayk2>
            share files with me -- get shinkuro -- <www.shinkuro.com>

            "first get your facts, then you can distort them at your leisure" -- mark
            twain
            "if the person in the next lane at the stoplight rolls up the window and
            locks the door, support their view of life by snarling at them" -- a biker's
            guide to life
            "if A equals success, then the formula is A equals X plus Y plus Z. X is
            work. Y is play. Z is keep your mouth shut." -- albert einstein
          • Lucas Gonze
            On Mercredi, sep 24, 2003, at 05:57 America/New_York, Daniel Harris ... You should do that, but you should do that anyway. The reason why the security of the
            Message 5 of 16 , Sep 24, 2003
            • 0 Attachment
              On Mercredi, sep 24, 2003, at 05:57 America/New_York, Daniel Harris
              wrote:

              > On Wednesday, September 24, 2003, at 07:41 am, Julian Bond wrote:
              >> The real security question is whether the end user is comfortable
              >> giving
              >> ID+Password+URL to alpha.com. Arguably, alpha.com is building a
              >> database
              >> of these triples in the knowledge that they *might* be useful
              >> elsewhere.[2]
              >
              > At this stage I start to think about a trust model because that's what
              > you're asking here: can the user trust alpha.com with their password?
              > So, a distributed authentication system would be greatly enhanced if
              > married with a trust model where we could all comment/rate each other
              > and each other's services.

              You should do that, but you should do that anyway.

              The reason why the security of the SEA model depends on how often
              people reuse the same name/pwd combos on a bunch of different sites is
              that *both* models are about spreading confidential data around. If SEA
              means that people will use the same combo in more places, it's less
              secure, otherwise it's no worse.

              - Lucas
            • Julian Bond
              ... Back in the real world, there s a reductio ad absurdam problem with this. Most Authorities (eg Passport) are only really warranting that this ID is
              Message 6 of 16 , Sep 24, 2003
              • 0 Attachment
                Jeffrey Kay <jeff@...> wrote:
                >The basic idea behind authentication are that you have to trust the
                >authenticating authority. If you can't then the system fails.

                Back in the real world, there's a reductio ad absurdam problem with
                this. Most "Authorities" (eg Passport) are only really warranting that
                this ID is associated with an email address which appeared to once have
                a human reading it. Even eCommerce SSL certificates only really warrant
                that a domain had a fax number associated with it at one time.

                So let's try a use-case. I got it into my head that the Deanspace
                software could be used by the Liberal-Democrats in the UK. While doing
                the research, I signed up at geeks4dean.com and told them to validate
                against jbond:drupal.login:voidstar.com/xmlrpc.php. When the password I
                gave them validated, they picked up my foaf file and thumbnail and
                auto-created a profile for me. There's an audit trail and if necessary
                someone could look at voidstar.com and find content going back a few
                years. They could check the pgp signature on the foaf file. The domain
                has some history. Email addresses that include @... appear all
                over the web. There's a CV up there. So clearly voidstar.com is a pretty
                good authenticating authority for jbond. Now I go to expats4dean.co.uk
                and tell it to validate on jbond:drupal.login:geeks4dean.com/xmlrpc.php
                They create their own profile based on the one at geeks4dean.com which
                originally came from voidstar.com.

                When I start posting extreme libertarian anarcho-capitalist tracts on
                expats4dean.co.uk and they decide to ban me, they can post all over
                their site, geeks4dean.com, this mailing list, bloggercon and anywhere
                else they choose that the entity that calls itself jbond and lives at
                voidstar.com is not to be trusted.

                ISTM that this has proved at least as effective as the big centralized
                authenticating authorities. And we didn't have to involve them at all.

                I feel sure that I'm re-inventing wheels here. And I've no doubt that
                I'm glossing over deep problems. But I refuse to accept that this
                problem needs either some BigCo in the middle, or incredibly complicated
                web services that are all spec and no implementation.

                --
                Julian Bond Email&MSM: julian.bond@...
                Webmaster: http://www.ecademy.com/
                Personal WebLog: http://www.voidstar.com/
                M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
              • Jeffrey Kay
                ... You re correct about this -- what exactly does the authority warrant? Passport, Verisign and others offer a degree of warranty that the user validation
                Message 7 of 16 , Sep 24, 2003
                • 0 Attachment
                  On 9/24/03 4:10 PM, "Julian Bond" <julian_bond@...> wrote:

                  > Jeffrey Kay <jeff@...> wrote:
                  >> The basic idea behind authentication are that you have to trust the
                  >> authenticating authority. If you can't then the system fails.
                  >
                  > Back in the real world, there's a reductio ad absurdam problem with
                  > this. Most "Authorities" (eg Passport) are only really warranting that
                  > this ID is associated with an email address which appeared to once have
                  > a human reading it. Even eCommerce SSL certificates only really warrant
                  > that a domain had a fax number associated with it at one time.

                  You're correct about this -- what exactly does the authority warrant?
                  Passport, Verisign and others offer a degree of warranty that the user
                  validation translates into something. Sometimes it's a signed letter,
                  sometimes it's an email callback. The purpose of this authentication
                  varies, but generally it's to give a third party a feeling that somehow the
                  authenticated individual or service corresponds to a specific human being or
                  company.

                  > So let's try a use-case. I got it into my head that the Deanspace
                  > software could be used by the Liberal-Democrats in the UK. While doing
                  > the research, I signed up at geeks4dean.com and told them to validate
                  > against jbond:drupal.login:voidstar.com/xmlrpc.php. When the password I
                  > gave them validated, they picked up my foaf file and thumbnail and
                  > auto-created a profile for me. There's an audit trail and if necessary
                  > someone could look at voidstar.com and find content going back a few
                  > years. They could check the pgp signature on the foaf file. The domain
                  > has some history. Email addresses that include @... appear all
                  > over the web. There's a CV up there. So clearly voidstar.com is a pretty
                  > good authenticating authority for jbond. Now I go to expats4dean.co.uk
                  > and tell it to validate on jbond:drupal.login:geeks4dean.com/xmlrpc.php
                  > They create their own profile based on the one at geeks4dean.com which
                  > originally came from voidstar.com.

                  So this use-case is interesting, but it doesn't tell me the key question
                  which is why geeks4dean.com cares who you are. If the purpose is to ensure
                  that an id that you select remains unique within their system, then this
                  third party authentication is overkill. If, on the other hand, it's to
                  protect your credit card that's on file for campaign contributions, then
                  both of you have an interest in ensuring that the authenticated user is
                  legitimately using the credit card.

                  Essentially, if the value of identity is significant enough, the validating
                  party needs to develop trust in that identity by trusting the authority that
                  validates it. This is a simple enough concept. If gees4deen or
                  expats4dean doesn't really care who you are and the validation is merely to
                  allow you to maintain a single, but essentially valueless, identity on their
                  system, then they don't care who the authenticating authority is but you
                  should (this is for your protection now).

                  > When I start posting extreme libertarian anarcho-capitalist tracts on
                  > expats4dean.co.uk and they decide to ban me, they can post all over
                  > their site, geeks4dean.com, this mailing list, bloggercon and anywhere
                  > else they choose that the entity that calls itself jbond and lives at
                  > voidstar.com is not to be trusted.

                  See my comments above on significance of identity. Essentially, this tells
                  me that the authentication is for the user's purposes, not the services. In
                  essence, this is equivalent to signing up for a service that e-mails you
                  back to validate that you really signed up. They don't care who the
                  individual really is, just that you aren't lying about your e-mail address.

                  > ISTM that this has proved at least as effective as the big centralized
                  > authenticating authorities. And we didn't have to involve them at all.

                  If the system is fundamentally about you protecting your own identity and
                  offering a means of transmitting that singular identity to a service, then I
                  suppose that this has some value as long as the service doesn't really care
                  that much if someone hacks your identity. In other words, it's your problem
                  not the services. However, if the service has some stake in the game, then
                  their identification of you has to be stronger than that -- they need to
                  trust the authenticating authority.

                  > I feel sure that I'm re-inventing wheels here. And I've no doubt that
                  > I'm glossing over deep problems. But I refuse to accept that this
                  > problem needs either some BigCo in the middle, or incredibly complicated
                  > web services that are all spec and no implementation.

                  This is a little melodramatic for a conclusion, so let me clarify my
                  thoughts on this. The solution doesn't have to be centralized or
                  implemented by some big company. However it does have to meet the basic
                  needs for authenticating individuals. Weak authentication through e-mail is
                  common as a simple test of valid e-mail use for service sign-up or mailing
                  lists. It's not good enough for credit cards, however. Similarly, the
                  system that you are talking about seems like it would be fine to give an
                  individual peace of mind that he or she is uniquely identifying themselves
                  to a service as long as the service didn't really care who the user was. If
                  they did, then the service would have to have some trust somehow in the
                  authenticating service. That's really the hole in this solution -- how does
                  a service develop trust in the authority to get confidence that the identity
                  really does belong to the user of that identity?

                  jeffrey kay
                  weblog <k2.com> pgp key <www.k2.com/keys.htm> aim <jkayk2>
                  share files with me -- get shinkuro -- <www.shinkuro.com>

                  "first get your facts, then you can distort them at your leisure" -- mark
                  twain
                  "if the person in the next lane at the stoplight rolls up the window and
                  locks the door, support their view of life by snarling at them" -- a biker's
                  guide to life
                  "if A equals success, then the formula is A equals X plus Y plus Z. X is
                  work. Y is play. Z is keep your mouth shut." -- albert einstein
                • Lucas Gonze
                  ... I told you so. :-) Blogger should do it, PayPal shouldn t. ... I m not sure I see that I see how that s a hole. The service should trust the authority
                  Message 8 of 16 , Sep 24, 2003
                  • 0 Attachment
                    Jeffrey Kay wrote:
                    > The solution doesn't have to be centralized or
                    > implemented by some big company. However it does have to meet the basic
                    > needs for authenticating individuals. Weak authentication through e-mail is
                    > common as a simple test of valid e-mail use for service sign-up or mailing
                    > lists. It's not good enough for credit cards, however.

                    I told you so. :-)

                    Blogger should do it, PayPal shouldn't.

                    > Similarly, the
                    > system that you are talking about seems like it would be fine to give an
                    > individual peace of mind that he or she is uniquely identifying themselves
                    > to a service as long as the service didn't really care who the user was. If
                    > they did, then the service would have to have some trust somehow in the
                    > authenticating service. That's really the hole in this solution -- how does
                    > a service develop trust in the authority to get confidence that the identity
                    > really does belong to the user of that identity?

                    I'm not sure I see that I see how that's a hole. The service should trust
                    the authority because the user did. If the authority is good enough for
                    the user, it's good enough for the service.

                    - Lucas
                  • Jeffrey Kay
                    ... So on this point we agree :-). ... It s not a hole if you accept the caveat that the service doesn t really care who the user is (PayPal v. Blogger). It
                    Message 9 of 16 , Sep 24, 2003
                    • 0 Attachment
                      On 9/24/03 4:58 PM, "Lucas Gonze" <lgonze@...> wrote:

                      > Jeffrey Kay wrote:
                      >> The solution doesn't have to be centralized or
                      >> implemented by some big company. However it does have to meet the basic
                      >> needs for authenticating individuals. Weak authentication through e-mail is
                      >> common as a simple test of valid e-mail use for service sign-up or mailing
                      >> lists. It's not good enough for credit cards, however.
                      >
                      > I told you so. :-)
                      >
                      > Blogger should do it, PayPal shouldn't.

                      So on this point we agree :-).

                      >> Similarly, the
                      >> system that you are talking about seems like it would be fine to give an
                      >> individual peace of mind that he or she is uniquely identifying themselves
                      >> to a service as long as the service didn't really care who the user was. If
                      >> they did, then the service would have to have some trust somehow in the
                      >> authenticating service. That's really the hole in this solution -- how does
                      >> a service develop trust in the authority to get confidence that the identity
                      >> really does belong to the user of that identity?
                      >
                      > I'm not sure I see that I see how that's a hole. The service should trust
                      > the authority because the user did. If the authority is good enough for
                      > the user, it's good enough for the service.

                      It's not a hole if you accept the caveat that the service doesn't really
                      care who the user is (PayPal v. Blogger). It is a hole if the service cares
                      who the user is.

                      It wasn't clear to me from the beginning of this discussion that this caveat
                      was a given.

                      Cheers -- jeff

                      jeffrey kay
                      weblog <k2.com> pgp key <www.k2.com/keys.htm> aim <jkayk2>
                      share files with me -- get shinkuro -- <www.shinkuro.com>

                      "first get your facts, then you can distort them at your leisure" -- mark
                      twain
                      "if the person in the next lane at the stoplight rolls up the window and
                      locks the door, support their view of life by snarling at them" -- a biker's
                      guide to life
                      "if A equals success, then the formula is A equals X plus Y plus Z. X is
                      work. Y is play. Z is keep your mouth shut." -- albert einstein
                    • Lucas Gonze
                      ... Fair enough. Agreed. ... So, the big thing stopping this idea from happening is that the transmission of the password from the service to the authority
                      Message 10 of 16 , Sep 24, 2003
                      • 0 Attachment
                        Jeffrey Kay wrote:
                        > It wasn't clear to me from the beginning of this discussion that this caveat
                        > was a given.

                        Fair enough. Agreed.

                        ...

                        So, the big thing stopping this idea from happening is that the
                        transmission of the password from the service to the authority has to be
                        unobservable, which means that the authority has to run https, which many
                        blogging tools don't have. I mention this because I hoked up some perl
                        yesterday to implement Julian's pseudocode in a RESTy way*. I made it
                        through to the part where I needed https, which my personal ISP doesn't
                        provide.

                        Since TLS is not available via things like blosxom, a useful improvement
                        would be to allow for the encryption to be done by CGI.

                        - Lucas

                        * REST design for SEA

                        1) Service picks up SEA name in form user@domain, as well as password.
                        2) Service requests https://domain/SEAUserResolutionService/user/password
                        3) Authority returns 200 OK to authenticate, 404 otherwise.
                        * Response body is undefined and left for future extension.
                        * Expiration in ten minutes
                      • Julian Bond
                        Having thought about this a bit and talked to some other people, it seems there might be a useful idea here. Enough to justify a little standards work or at
                        Message 11 of 16 , Oct 3, 2003
                        • 0 Attachment
                          Having thought about this a bit and talked to some other people, it
                          seems there might be a useful idea here. Enough to justify a little
                          standards work or at least discussion.

                          So in the time honoured fashion, here's the mailing list
                          http://groups.yahoo.com/group/sim-ext-auth/

                          And a Wiki will be along shortly. Probably at
                          http://www.voidstar.com/sea/

                          --
                          Julian Bond Email&MSM: julian.bond@...
                          Webmaster: http://www.ecademy.com/
                          Personal WebLog: http://www.voidstar.com/
                          M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
                        Your message has been successfully submitted and would be delivered to recipients shortly.