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

Decentralized single sign on

Expand Messages
  • Julian Bond
    http://lid.netmesh.org/ Comments? An Identity server for everyone? -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster:
    Message 1 of 11 , Jan 5, 2005
    • 0 Attachment
      http://lid.netmesh.org/

      Comments? An Identity server for everyone?

      --
      Julian Bond Email&MSM: julian.bond at voidstar.com
      Webmaster: http://www.ecademy.com/
      Personal WebLog: http://www.voidstar.com/
      M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
      S: callto://julian.bond/
    • lucas_gonze
      ... Quoting from the site: ... How do I get my LID digital identity? If you have control over any URL, such as your home page, you already have a LID digital
      Message 2 of 11 , Jan 5, 2005
      • 0 Attachment
        --- In decentralization@yahoogroups.com, Julian Bond
        <julian_bond@v...> wrote:
        > http://lid.netmesh.org/
        >
        > Comments? An Identity server for everyone?

        Quoting from the site:
        ...
        How do I get my LID digital identity? If you have control over any
        URL, such as your home page, you already have a LID digital identity.
        Now you only need to install a simple Perl script at that URL, and you
        are LID-enabled.

        Can I use any URL as my LID digital identity? Yes, if you can run a
        CGI script at that URL.
        ...

        Fantastic -- using URLs as the basis of identity is, as far as I can
        tell, the only way to do it. And this solution is CGI-based, which
        gives it beautiful simplicity.

        - Lucas
      • Johannes Ernst
        ... Thanks for the flowers, Lucas. Yes, LID is all about simplicity: Why not use the world s most successful electronic identifier, the URL, to identify people
        Message 3 of 11 , Jan 5, 2005
        • 0 Attachment
          On Jan 5, 2005, at 13:42, lucas_gonze wrote:
          > Fantastic -- using URLs as the basis of identity is, as far as I can
          > tell, the only way to do it. And this solution is CGI-based, which
          > gives it beautiful simplicity.
          >
          > - Lucas

          Thanks for the flowers, Lucas. Yes, LID is all about simplicity: Why
          not use the world's most successful electronic identifier, the URL, to
          identify people as well? And:

          You can use your blog's URL as your digital ID. Very natural ... e.g.

          http://netmesh.info/jernst -- my LID digital ID, and also URL to my
          blog
          http://netmesh.info/jernst?xpath=/VCARD -- my always up-to-date VCard
          for human consumption (public records only)
          http://netmesh.info/jernst?xpath=/VCARD&action=text/xml -- my always
          up-to-date VCard for machine consumption (public records only)

          Same queries for every LID URL, which allows me to put a very simple
          signature in my e-mails and on biz cards (see below).

          And: by specifying your own LID URL as part of the query (+credentials
          if needed) you can obtain more information than others, depending on
          what rights I have assigned to you: true ownership of identity here
          with some social networking features.

          http://netmesh.info/jernst?help=help -- summary / example page about
          what one can do with my LID URL.
          http://lid.netmesh.org/ -- docs, code and on-line examples etc. as
          Julian pointed out (thanks!)



          Johannes Ernst
        • Julien Couvreur
          Could you elaborate on why you think URLs are better than PGP keys (or similar certs) as an identity reference? Also, if you have to do two requests to the
          Message 4 of 11 , Jan 5, 2005
          • 0 Attachment
            Could you elaborate on why you think URLs are better than PGP keys (or
            similar certs) as an identity reference?

            Also, if you have to do two requests to the auth server/url anyways,
            why do you need any cryptography? Just use a temporary buffer to store
            challenges.

            Cheers,
            Julien


            Some thinking on auth-by-url solutions:
            http://blog.monstuff.com/archives/000153.html


            On Wed, 05 Jan 2005 21:42:16 -0000, lucas_gonze <lucas@...> wrote:
            >
            >
            > --- In decentralization@yahoogroups.com, Julian Bond
            > <julian_bond@v...> wrote:
            > > http://lid.netmesh.org/
            > >
            > > Comments? An Identity server for everyone?
            >
            > Quoting from the site:
            > ...
            > How do I get my LID digital identity? If you have control over any
            > URL, such as your home page, you already have a LID digital identity.
            > Now you only need to install a simple Perl script at that URL, and you
            > are LID-enabled.
            >
            > Can I use any URL as my LID digital identity? Yes, if you can run a
            > CGI script at that URL.
            > ...
            >
            > Fantastic -- using URLs as the basis of identity is, as far as I can
            > tell, the only way to do it. And this solution is CGI-based, which
            > gives it beautiful simplicity.
            >
            > - Lucas
            >
            >
            > Announce or discover P2P conferences on the P2P Conference Wiki at
            > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
          • Wes Felter
            ... I don t consider this true SSO, since you have to paste the URL into each new Web site you visit. Decentralized true SSO (by my definition) using
            Message 5 of 11 , Jan 5, 2005
            • 0 Attachment
              On Jan 5, 2005, at 6:25 AM, Julian Bond wrote:

              >
              > http://lid.netmesh.org/
              >
              > Comments? An Identity server for everyone?

              I don't consider this true SSO, since you have to paste the URL into
              each new Web site you visit. Decentralized true SSO (by my definition)
              using unmodified browsers is impossible, however, so LID looks like a
              very good compromise. LID is kind of the dual of SXIP, since SXIP is
              easier to use but centralized. What bothers me is that similar systems
              have been previously proposed (e.g. drupal) and gained no traction.

              Wes Felter - wesley@... - http://felter.org/wesley/
            • Johannes Ernst
              ... The third alternative being URNs and URN-like names like the ones from Identity Commons (=some.name). The fourth being e-mail addresses or the like (we
              Message 6 of 11 , Jan 5, 2005
              • 0 Attachment
                On Jan 5, 2005, at 16:48, Julien Couvreur wrote:

                > Could you elaborate on why you think URLs are better than PGP keys (or
                > similar certs) as an identity reference?

                The third alternative being URNs and URN-like names like the ones from
                Identity Commons (=some.name).
                The fourth being e-mail addresses or the like (we tend to mean http
                when we say "URL" in the LID context)

                URLs are human-readable, human-speakable and can be remembered by
                humans. (like URNs, unlike keys, like e-mail addresses)
                They can be bookmarked. (unlike URNs, unlike keys and only sort of like
                e-mail addresses)
                They can be printed on a business card. (like URNs, unlike keys and
                like e-mail addresses)
                They are actionable by everyone: enter URL into browser and it leads to
                useful information. (unlike URNs, unlike keys, somewhat like e-mail
                addresses)
                80% (wild guess) of the population with access to a computer know what
                they are (unlike URNs, unlike keys, like e-mail addresses)
                They are immediate(ly gratifying) (unlike URNs, unlike keys, unlike
                e-mail addresses)
                They are broadly usable protocol endpoints, e.g. they can be queried
                (unlike URNs, unlike keys, unlike e-mail addresses)

                Note that we provide a LID query (e.g
                http://netmesh.info/jernst?meta=gpg%20-export%20--armor) so a person's
                public key can be easily retrieved.

                > Also, if you have to do two requests to the auth server/url anyways,
                > why do you need any cryptography? Just use a temporary buffer to store
                > challenges.

                You are right, we actually don't "need" cryptography. LID supports an
                open list of authentication schemes (parameter credtype in the
                protocol), of which we currently have defined only one which uses GPG.
                Others are possible that may or may not be more appropriate, depending
                on requirements ...

                Alternatively, there's a "ticket" in the protocol that's passed around
                and that can be verified through a back channel as you point out. But
                as you say, they require a temporary buffer and, although this may
                appear to be a minor point, thus increase the requirements for somebody
                running LID as a simple CGI script. The Perl script we've put on our
                website does not need to write any data whatsoever, which appealed to
                us -- I guess we've had to deal with too many webservers that didn't
                have their suexec configured correctly ;-)
              • Johannes Ernst
                ... How many digital IDs do you expect to have even if technically, one would be enough? We tend to believe it will be N 1, or even N 1, so identity
                Message 7 of 11 , Jan 5, 2005
                • 0 Attachment
                  On Jan 5, 2005, at 19:19, Wes Felter wrote:

                  > I don't consider this true SSO, since you have to paste the URL into
                  > each new Web site you visit. Decentralized true SSO (by my definition)
                  > using unmodified browsers is impossible, however, so LID looks like a
                  > very good compromise.

                  How many digital IDs do you expect to have even if technically, one
                  would be enough?
                  We tend to believe it will be N > 1, or even N >> 1, so identity
                  correlation across the network is much harder that if you had only one
                  (e.g. your ID for day job #1 vs. night job vs. school board vs. medical
                  vs. family etc. etc.)

                  If so, you simply must choose the particular ID you want to use with a
                  party that you encounter the first time. (I'm trying to avoid using the
                  term "persona" because it has all sorts of connotations for all sorts
                  of people ...) The site can store that LID URL in a long-time cookie so
                  it's only a first-time thing.

                  One of our design principles for LID was that you should be able to use
                  N digital IDs hosted by N different service providers, with even the
                  service providers being unable to correlate your IDs if you so desire.
                  Consequently, you need to provide a LID URL the first time you interact
                  with a new party, and software can't (and shouldn't) automate it.

                  Alternatively, as you point out, one could establish a place (e.g. an
                  identity provider) that knows about all of your IDs. This is less
                  secure, at least for the paranoid among us, but even more importably,
                  only slightly more convenient: you still will have to choose the ID you
                  want to use with a new party, although the GUI for doing so might be a
                  group of radio buttons rather than a text field into which you type
                  your LID URL.

                  [Re-reading what you said, my response may be blindingly obvious to you
                  already]

                  > What bothers me is that similar systems
                  > have been previously proposed (e.g. drupal) and gained no traction.

                  That's where we get into the "what's the compelling need for digital
                  identities" discussion.

                  Personally, I don't think it is SSO, the need is simply not big enough
                  to cause the adoption of a completely new technology (LID or otherwise)

                  On the other hand, there's tremendous activity around social computing
                  -- and if you think of it, there is no such thing as social computing
                  without identity. (I wouldn't know who my friends are if I couldn't
                  identify them). That's why LID's first feature was VCard queries with
                  node-level access rights, and its second FOAF queries with node-level
                  access rights, and we have some more ideas under development that take
                  this to the next level.

                  Right now, social computing is stovepipe computing -- and LID could
                  help change that, for the benefit of pretty much everybody. SSO is just
                  one of the must-have features in a much larger package.

                  Thoughts?
                • lucas_gonze
                  ... Interesting problem to bring up. It strikes me that you could be dropped into a DHT where each hop was a redirect and the final stop was your SSO host.
                  Message 8 of 11 , Jan 5, 2005
                  • 0 Attachment
                    --- In decentralization@yahoogroups.com, Wes Felter <wesley@f...> wrote:
                    > On Jan 5, 2005, at 6:25 AM, Julian Bond wrote:
                    >
                    > I don't consider this true SSO, since you have to paste the URL into
                    > each new Web site you visit. Decentralized true SSO (by my definition)
                    > using unmodified browsers is impossible, however, so LID looks like a
                    > very good compromise.

                    Interesting problem to bring up. It strikes me that you could be
                    dropped into a DHT where each hop was a redirect and the final stop
                    was your SSO host.

                    > LID is kind of the dual of SXIP, since SXIP is
                    > easier to use but centralized. What bothers me is that similar systems
                    > have been previously proposed (e.g. drupal) and gained no traction.

                    About adoption, I got interested in this topic because I was working
                    on yet another site auth system and wanted to ease the pain of
                    creating an account. For the user it makes the need to give out an
                    email go away. For web apps, it allows them to not have to write an
                    authentication system, and it makes it less likely that users will go
                    away rather then enter an email. These benefits strike me as concrete
                    enough to make one solution or another take off eventually.

                    Also, my impression is that LID is both simpler and less centralized
                    than either Drupal or Sxip, so it might be that the tech is
                    progressing towards a breakthrough point.

                    - Lucas
                  • Wes Felter
                    ... If a site requires an email address, why would it allow you to use a LID identity with no email address instead? I guess there are several reasons why a
                    Message 9 of 11 , Jan 5, 2005
                    • 0 Attachment
                      On Jan 5, 2005, at 10:30 PM, lucas_gonze wrote:
                      > --- In decentralization@yahoogroups.com, Wes Felter <wesley@f...>
                      > wrote:
                      >
                      >> LID is kind of the dual of SXIP, since SXIP is
                      >> easier to use but centralized. What bothers me is that similar systems
                      >> have been previously proposed (e.g. drupal) and gained no traction.
                      >
                      > About adoption, I got interested in this topic because I was working
                      > on yet another site auth system and wanted to ease the pain of
                      > creating an account. For the user it makes the need to give out an
                      > email go away.

                      If a site requires an email address, why would it allow you to use a
                      LID identity with no email address instead? I guess there are several
                      reasons why a site would require an email address, and each case would
                      have to be analyzed separately. I haven't designed any Web apps lately,
                      so I'm not sure what the cases are.

                      > For web apps, it allows them to not have to write an
                      > authentication system

                      If you want LID you would either have to implement it yourself or use a
                      library. If you're using a local account database, you'd either have to
                      implement it yourself or use a library. I don't see any difference
                      there.

                      > Also, my impression is that LID is both simpler and less centralized
                      > than either Drupal or Sxip, so it might be that the tech is
                      > progressing towards a breakthrough point.

                      At first glance LID is of similar complexity to SXIP; obviously it is
                      less centralized than SXIP.
                      LID is much more complex than Drupal auth, but Drupal has a glaring
                      security problem (all sites see your password). Both LID and Drupal
                      auth are fully decentralized.

                      Wes Felter - wesley@... - http://felter.org/wesley/
                    • lucas_gonze
                      ... The most common reason for the email address is to allow a user to recover a lost password. There are also secondary reasons like blocking spam bots, but
                      Message 10 of 11 , Jan 5, 2005
                      • 0 Attachment
                        --- In decentralization@yahoogroups.com, Wes Felter <wesley@f...> wrote:
                        > If a site requires an email address, why would it allow you to use a
                        > LID identity with no email address instead?

                        The most common reason for the email address is to allow a user to
                        recover a lost password. There are also secondary reasons like
                        blocking spam bots, but these are all fixable without single sign-on.
                        In any SSO system the problem of recovering lost passwords belongs to
                        the identity host, not the web app, so a web app can use an SSO
                        identity without an email.

                        > > For web apps, it allows them to not have to write an
                        > > authentication system
                        >
                        > If you want LID you would either have to implement it yourself or use a
                        > library. If you're using a local account database, you'd either have to
                        > implement it yourself or use a library. I don't see any difference
                        > there.

                        The library for a SSO system doesn't have to maintain the database or
                        any of the user interface for modifying account settings. The result
                        is that quite a lot of code becomes somebody else's problem.

                        > > Also, my impression is that LID is both simpler and less centralized
                        > > than either Drupal or Sxip, so it might be that the tech is
                        > > progressing towards a breakthrough point.
                        >
                        > At first glance LID is of similar complexity to SXIP; obviously it is
                        > less centralized than SXIP.

                        Hm. I really don't know enough about Sxip to compare them at this
                        level of detail, then.

                        > LID is much more complex than Drupal auth, but Drupal has a glaring
                        > security problem (all sites see your password). Both LID and Drupal
                        > auth are fully decentralized.

                        Yeah, I've always written off Drupal auth for that reason -- the
                        security makes no sense to me.

                        - Lucas
                      • Johannes Ernst
                        ... There is also the non-technical reason of sites desiring to send e-mail to registered users. This is how it would work with LID. 1) user signs up with just
                        Message 11 of 11 , Jan 6, 2005
                        • 0 Attachment
                          On Jan 5, 2005, at 22:12, lucas_gonze wrote:

                          > The most common reason for the email address is to allow a user to
                          > recover a lost password...

                          There is also the non-technical reason of sites desiring to send e-mail
                          to registered users. This is how it would work with LID.

                          1) user signs up with just their LID URL, using LID SSO
                          2) site performs query LID?xpath=/VCARD/EMAIL/USERID;action=text/xml
                          3) if site is able to obtain e-mail address, no further action is
                          required and all site e-mail will go to the user's public e-mail
                          address
                          4) if site is unable to obtain e-mail address (because user has not
                          configured public e-mail, or disallows site to obtain e-mail address),
                          site can flash to user next time user visits that site needs / wants
                          e-mail address. If user agrees, user adds a line to their LID
                          configuration at their LID URL site that site is allowed to see e-mail
                          address
                          5) user can monitor when site asks for e-mail address (because it leads
                          to a trackable LID query)

                          => privacy about the same as without LID
                          => more convenient with LID for both site and user
                          => more trackable for the user with LID (which imho is one of the needs
                          underlying a lot of privacy concerns)
                          => more likely to be accurate e-mail address for site (even after user
                          may change e-mail addresses)
                          => supports a whole bunch of new use cases, such as "one-time" e-mail
                          addresses (if user / LID software dynamically changes e-mail address
                          returned), the gradual "opening of the kimono" as the relationship
                          between use and site evolves to include additional information, say
                          shipping address or phone number, all of which will always be
                          up-to-date for site with LID, and all of which user can remove from
                          being seen by site at any time (of course, site can cache information
                          but that's no worse than what we have today)

                          >>> For web apps, it allows them to not have to write an
                          >>> authentication system
                          >>
                          >> If you want LID you would either have to implement it yourself or use
                          >> a
                          >> library. If you're using a local account database, you'd either have
                          >> to
                          >> implement it yourself or use a library. I don't see any difference
                          >> there.
                          >
                          > The library for a SSO system doesn't have to maintain the database or
                          > any of the user interface for modifying account settings. The result
                          > is that quite a lot of code becomes somebody else's problem.

                          For a site to implement LID SSO, you need to have
                          1) a single column in your table for registered users, containing the
                          LID URL of the user (plus columns for whatever user info you may want
                          to cache instead of retrieving from LID URL every time, such as
                          LID?xpath=/VCARD/N/GIVEN -- the user's first name)
                          2) three little pieces of code:
                          a) a redirect to the user's LID with some parameters
                          "?action=sso-approve;target=siteurl", that kind of thing, when the user
                          needs to be SSO'd
                          b) unpack URL args, check against user table, retrieve GPG public
                          key from LID URL, and verify key when action=sso-approved comes in as a
                          redirect from user's LID.
                          c) code that inserts LID URL into user table upon initial
                          registration.

                          As Lucas says, a lot simpler than what you'd have to do without LID.


                          Johannes Ernst
                        Your message has been successfully submitted and would be delivered to recipients shortly.