Posts from Web service

Identity, Authentication, and Provisioning Them Online

Christina jotted down some thoughts on indentity on a flight to SF and I read them this morning. In her post, she references Ev's excellent post on the same topic from a while back. So I went on a bike ride as the sun rose over the east end of long island and thought a bit about all of this.

Before going on, I'd like to emphasize that these thoughts are mine and mine only. Nobody has seen this post before publishing other than me, including my partners and our portfolio companies. It does not represent the opinions of any company I and/or our firm are involved in.

I don't have a single online identity. I have many. They are rich, representative, and different from each other.

@fredwilson (tumblr)

And many many more.

I apologize to all the services out there (in and out of our portfolio) that I left off this list.

I believe that OpenID is on the right track. In the OpenID scheme:

The term OpenID may also refer to an ID as specified in the OpenID standard; these IDs take the form of a unique URL, and are managed by some 'OpenID provider' that handles authentication.

OpenID has two important concepts in it. The first is identity. The second is authentication. The two are totally different but they have become comingled on the web because the leading third party authentication services, Facebook, Twitter, and Google, are combining the two in interesting ways.

When you build a web and/or mobile app and you want to make it easy for the user to share data between your app and one of these big three web services, you provide for one button authentication to them. Everyone who uses the web and mobile apps is now familiar with "login with Facebook", "login with Twitter" or "login with Google". We use them all the time. They make things easier on us.

These authentication services provide some notion of identity as well. But only your identity in their service. Not your entire identity.

So back to OpenID for a minute. I really like the idea that a URL can be an ID. But I don't like the idea that one URL is your ID. I like the idea that a list of URLs makes up your ID. I started my list at the beginning of this post. It is not complete by any means, but it is a good start.

So what I want is a layer that sits on top of all these services, aggregates up all of my URLs (identities), and then provides authentication in the same way that Facebook, Twitter, and Google do today.

And I'd like this layer to be able to provision to web services exactly the same data that you can get (and give) by authenticating directly with the social platforms. And, of course, I'd like to control what data gets provisioned to what apps.

Many have taken a stab at this over the past few years. It is a big opportunity and a big problem. But none (including OpenID) have gotten the kind of traction that Facebook, Twitter, and Google have. I believe there are several reasons for that. First, you need a brand that users recognize (and trust??) to be able to do this. Second, the authentication experience needs to be simple, easy, and not geeky in the least. And third, you need the cooperation of Facebook, Twitter, and Google to do this well and it is in their interests to be the providers of authentication and identity on the Internet so getting that cooperation has been tough.

The good news is it is becoming increasingly clear that no one web service will control our identity online. The success of Google+, Tumblr, Foursquare, Instagram, etc, etc in the past year has shown that users want more social platforms in their lives, not less. Or at least that some users want different social platforms than the ones that have been leading the way for the past decade.

So maybe the big three can get together and cooperate on building this authentication layer on top of their services and promoting is as an indepedent way to authenticate and provision identity and related data to web and mobile services. I'd love to see that happen and I suspect the Internet would be a better place because of it.


Are Real Names Required For Real Socializing?

Over the weeekend my friend Jeff Jarvis and I had a twebate about this topic. You can see it in action on storify thanks to David Connell.

I'm all for real names if people want to use them. I use "fredwilson" on every web service I can and that is almost all of them. It's a vanity thing for me more than anything else. I want to get to the service early enough that I can grab that handle.

But not everyone wants to use a real name. There are all sorts of reasons for that. This post on the EFF blog, which kicked off the twebate between me and Jeff, lists a bunch of them.

This community is a perfect example of the value of anonymity. Kid Mercury, FAKE GRIMLOCK, Prokofy, JLM, etc, etc. They are some of the most engaged community members. We love them (at least I do), and I could care less who they are in real life. What I care about are their ideas, their voice, their participation, and their energy. If anonymity brings that out in some, then bring it on.

David Weinberger left a comment on Caterina Fake's blog that I love and reblogged on Tumblr last week:

In our culture, we’re suspicious of strangers. They’re a threat. They lurk in shadows. On the Web, however, strangers are the source of everything worthwhile. Strangers and their utterances are the stuff of the Web. They are what give the Web its matter, its shape, its value. Rather than hiding in our tents and declaring our world to exist of the other tents near us — preferably with a nice tall wall around us — the Web explicitly is a world only because of the presence of so many strangers.

The desire to clean up the web, civilize it, and sterlize it pisses me off. I hate it. The Zuckerbergs can run a sterile community on the web if they want. That's just fine. But to suggest that real names is the source of their success it to learn the wrong lessons from Facebook.

Facebook is successful because they bring structure (phototags are the best example) and order (the newsfeed) to the social web. The requirement to use real names is a weakness not a strength of the service.

But of course not everyone will agree with me on this. Jeff doesn't. We ended our twebate with an agreement to take this debate to the stage. I hope we can do that this fall somewhere in NYC. I'm hoping for some sketchy dicey neighborhood to be honest. This is an important debate as it impacts the way social services are designed and executed. So let's have it.


