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

Simple External Authentication or Single Sign-on for the rest of us

Expand Messages
  • Julian Bond
    Here s a proposal for a low tech, de-centralized, remote authentication system with profile management. It s aimed at all those low security situations where
    Message 1 of 16 , Sep 23, 2003
    View Source
    • 0 Attachment
      Here's a proposal for a low tech, de-centralized, remote authentication
      system with profile management. It's aimed at all those low security
      situations where you need to login to a website but don't want to go
      through the hassle of creating an authenticated profile.

      The basic approach is a simple web service. This web service should
      support and be implemented in XML-RPC, ReST and SOAP (in order of
      priority). It would take two string parameters; an ID and password. It
      would return True or False. This service would usually be available in a
      standard location (say "remote.login", /xmlrpc/, port 80) or can be
      found via some auto-discovery mechanism such as RSD.

      The intention is that this web service is widely implemented either as
      standalone CGI files on personal websites, or as a service on more
      centralised systems like Typepad, Slashdot, etc etc.

      On the server side, anyone building systems that require login but are
      not overly concerned about security should add support for external
      authentication. If the user types in something like ID: foo@... it
      will pass foo and the password to the web service at bar.com. If it
      returns true, then either log the person in against foo@... or
      create a user record linked to foo@... and log them in against it.

      For this to get widespread implementation at least three things are
      needed.

      1) Simple stand alone CGI programs in the major languages (eg perl, php,
      python, or whatever) that implement the service. These should include a
      minimally simple interface to maintain a fairly short list of
      ID/Password pairs.

      2) A set of toolkits in all the major languages for server-side
      applications to implement both sides of remote login.

      3) Support for remote login built into successful apps like slash,
      php-nuke, movable-type, blogger, etc etc.

      Extensions and Issues
      ---------------------
      The biggest issue I see is that there is minimal security and minimal
      hiding of passwords but this doesn't actually matter. We're not trying
      to replace Passport, Liberty or PingID. What we are doing is creating a
      standard for those tens of thousands of websites that need minimal
      authentication. Many of us currently solve this by using the same ID and
      Password wherever possible. This system formalises this by letting us
      control that common ID-Password ourselves in one place. It also avoids
      the problem of having to create jbond23, jbond23uk, j23bond and so on
      because jbond has already been taken.

      This idea immediately suggests some standard, possibly using FOAF, to
      let an end user or participating sites provide basic user profile
      information to a site that is creating a new user record. I have in mind
      some similar approach of minimal cgi program for de-centralization,
      toolkits for App coders and support in major platforms for a
      standardised foaf, vcard or similar set of data. This data could then be
      used to pre-populate user records.

      If this takes off, it'll need a name. Really Simple Authentication is
      appealing, but RSA is already taken... Simple External Authentication
      (SEA) looks possible.

      Acknowledgements
      ----------------
      This whole essay was inspired when I went back and had another look at
      the current state of Drupal. For a year or so Drupal has had a remote
      authentication system that let you log in to a Drupal site using an ID
      and password from another site. They currently have support for Drupal,
      Blogger, Delphi Forums, Manila, Yahoo, Jabber, LDAP. The code and
      techniques are admirably simple and would provide a good basis for the
      more general approach outlined above. http://drupal.org/node/view/312

      You probably know about Deanspace http://www.deanspace.org/ which is
      based on Drupal. Every Deanspace site supports this style of remote
      auth.

      Archive
      -------
      This is archived at
      http://www.voidstar.com/node.php?id=1537
      http://www.lazyweb.org/archives/004992.html

      Next?
      -----
      Has this got wings? Does it need a mailing list? Is there a better
      mailing list to discuss this? Does it need a wiki?

      --
      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
    • Lucas Gonze
      The main security issue is the degree to which a user is already using the same username and password on multiple sites. - Lucas
      Message 2 of 16 , Sep 23, 2003
      View Source
      • 0 Attachment
        The main security issue is the degree to which a user is already using
        the same username and password on multiple sites.

        - Lucas


        On Mardi, sep 23, 2003, at 05:15 America/New_York, Julian Bond wrote:

        > Here's a proposal for a low tech, de-centralized, remote authentication
        > system with profile management. It's aimed at all those low security
        > situations where you need to login to a website but don't want to go
        > through the hassle of creating an authenticated profile.
        >
        > The basic approach is a simple web service. This web service should
        > support and be implemented in XML-RPC, ReST and SOAP (in order of
        > priority). It would take two string parameters; an ID and password. It
        > would return True or False. This service would usually be available in
        > a
        > standard location (say "remote.login", /xmlrpc/, port 80) or can be
        > found via some auto-discovery mechanism such as RSD.
        >
        > The intention is that this web service is widely implemented either as
        > standalone CGI files on personal websites, or as a service on more
        > centralised systems like Typepad, Slashdot, etc etc.
        >
        > On the server side, anyone building systems that require login but are
        > not overly concerned about security should add support for external
        > authentication. If the user types in something like ID: foo@... it
        > will pass foo and the password to the web service at bar.com. If it
        > returns true, then either log the person in against foo@... or
        > create a user record linked to foo@... and log them in against it.
        >
        > For this to get widespread implementation at least three things are
        > needed.
        >
        > 1) Simple stand alone CGI programs in the major languages (eg perl,
        > php,
        > python, or whatever) that implement the service. These should include a
        > minimally simple interface to maintain a fairly short list of
        > ID/Password pairs.
        >
        > 2) A set of toolkits in all the major languages for server-side
        > applications to implement both sides of remote login.
        >
        > 3) Support for remote login built into successful apps like slash,
        > php-nuke, movable-type, blogger, etc etc.
        >
        > Extensions and Issues
        > ---------------------
        > The biggest issue I see is that there is minimal security and minimal
        > hiding of passwords but this doesn't actually matter. We're not trying
        > to replace Passport, Liberty or PingID. What we are doing is creating a
        > standard for those tens of thousands of websites that need minimal
        > authentication. Many of us currently solve this by using the same ID
        > and
        > Password wherever possible. This system formalises this by letting us
        > control that common ID-Password ourselves in one place. It also avoids
        > the problem of having to create jbond23, jbond23uk, j23bond and so on
        > because jbond has already been taken.
        >
        > This idea immediately suggests some standard, possibly using FOAF, to
        > let an end user or participating sites provide basic user profile
        > information to a site that is creating a new user record. I have in
        > mind
        > some similar approach of minimal cgi program for de-centralization,
        > toolkits for App coders and support in major platforms for a
        > standardised foaf, vcard or similar set of data. This data could then
        > be
        > used to pre-populate user records.
        >
        > If this takes off, it'll need a name. Really Simple Authentication is
        > appealing, but RSA is already taken... Simple External Authentication
        > (SEA) looks possible.
        >
        > Acknowledgements
        > ----------------
        > This whole essay was inspired when I went back and had another look at
        > the current state of Drupal. For a year or so Drupal has had a remote
        > authentication system that let you log in to a Drupal site using an ID
        > and password from another site. They currently have support for Drupal,
        > Blogger, Delphi Forums, Manila, Yahoo, Jabber, LDAP. The code and
        > techniques are admirably simple and would provide a good basis for the
        > more general approach outlined above. http://drupal.org/node/view/312
        >
        > You probably know about Deanspace http://www.deanspace.org/ which is
        > based on Drupal. Every Deanspace site supports this style of remote
        > auth.
        >
        > Archive
        > -------
        > This is archived at
        > http://www.voidstar.com/node.php?id=1537
        > http://www.lazyweb.org/archives/004992.html
        >
        > Next?
        > -----
        > Has this got wings? Does it need a mailing list? Is there a better
        > mailing list to discuss this? Does it need a wiki?
        >
        > --
        > 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
        >
        > To unsubscribe from this group, send an email to:
        > decentralization-unsubscribe@egroups.com
        >
        > Announce or discover P2P conferences on the P2P Conference Wiki at
        > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >
      • Lucas Gonze
        I think SEA would be very useful in low security situations like web discussion groups, on blogs in particular, and questionable in ecommerce sites.
        Message 3 of 16 , Sep 23, 2003
        View Source
        • 0 Attachment
          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.
          >
          > - Lucas
          >
          >
          > On Mardi, sep 23, 2003, at 05:15 America/New_York, Julian Bond wrote:
          >
          >> Here's a proposal for a low tech, de-centralized, remote
          >> authentication
          >> system with profile management. It's aimed at all those low security
          >> situations where you need to login to a website but don't want to go
          >> through the hassle of creating an authenticated profile.
          >>
          >> The basic approach is a simple web service. This web service should
          >> support and be implemented in XML-RPC, ReST and SOAP (in order of
          >> priority). It would take two string parameters; an ID and password. It
          >> would return True or False. This service would usually be available in
          >> a
          >> standard location (say "remote.login", /xmlrpc/, port 80) or can be
          >> found via some auto-discovery mechanism such as RSD.
          >>
          >> The intention is that this web service is widely implemented either as
          >> standalone CGI files on personal websites, or as a service on more
          >> centralised systems like Typepad, Slashdot, etc etc.
          >>
          >> On the server side, anyone building systems that require login but are
          >> not overly concerned about security should add support for external
          >> authentication. If the user types in something like ID: foo@... it
          >> will pass foo and the password to the web service at bar.com. If it
          >> returns true, then either log the person in against foo@... or
          >> create a user record linked to foo@... and log them in against it.
          >>
          >> For this to get widespread implementation at least three things are
          >> needed.
          >>
          >> 1) Simple stand alone CGI programs in the major languages (eg perl,
          >> php,
          >> python, or whatever) that implement the service. These should include
          >> a
          >> minimally simple interface to maintain a fairly short list of
          >> ID/Password pairs.
          >>
          >> 2) A set of toolkits in all the major languages for server-side
          >> applications to implement both sides of remote login.
          >>
          >> 3) Support for remote login built into successful apps like slash,
          >> php-nuke, movable-type, blogger, etc etc.
          >>
          >> Extensions and Issues
          >> ---------------------
          >> The biggest issue I see is that there is minimal security and minimal
          >> hiding of passwords but this doesn't actually matter. We're not trying
          >> to replace Passport, Liberty or PingID. What we are doing is creating
          >> a
          >> standard for those tens of thousands of websites that need minimal
          >> authentication. Many of us currently solve this by using the same ID
          >> and
          >> Password wherever possible. This system formalises this by letting us
          >> control that common ID-Password ourselves in one place. It also avoids
          >> the problem of having to create jbond23, jbond23uk, j23bond and so on
          >> because jbond has already been taken.
          >>
          >> This idea immediately suggests some standard, possibly using FOAF, to
          >> let an end user or participating sites provide basic user profile
          >> information to a site that is creating a new user record. I have in
          >> mind
          >> some similar approach of minimal cgi program for de-centralization,
          >> toolkits for App coders and support in major platforms for a
          >> standardised foaf, vcard or similar set of data. This data could then
          >> be
          >> used to pre-populate user records.
          >>
          >> If this takes off, it'll need a name. Really Simple Authentication is
          >> appealing, but RSA is already taken... Simple External Authentication
          >> (SEA) looks possible.
          >>
          >> Acknowledgements
          >> ----------------
          >> This whole essay was inspired when I went back and had another look at
          >> the current state of Drupal. For a year or so Drupal has had a remote
          >> authentication system that let you log in to a Drupal site using an ID
          >> and password from another site. They currently have support for
          >> Drupal,
          >> Blogger, Delphi Forums, Manila, Yahoo, Jabber, LDAP. The code and
          >> techniques are admirably simple and would provide a good basis for the
          >> more general approach outlined above. http://drupal.org/node/view/312
          >>
          >> You probably know about Deanspace http://www.deanspace.org/ which is
          >> based on Drupal. Every Deanspace site supports this style of remote
          >> auth.
          >>
          >> Archive
          >> -------
          >> This is archived at
          >> http://www.voidstar.com/node.php?id=1537
          >> http://www.lazyweb.org/archives/004992.html
          >>
          >> Next?
          >> -----
          >> Has this got wings? Does it need a mailing list? Is there a better
          >> mailing list to discuss this? Does it need a wiki?
          >>
          >> --
          >> 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
          >>
          >> To unsubscribe from this group, send an email to:
          >> decentralization-unsubscribe@egroups.com
          >>
          >> Announce or discover P2P conferences on the P2P Conference Wiki at
          >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
          >>
          >> Your use of Yahoo! Groups is subject to
          >> http://docs.yahoo.com/info/terms/
          >>
          >>
          >
          >
          > To unsubscribe from this group, send an email to:
          > decentralization-unsubscribe@egroups.com
          >
          > Announce or discover P2P conferences on the P2P Conference Wiki at
          > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >
        • Julian Bond
          ... Ignore the actual protocol for a moment. Site alpha.com validates with Site bravo.com. Site Alpha knows that UserID= foo + Password= bar +
          Message 4 of 16 , Sep 23, 2003
          View Source
          • 0 Attachment
            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.

            --
            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
          • Daniel Harris
            Funny, I posted very a similar idea to KendraWiki 2 weeks ago. Collective conscious or what?! ;-)
            Message 5 of 16 , Sep 24, 2003
            View Source
            • 0 Attachment
              Funny, I posted very a similar idea to KendraWiki 2 weeks ago.
              Collective conscious or what?! ;-)

              http://www.kendra.org.uk/wiki/wiki.pl?SimpleDistributedAuthentication

              You can also see the ensuing discussion and a implementation suggestion
              from Dave Cridland if you follow the thread from here:

              [kDev] Simple Distributed Authentication and KendraBase Scenarios...
              http://www.kendra.org.uk/lists/archive/k-developers/msg00125.html

              I would suggest having 3 string parameters: ID, URL and password. I'd
              split up the ID and URL for clarity. IDs can sometimes be email
              addresses - so you'd end up with a couple of @'s. And you may have many
              users' websites operating under one domain all with their own
              authentication system cgi in their own directories. If you didn't split
              them up then you could end up with:

              Username: daniel@...@.../users/daniel/

              Which, I guess, is still parse-able though.

              Anyway, love the idea. Kendra Foundation would definitely be into
              supporting it. This is exactly what we want in KendraBase: each user
              with their own semantic space that they can share with other
              websites/applications. Whether this 'space' is hosted on a shared
              domain, their own domain or a local P2P application should make no
              difference.

              By the way, I found my developer for KendraBase. Hired Neil Harris, the
              guy that built Sohonet, a few weeks ago. Will keep you all posted.
              Thanks to those who showed interest.

              Cheers Daniel

              On Tuesday, September 23, 2003, at 10:15 am, Julian Bond wrote:
              > Here's a proposal for a low tech, de-centralized, remote authentication
              > system with profile management. It's aimed at all those low security
              > situations where you need to login to a website but don't want to go
              > through the hassle of creating an authenticated profile.
            • 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 6 of 16 , Sep 24, 2003
              View Source
              • 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 7 of 16 , Sep 24, 2003
                View Source
                • 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 8 of 16 , Sep 24, 2003
                  View Source
                  • 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 9 of 16 , Sep 24, 2003
                    View Source
                    • 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 10 of 16 , Sep 24, 2003
                      View Source
                      • 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 11 of 16 , Sep 24, 2003
                        View Source
                        • 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 12 of 16 , Sep 24, 2003
                          View Source
                          • 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 13 of 16 , Sep 24, 2003
                            View Source
                            • 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 14 of 16 , Sep 24, 2003
                              View Source
                              • 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 15 of 16 , Sep 24, 2003
                                View Source
                                • 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 16 of 16 , Oct 3, 2003
                                  View Source
                                  • 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.