Passport at the forefront of .Net

The first sighting most of us make of Microsoft's vast .NET initiative will probably be via Microsoft consumer services like Passport, which .NET will offer as a programming interface so it can be built into applications. Should we be excited - or unnerved? IDGNet's Russell Brown quizzes Passport marketing manager Jigish Avalani.

As group manager for Passport Marketing, Jigish Avalani is responsible for selling Microsoft's vision of a new range of software services to consumers.

Passport, Microsoft's "digital identity management service", is the sharp end of the company's .NET strategy and it's the first part of that strategy that most of us will encounter. Avalani was in New Zealand last week to pitch the concept to local merchants. IDGNet's Russell Brown asked him how Microsoft had managed to quickly woo major US e-tailers into taking up .NET last October.

Avalani: We were able to prove to merchants that it would be valuable to them. And even though we launched as major companies had locked down their systems in advance of Y2K and the holiday shopping season, we had 23 dot-coms live with their implementation in time for the holiday shopping season. It was a phenomenal experience for them and us.

Basically the merchants saw some great numbers for conversion rates and a way to eliminate the problem of shopping cart abandonment. It was a great value proposition for them.

How much is the process by which Passport is integrated going to change as .NET rolls out over the next few years? At the moment, for instance, the sequence of events for someone who goes to sign up to Hotmail is that they are redirected over to Passport.

It's already .NET strategy. Because it's a subscription service, consumers go to the consumer experience site, whether it's a portal or an application. They sign in and the authentication piece is a service run by Passport. So behind the scenes the site does the URL redirect, authenticates and returns.

After that any additional experience and elements is between the site and the consumer directly. That's the key premise for being able to provide and provision the software as a service model.

So consumers will always be aware that Passport's in the loop?

Passport is their digital identity that opens the door. For digital wallets it'll be consumers using their wallet for the purchase transaction, so consumers are always under control. They see the Passport express purchase button and they go and use that. The consumer interaction is always with the business - whether it's a shopping experience with barnesandnoble.com or whatever.

At the point of checkout, you'll probably be presented with some sort of checkout page. In the traditional model you have something like a Buy button and when you clock on it it'll take you to a page with a form that you'll fill out with your name and address and everything.

What we ask merchants to do is integrate a Passport Express Purchase button on their site. And that actually redirects it off to their wallet Web server on the Passport.com site. The page there will have the same style sheet as the merchant has - same backgrounds and that sort of thing - so the merchant has the ability to maintain branding. To the consumer, it feels like their page.

Privacy is presumably the big question you have to answer over this.

It designed in such a way that consumers' privacy is maintained, obviously from our point of view, but contractually as well. Merchants contractually are bound to a very strong privacy statement that says that they will not abuse any of the consumer data that they get from Passport.

How do I determine which parts of my information goes to which merchant? There may be stuff I don't want some third-party merchants to know.

If you click on the Passport Express Purchase button for it means you're authorising the merchant to use your Passport wallet for this particular transaction. But it's not your entire wallet - that's the beauty of it. I have multiple payment types and multiple shipping addresses and I'm only using one of those for this particular transaction. So only the information that I chose is transmitted back to the merchant - that's all the merchant gets from me.

Say I'm logged into Passport and I arrive at a participating merchant site. What does it know about me on arrival?

All we capture as a core profile is country, state and zip code - and that's it. It's intentionally lightweight. Optionally, if the consumer decides to opt in, is first name, email name, age and gender. If you sign into a site with your Passport ID, we do the authentication and send and transmit that core profile with a unique Passport identifier, or GUID, which is 128-bit encrypted.

The merchants use that to key into their own database. But after I sign in, Passport's out of the way. We just provided the authentication piece - the merchant outsourced their password management, which is extremely valuable to them. And if consumers have too many IDs and passwords, they're prone to forget them, so you have to have some kind of password management and staff a support centre, things like that. Gartner recently put the cost as 70 cents per customer per year, which is a lot of money.

The thing that strikes me about exposing services as APIs is that it puts Microsoft in a position where it can break an application by withdrawing or changing the service.

It's not necessarily that it would allow Microsoft to break services, but that it imposes a strong requirement on us, as a software service, to be able to do just in time development at the back, and be able to maintain the flexibility and the availability of the APIs and services to the merchants.

You're componentising not only the application on the platform but the service itself. That's one of the reasons why Passport is a suite of e-commerce service: digital sign-in, digital identity and the wallet piece. So even though the wallet's associated with every ID it's just blank unless the consumer explicitly goes in and adds things and uses it during the purchase transaction.

From the business standpoint, the core profile is relatively straightforward - and if we change anything it's actually going to be enhancing that to provide additional levels of flexibility and service. You add onto it rather than messing with it. So in a sense it imposes on us the requirement to make it highly available, reliable and scaleable.

How does the Passport pricing model work for merchants?

In the dot-com world, if your genericise it, there are two business models. One that says everything for free - but mine the heck out of consumer data. I won't make any judgement calls on that - but we all know the problems with that. And we don't believe in it. The other business model says, don't mine as much consumer data but take a percentage of the transaction fee.

With Passport we decided to consciously not go with either of those business models because what we primarily believe in is consumer privacy and security - and because we're a software company. Our core competency is software. But instead of packaged software with a one-time licence fee, this is an annual service agreement. So with passport, our service fees are tiered based on average unique users

Keep in mind that this is a server-based solution, so it facilitates the anytime-anyplace-any-device. Signing out happens multiple ways - either by the consumer killing the browser or by explicitly clicking on the passport sign-out button.

Or the merchant business has the opportunity to do that. In some business, especially high-end financial transaction business, they may want to sign off customers after each transaction or reset to say they need to be authenticated again for any activity.

In the wallet itself it's much more sophisticated. The consumer can say, "after each purchase and transaction, sign me out", if they wish to. Consumers are always in control and secondly business is in control as well.

So when can we expect to see Passport roll out locally?

That's the reason I'm here - to set up our regional office, talk to the right set of merchants.

Passport is leading out .NET in terms of what consumers are going to interact with. What's next?

A couple of things. Passport should be viewed more as an overall digital identity management service. As a service it facilitates additional consumer scenarios. One of those is obviously the shopping.

But as a pure digital identity it can facilitate things like location-based services. Because it is a pure server-based service, mobile and wireless and cellphone carriers can use it to be able to associate with your cellphone.

So whenever I'm on the Web at my PC or an Internet kiosk I can set a whole bunch of additional profiles - say I'm going on vacation somewhere, and say there are a couple of things I'm interested in being notified about.

So I just set that up on my mobile phone carrier's Web site and when I'm out there, I just turn on my cellphone. Ninety percent of the time a cellphone carrier knows roughly where you are and that helps them facilitate in mapping it back the Passport services. So it's a notification engine if you may - regardless of which device you use and where you are. I can also be linked in with things like [Microsoft] Messenger - which becomes a consumer experience off the overall notification engine.

And wouldn't it be nice if I'm in New Zealand and I get notified about something via my cellphone - and I can actually act on it rather than just having an information device? And it shouldn't matter to my stockbroker or anyone else where exactly I am so long as I'm authenticated as who I am - which is where Passport comes in.

I, as a consumer, demand that from the business - in this case the application provider, the brokerage account, which needs to turn around and practically meet my needs, so that they can retain me. Because guess what? If they don't, their competition is going to turn around and provide that.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place

[]