Syncing Up Your Credit Cards

Last week I posted about a service called BillGuard. BillGuard scans your credit card bills for questionable transactions so you don’t have to. It’s a great service. One of the things you do when you set up BillGuard is you connect your credit card(s) to the BillGuard web service. It’s straightforward and easy. Once you do that, the magic happens.

I did the same thing yesterday. I connected my Foursquare with my American Express card. Once you do that, when you check in at places that have Foursquare specials, you get automatic credit when you pay with American Express. Foursquare calls this “load to card“. You can do it here.

I really like the idea of syncing my credit cards with web services. I’m not so into the social value of sharing my transactions with everyone (where Blippy started), but I am very much into the personal value of leveraging my transaction history into various web services I use frequently. And I am also very into the idea of getting the benefit of offers and deals automatically credited to me via my credit card account.

I think we have just scratched the surface of what is possible when you sync up your transaction activity with other services in your life. There is great opportunity in this idea.

Enhanced by Zemanta


I use a lot of music web services but I don't like to invest in this sector. Nonetheless, it's an area that I spend a lot of time thinking about. I've written endlessly on this blog about the music web services I use, why I use them, and where I think the music web is going.

The most interesting music web service to me has been audioscrobbler (aka I'm not all that interested in as a social network, but I am obsessed with it's value as a data asset. I report all my music listens to via the audioscrobbler technology and it has built a deep data asset on my musical listening habits (and therefore musical taste). Since October 2005, I've recorded 60,168 song listens with audioscrobbler. That's roughly 40 listens per day. Sounds like a lot, right? Well we listen to music all the time in our house and we've had audioscrobbler on our Sonos for the past year or so.

There are a bunch of music web services I use that leverage the power of the audioscrobbler data via the api. So I show up at a new music web service and it can instantly know what I like to listen to by simply asking me for my user name and password. It's like magic. I love it.

The developer of audioscrobbler is a guy named Richard Jones (aka RJ) who built it while he was in college. He merged it into and became the CTO.

Well RJ is back to building interesting new web music stuff and his new thing is called Playdar. And like audioscrobbler, I think this could be a powerful foundational platform technology for the music web.

Playdar is a "music content resolver" platform. You put the Playdar software on all the machines you have with music on them. And then Playdar makes it so that you can play your music via the web whenever and wherever you want. This is not the first effort to do this sort of thing, but it is the first time this has been done as an open source platform.

This is an important distinction. Like audioscrobber was the foundational technology for and many other music web services, Playdar can and will be the same.

The Playdar ecosystem is just getting going but there are already some interesting demos. I like Toby Padilla's Playgrub which turns web pages into playlists. I also like James Wheare's Playlick which turns accounts into playlists.

Open platforms and ecosystems are powerful and the music web needs more of them. I am excited to see where Playdar goes. I'll be following it closely and if you are into web music, you should too.

Reblog this post [with Zemanta]
#My Music#Web/Tech

Two New Ways To Find A Better Place To Stay On The Road

My partner Albert said this a week or two ago on his blog:

When people ask me whether investing in web services is a long-term opportunity, I often say that “we ain’t seen nothing yet.”

I was reminded of that when I went to the web to find a hotel to stay in Miami when I am down there for Future Of Web Apps in February.

In the past, I'd have tried TripAdvisor or maybe even Google. But just in the past few months, there are two really great new ways to do this.

The first is Oyster, a web service dedicated to honest and excellent hotel reviews. They literally send out a person to stay in the hotel for a few days, take their own undoctored photos, and present in a clear and concise format. Here's their page on Miami hotels, and here's a page on Tides in South Beach, which they say has awesome rooms.

Oyster's strength, personally crafted reviews, is also its weakness because they only have reviews right now for certain destinations. I suspect it will take them a few years to be totally comprehensive. However, because so much hotel seeking traffic comes from Google, they can be a great service for people who start their hotel searches at Google. If you see an Oyster result in Google, you should absolutely click on it.

The other way to do it is Hunch. Instead of hiring "experts" to go out and review the hotels, Hunch takes an approach that is more like wikipedia. They crowdsource questions and answers from thousands of "contributors" and then package them up in easy question and answer sessions that lead you to the "right answer".

Try this hotels in miami page and see how it works. You'll notice that Hunch doesn't give you just one answer. It gives you a "best" answer and three other suggestions. I've found that not only do I get good advice from Hunch, it also helps me quickly understand the tradeoffs I am making in hotel decisions.

Of course, there's a natural partnership between Hunch and Oyster around hotels. Hunch is good at framing the decision and giving you a short list to consider. Oyster is great for digging into the specifics of the hotel to get to the final choice.

Since both companies are in NYC and are part of the great startup culture we've got going here, I bet that's not too hard to make happen.

Reblog this post [with Zemanta]
#Blogging On The Road#Web/Tech