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

Re: [decentralization] Re: MSN Messenger

Expand Messages
  • Rahul Dave
    ... Maybe I misunderstood microsofts original purpose with passport, but I thought the idea was single sign on. This means that as a third party web site, I
    Message 1 of 25 , Jul 10, 2001
    View Source
    • 0 Attachment
      >
      > But for something like sign-in, where all you want to do is authenticate, and
      > where existing mechanisms like web passwords and cookies are utterly feeble but
      > still work fine, trusted third parties don't add anything but overhead.
      Maybe I misunderstood microsofts original purpose with passport, but I thought the
      idea was single sign on. This means that as a third party web site, I replace my
      login page with a 'click to log in with passport' icon.

      So, there is no username and password for finesweets.com anymore. The user does not
      have to store such a pair for that site in his profile. The only place the user logs on to
      is passport, and passport tells finesweets, that guy's kosher. Finesweets checks that that statement
      is indeed made by passport *NOT* not that the users credentials are kosher.
      So its outsourcing of one part of finesweets database.

      Seen from this perspective, the third party is needed, as the third party is the outsourcee for one
      standard part of the ecommerce process. While MS would have us all use passport, I'm guessing that
      different 'domains' or 'realms' will form, such as 'merchants affiliated with AOL',
      'merchants for the immediate breakup of microsoft'(merchants associated with sun, ie :-)), 'msn merchants',
      'ibm','me and my dumb friends','archie highschool', etc and each will have one 'third party'
      for that domain (nothing precluding the third party from degenerately being one of the other 2 parties).

      And yes, compared to a local database lookup, it definitely adds overhead.
      But there is no reason that a web store ought to even need a programmer to be selling stuff, so
      for the tradeoff of overhead, the idea is to have put-togetherable components. Ofcourse, all stores like to
      track their customers, so there also needs to be a way to get the customers profile as a service, idependent of
      the authentication. I believe this is one of the hailstorm services.

      BTW, besides the original set of interviews, I found some nitty gritty technical stuff
      on hailstorm at:
      http://msdn.microsoft.com/theshow/Episode014/default.asp
      Rahul

      >
      > > I can't really think of any interactions that would require such a trusted
      > > third party. We can see that IM has taken off without it. B2C commerce
      > > doesn't require anything more than credit cards. In B2B situations, we can
      > > imagine that each company's CA could cross-certify with its partners' CAs,
      > > although I admit I don't have experience in that area.
      > >
      > > Hmm, I just realized that Todd Boyle hasn't chimed in lately with his "all
      > > True Names all the time" spiel.
      > >
      > > Wesley Felter - wesley@... - http://felter.org/wesley/
      > >
      > >
      > > To unsubscribe from this group, send an email to:
      > > decentralization-unsubscribe@egroups.com
      > >
      > >
      > >
      > > 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
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Lucas Gonze
      ... http://biz.yahoo.com/prnews/010710/sftu089.html Microsoft and VeriSign Announce .NET Alliance Companies Will Work Together to Expand Trust and
      Message 2 of 25 , Jul 11, 2001
      View Source
      • 0 Attachment
        > I have this feeling though that from a business model
        > perspective, we
        > *will* land up with few big 'kerberos servers', at places like MSN,
        > AOL, etc...

        http://biz.yahoo.com/prnews/010710/sftu089.html

        Microsoft and VeriSign Announce .NET Alliance

        Companies Will Work Together to Expand Trust and Authentication Services In
        .NET; VeriSign to Integrate Microsoft .NET Technologies and Deploy Windows 2000
        Servers
      • Lucas Gonze
        Whether the goal is single sign-on depends on perspective. For users the goal is to stop having to set up and remember a username/password for every site. For
        Message 3 of 25 , Jul 11, 2001
        View Source
        • 0 Attachment
          Whether the goal is single sign-on depends on perspective. For users the goal
          is to stop having to set up and remember a username/password for every site.
          For the third party site the goal is to reduce the need for coder time to set up
          and maintain a user membership system. With Passport the goal is to have single
          sign on, in order to provide value-added services like delivery data, and to
          correlate user data across sites.

          Out of the above, these requirements can be met with an ID that is stored on the
          local machine:
          * stop having to set up and remember a username/password for every site
          * reduce the need for coder time to set up and maintain a user membership system
          * to provide value-added services like delivery data

          And these requirements need a single sign-on:
          * correlate user data across sites

          If the ID is stored on the local machine, local software needs to be able to
          interact with the remote site to provide user data. EG the 'local kerberos'
          daemon. I don't believe that is a larger technical change for third party sites
          and users than global-scale kerberos integration.

          - Lucas
        • Wesley Felter
          ... I think you re using a different definition of SSO from mine (and probably others ). I define SSO as only having to type a username/password once. So
          Message 4 of 25 , Jul 11, 2001
          View Source
          • 0 Attachment
            On Wed, 11 Jul 2001, Lucas Gonze wrote:

            > Out of the above, these requirements can be met with an ID that is stored on the
            > local machine:
            > * stop having to set up and remember a username/password for every site
            > * reduce the need for coder time to set up and maintain a user membership system
            > * to provide value-added services like delivery data
            >
            > And these requirements need a single sign-on:
            > * correlate user data across sites

            I think you're using a different definition of SSO from mine (and probably
            others'). I define SSO as only having to type a username/password once. So
            Apple's keychain and the "remember this information" checkbox in most
            browsers already meets the definition of SSO, but those mechanisms don't
            allow user data to be correlated across sites.

            In addition to SSO, Passport provides a single global identity; while it's
            useful in some circumstances I don't consider it necessary for SSO.

            > If the ID is stored on the local machine, local software needs to be able to
            > interact with the remote site to provide user data. EG the 'local kerberos'
            > daemon. I don't believe that is a larger technical change for third party sites
            > and users than global-scale kerberos integration.

            If you're going to run some local software, might as well use SSL client
            certificates (probably self-signed). Dave Winer would probably never go
            for it, though, due to the complexity.

            Wesley Felter - wesley@... - http://felter.org/wesley/
          • Lucas Gonze
            ... I was thinking of single sign-on as being equivalent to a single global identity, but now that you mention it, anything that doesn t require the user to
            Message 5 of 25 , Jul 11, 2001
            View Source
            • 0 Attachment
              > I think you're using a different definition of SSO from mine (and probably
              > others'). I define SSO as only having to type a username/password once. So
              > Apple's keychain and the "remember this information" checkbox in most
              > browsers already meets the definition of SSO, but those mechanisms don't
              > allow user data to be correlated across sites.
              >
              > In addition to SSO, Passport provides a single global identity; while it's
              > useful in some circumstances I don't consider it necessary for SSO.

              I was thinking of single sign-on as being equivalent to a single global
              identity, but now that you mention it, anything that doesn't require the user to
              type their username/password for every site qualifies.

              So I have to ask again, what is the value to users in having someone sponsor
              their identity?

              There is an advantage to common namespace pools, which is scoping. That is,
              "job blow" means nothing without a scope qualifier. Passport allows for a
              passport:joeblow concept. Go to passport, which is well-known, then look up the
              user. I wonder what the limitations are on decentralized alternatives? If,
              rather than sponsor_organization:name, you have lookup_type:name, what problems
              does that create? justified fear, uncertainty, and doubt about whether the
              lookup would fail for technical reasons?

              - Lucas
            • Rahul Dave
              I tend to have one additional requirement for SS0: zero registration, the corollary in a sense of correlated data. Now there is nothing which says this needs
              Message 6 of 25 , Jul 11, 2001
              View Source
              • 0 Attachment
                I tend to have one additional requirement for SS0: zero registration, the
                corollary in a sense of correlated data. Now there is nothing which says
                this needs to come from passport, it could come from your own desktop
                server. For 3rd party verifiability, it could be a cert, though this
                puts a crypto capability requirement on the merchant. But in principle,
                desktop server is fine.

                Ofcourse firewalls means that such a profile/kerberos server
                may be wanted by an org which could answer to such queries by having
                requests on the http or whatever port redirected to this machine..
                I got this from you:
                >
                >
                > I was thinking of single sign-on as being equivalent to a single global
                > identity, but now that you mention it, anything that doesn't require the user to
                > type their username/password for every site qualifies.
                >
                > So I have to ask again, what is the value to users in having someone sponsor
                > their identity?
                verifiability, and the nature of the identity: "this identity certifies that
                rahul is the class fool for class 123675 and is authorized to call eat methods
                on potato objects"
                >
                > There is an advantage to common namespace pools, which is scoping. That is,
                > "job blow" means nothing without a scope qualifier. Passport allows for a
                > passport:joeblow concept. Go to passport, which is well-known, then look up the
                > user. I wonder what the limitations are on decentralized alternatives? If,
                > rather than sponsor_organization:name, you have lookup_type:name, what problems
                > does that create? justified fear, uncertainty, and doubt about whether the
                > lookup would fail for technical reasons?
                >
                > - Lucas
                >
                >
                > To unsubscribe from this group, send an email to:
                > decentralization-unsubscribe@egroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
              • Wesley Felter
                ... I would argue that there is none. ... We already have DNS for this. If you pay $10/year, you can get a domain (which can all-too-easily taken away from
                Message 7 of 25 , Jul 11, 2001
                View Source
                • 0 Attachment
                  On Wed, 11 Jul 2001, Lucas Gonze wrote:

                  > So I have to ask again, what is the value to users in having someone sponsor
                  > their identity?

                  I would argue that there is none.

                  > There is an advantage to common namespace pools, which is scoping. That is,
                  > "job blow" means nothing without a scope qualifier. Passport allows for a
                  > passport:joeblow concept. Go to passport, which is well-known, then look up the
                  > user.

                  We already have DNS for this. If you pay $10/year, you can get a domain
                  (which can all-too-easily taken away from you, but all the non-DNS systems
                  seem even worse), point the domain at your computer, and you're done. If
                  you don't have a good enough connection, then sign up for identity service
                  and point your DNS at that. If your identity service provider tries to
                  shaft you, just sign up for a different one and update your DNS to point
                  at it. Just make sure that *you* are the administrative contact on your
                  domain.

                  > I wonder what the limitations are on decentralized alternatives? If,
                  > rather than sponsor_organization:name, you have lookup_type:name, what problems
                  > does that create? justified fear, uncertainty, and doubt about whether the
                  > lookup would fail for technical reasons?

                  Raph Levien is working on this for his PhD; he doesn't have the problem
                  completely solved, but it's looking good.

                  Wesley Felter - wesley@... - http://felter.org/wesley/
                Your message has been successfully submitted and would be delivered to recipients shortly.