>Ed,
>
>We started a discussion about Passport in Seattle, but unfortunately, never got to finish it... (I apologize, but that week didn't work out quite the way I had planned, due to some serious deadline preassure...).
>
>Here's why I like MS Passport, and why I think it's at least somewhat safe:
>
>First of all, there is a major misconception about how much information there is available in Passport (and similar services). To establish a Passport account all that's needed is a user name, and a password. The user name is an email address, but it doesn't have to be your real email address. So if one is concerned about security, make up a fake email address, and you are all set.
>
>Also, from a Passport Partner point of view (the sites that allow for Passport Authentication), there is very very little information one can get our of the service. Basically, the PID (Passport ID) is the only piece of significance. This is a unique ID that gets generated and (for security reasons) send in two pieces.
>
>By itself, the PID doesn't tell anything. It simply allows to identify a user in between hits. For a site such as the Universal Thread, this is all that's needed.
>

Markus,

To this point, we concur as to what Passport is, and should be. I've no objection to a common authentication mechanism; I would like some greater cryptographic security, but for all intents and purposes, the PID is a direct descendant of the concept of a SID in the NT operating system. I don't know the internals of the PID transport mechanism, but you're 100% right that as long as the PID is treated strictly as a token and the token is used to securely request permissions and characteristics, then Passport is fine.

My concern stems from the use of a central authority, in this case MS, as an authentication server. It means that by accepting Passport, we agree that MS becomes the arbiter of access to the information referenced by the PID. THis is what I find to be scary; I'm not certain that I'm willing to cede a commercial entity (or in fact, any single entity other than myself or my organization) the right to store and distribute my personal information based on what I perceive as a weak cryptological reference. I haven't studied the internals of the Passport mechanism in detail, but my concerns are twofold, first, the ability of an entity to spoof my identity be interception and replication of my PID to gain access to restricted materials, and second and much more serious, the ability to spoof the identity of a PID consumer to access private detail stored at the central authentication site. I'm frankly disturbed that rather than someone gaining access to -all- my internal detail, the possibility of spoofing the identity of a PID consumer with access to private detail of a class of PID holders exists, so that as an example the address of people who generally are not included in routine mailings originating from the Sales Group of XYZ Corp could have themselves exposed as a result of XYZ Corp gaining access to the identity of a PID consumer authorized to access the information that we've otherwise requested to keep hidden.

This argument has been raging in the cryptographic community for years (at least as far back as when I was actively involved in it) - it's one of the things that argued against a whole class of public key cryptographic systems where the private keys were administered by a central authority. At some point with a central authority serving as the repository of controlled information, the security of that repository comes down to a challenge/response problem, where you can either attempt to emulate the identity of the administrator of a single node's detailed information, or spoof the identity of an authorized consumer of restricted information whose access to pertinant detail is granted by the central authority on the grounds of a contract between the members of the repository and the access authentication authority. In order for the concept to work, we have to cede the authenticator the right to decide who has access to the detail we entrust to the store. It's the underlying existance of the contract that we enter into with the administration authority that scares me, largely because most people who are members of the repository are unaware of the contract they enter into and the consequences that may arise from a breach of the security.

Then there's the issue of the failure of the authentication actor; if MS is designated as the arbiter of access to detail, and suddenly the MS authentication servers sink to the eighth level of Hell, the world of nodes reliant on that administrative authority had better hope we have good connectivity to the underworld. We establish a single or finitely limited point of reference for information we are intrisically reliant on to work at all.

I'm not worried that MS serve as the central authority (after all, they have all my imaginary information from every time I register my software, right?) as much as I am worried about establishing a body to serve as an oversight organization to investigate breaches of the store and mnitor the advance of the technology that serves to secure our private information. I'm certainly aware of the paranoia that might consume the Linux community in having MS administer the details of their love of Brand X. I'm adverse to having MS serve as its own watchdog organization as well; the success of various authorities that are charged with the internal investigation of themselves is not exactly satisfactory, at least within the US. And whether we trust the administrator, or the watchdog of the administrator, it boils down to a level of trust and confidence in the authentication mechanism.

I think that many people, including me, would be more comfortable with a distributed repository, so that I can enter the authentication contract with an entity that I trust (or serve as my own authentication authority if I trust noone.) The decentralization does affect performance of the authentication process, and as a result of increased volume of traffic, exposes the security to additional forms of cryptological attack (increased volume gives a larger result that can be examined by brute force attack, and increases the cost of administration of the protocol as a result of greater bandwidth consumed in carrying the query.)

>In fact, I think it would be awesome if I could sign in to the UT with my passport account. There are few things I hate more than having to set up (and remember) a ton of different user accounts for different sites. Different rules for passwords, user names that are already taken... What a nightmare! In fact, I now find myself not shopping at certain sites, just because I'm tired of the log-in process.
>

Amen.

>A lot of people say "I don't see any advantage in using Passport on my site... it's easier for me to write my own authentication mechanism...". Maybe that's true. But from the user's point of view, there is a big difference! Example: A customer may go to the West Wind site and buy an EPS product. At this point, Rick will notify us about that, and we will add the person to our registration database. However, when that person surfs to our site, there is no way to identify that person. However, if we had the PID of that person, we could identify the customer and allow access to premium content. And best of all: No personal information about the user has been transferred to us. With just the PID, there is nothing melitous we could do, not even spamming the person.
>

As long as I can restrict the PID consumer (West-Wind) from granting another consumer the right to access private detaile exposed to the first PID consumer (EPS), or they identifying entity is made aware of the consequence of exposing the detail, fine. I don't mind the relationship between West-Wind and EPS, but might well be annoyed with a relationship between West-Wind and the Jehovah's Witnesses entity (or kiddie porn sites, or Delphi advocacy sites, or whatever). I don't want to find myself assaulted in the early morning of the day by people out to save my soul because I bought Web Connection!

>
>Of course, there is other information that goes along with Passport. The Wallet for instance. One doesn't have to use the Wallet of course, but I like to. It makes my life much easier. And again, from a partner's point of view, there isn't much one can get out of the Wallet, unless the user gives consent. It's basically a quick way to enter information, rather than keying it in by hand. Therefore: Whether you keyed it in by hand, or whether you get the information from the wallet is all the same.
>

My concern here is where the private information resides; if I have total control over my private detail and make the active decision to propagate the information on a request basis that's fine - Passport in that case is nothing more than a common transport mechanism, perhaps with a cryptologically secure transfer mechanism associated witht he details. If, however, by using Wallet I cede the control to the central authority, or as a result of participating in Wallet I agree to accept a class of PIDs permitting access without my explicit authorization, then I have a problem.

>BTW: The Wallet isn't really Passport anymore. It's really .NET My Wallet. Like all other .NET My Services, they use Passport to link information to a user, but they are really seperate services. It's up to the user to use them, or not.
>

Understood. The content of detail controled by the Passport mechanism is not the same thing as a service that relies on Passport.

>
>Of course, one of the issues that remains is that Microsoft has all information you enter in your account. I personally am very comfortable with that. For one, I know that it's next to impossible to get any information from Microsoft, even if you just want to mail a free magazine. :-) Also, I think there is too much at stake for Microsoft...
>But I understand the concerns. For people who are really concerned, I recommend not to put any information into the account, other than a user name and a password.
>

I address this above.

>BTW: Talking about data privacy concerns. Have you ever taken a look at www.publicdata.com? Scary! That's where we need to start to voice our concerns...
>

No question - the individual is ultimately responsible for the security ofd their identity.

>
>Another issue is password security. In a Windows network, one can set up a policy that forces people to change passwords every so often. Guess how often I change my passwords for the 500 online accounts I created over the past few years. Right! Not even once. Even for my online banking stuff. It's a bad idea not to change it, but it's just too much of a hassle...
>In the not too distant future, users will be able to log on to their workstation with their Passport account. Passport will use Kerberos at that point. Very cool! And all policies will be valid.
>

I like Keberos, in that it's a mechanism that's well-understood and public; I understand the underpinnings of Keberos much better than I understand the underpinnings of the CryptoAPI in this setting.

>
>So the bottom line is that I think there is work that needs to be done on Passport, but overall, it's by far the best solution that's available. I trust MS more with my data, than some small web site that forces me to set up an account and that spams me before I'm done entering my information. (BTW: Spamming is a big no-no for a Passport partner, since one would get kicked off the program before one could email the word "spam" :-)
>

If that's the case, I'm in favor of it, because I don't like SPAM!