apk zenonia 5

Ev Williams wrote a good blog post on identity yesterday, that I suggest you go and read. The odd thing is that he leaves out the publicly articulated thoughts that we use blogs, Twitter and other services to publish as an expression of our identity. Before I get to that, though, I'd like to connect his facets back to the open specs that represent these aspects.

Authentication

Ev mentions OpenID here, and is essentially correct that it is not helpful on its own. It was designed to verify URLs for blog comments. If all you do is use OpenID, you just replace logging into your site with logging into another, adding extra confusion without much benefit. However, once you have a URL for someone, you can then discover further information about them, by examining that URL and its links. Microformats can encode this directly in the webpage, or you can use related links to discover API endpoints for more.

The distinction between Authorization and Authentication is elided by Ev, and in practice OAuth has been winning out over OpenID as it is explicitly an Authorization APi that had Authentication as a side effect. The new OpenID Connect proposals try to remedy both these failing by using OAuth and by standardizing on how to list other endpoints.

Representation

Here Ev is looking for what is commonly called profile information. We have some mature standards for this - vCard is widely used by email clients, and is currently going through another standardization round to add modern features. The hCard microformat gives a simple way to embed profiles in web pages. Also, the rel="me" part of XFN makes it straightforward to link web pages together that represent different aspects fo your public representation. This is supported by Facebook, Twitter and Google, but sadly not by about.me whom Ev praises.

If you want a general data format for profile data, Portable Contacts is what you need.

Communication

Ev's emphasis on email addresses here illustrates the problem with them; they are primarily write-only; though we persist in using them for log-in IDs, they are not readily discoverable. The WebFinger spec gives a way round this - a way to go from an email to endpoints for other readable identity standards. Other communication standards have piggy-backed on email address, such as Jabber and Wave.

Personalization

This hints at the glaring gap in Ev's model, the expression of personal taste and preference. This is commonly done by reviewing, and we have the hReview microformat to express that, but it can also be useful just to track a history of media played or places visited to derive preferences over time. Here Activity Streams are an obvious fit, and it would be good to map such proprietary formats as Amazon purchases, Last.fm scrobbles, iTunes played songs and so on into a common format to derive this.

One model we can use for this is tagging - associating keywords with things. Many feed specs have tagging built in, and the rel="tag" microformat is a way of indicating these publicly.

Reputation

As Ev says, this is problematic, and also often highly contextual; I may trust someone's advice on restaurants without listening to them about which programming language to use. Reputation and trust are subtle, deeply human and very hard to model. The best answer here may be to rely on the power of faces and following; if we attach the face of someone we know to their public statements, we can decide for ourselves how much weight to give them.

Which brings me back to my opening point. When we decide who to pay attention to online, we tend to rely on what they say; if you get an @ reply on twitter, clicking on that person's name to see their most recent comments is hugely useful in deciding how much attention to pay to them. Similarly, the history of public blog posts, or their reviews of movies, music, books or restaurants arre other reasons we may follow them, and our identity is most strongly formed from the stories we tell and retell about ourselves. Feeds, whether in Atom, RSS or hAtom, and Activity Streams give rich representation of our thought, opinions and actions.

Whom we choose to associate with or follow is also an expression of our identity, and a useful signal when deciding how much attention to pay to someone, and XFN and Portable Contacts are both usefule in discovering these connections.

Dare Obasanjo also responded to Ev's Identity post, and added in payment as well as the friends as missed aspects. I'd love to discuss this further with both Ev and Dare at the Internet Identity Workshop next month, which is where many of the specs mentioned above were conceived and agreed. Maybe Ev can bring some others from Twitter with him too; their past contributions to OAuth were highly useful and there is plenty more to get our teeth into, as Ev's post shows.

The online social landscape today sort of feels to me like search did in 1999. It’s a mess, but we don’t complain much about it because we don’t know there’s a better way.

Everything is decentralized, and no one is working to centralize stuff. I’ve got photos on Flickr, Posterous and Facebook (and even a few on MySpace), reviews on Yelp (but movie reviews on Flixster), location on Foursquare, Loopt and Gowalla, status updates on Facebook and Twitter, and videos on YouTube. Etc. I’ve got dozens of social graphs on dozens of sites, and trying to remember which friends puts his or her pictures on which site is a huge challenge.

What enabled Google to solve the search problem was a common standard for expressing pages and the links between them, so that they could index the webpages and derive a metric for which ones were more important. They didn't do this by replacing the web with a structured database that they curated, they worked with the standards in use to make sense of it.

To solve the social conundrum we need the equivalent - agreed standards in widespread use so that we can generalize across sites. Fortunately, we have these. We have OpenID and OAuth for delegated login; we have XFN, other microformats and Portable Contacts for public and private people connections; we have Feeds and Activity Streams for translating social actions between sites.

This enabling social infrastructure means that we'll be able to have a new generation of sites that enhance our web experience through social filtering without our connections being centralised in a single company's database.

Once we get used to the experience of being able to delegate login, personal connections and activity updates, we'll look askance at developers who insist we create yet another profile and invite all our friends by email to experience their site; it'll be like a website without links.

Platform Love: Getting Along - Panel

Panelists:


• David Glazer - Director of Engineering, Google
  
• Jeff Hansen - General Manager, Services Strategy/Live Mesh, Microsoft Corporation
  
• Dave Morin -Senior Platform Manager, Facebook

  
• David Recordon - Open Platforms Tech Lead , SixApart
  
• Max Engel, Head of Data Availability Initiative, MySpace

Moderator: Marc Canter - CEO, Broadband Mechanics

A new generation of young techies comes along, takes a look at the current stack, finds it too daunting (rightly so) and decides to start over from scratch. They find that they can make things happen that the previous generation couldn't cause they were so mired in the complexity of the systems they had built. The new systems become popular with "power users" -- people who yearn to overcome the limits of the previous generation. It's exhilirating! [...]
The trick in each cycle is to fight complexity, so the growth can keep going. But you can't keep it out, engineers like complexity, not just because it provides them job security, also because they really just like it. But once the stack gets too arcane, the next generation throws their hands up and says "We're not going to deal with that mess."

Now, I may be a few years behind Dave, but I think he is throwing the baby out with the bathwater, or the stack out with the cycle here. Back when I started out, to get my computer to generate sound, I had to make my own D to A converter to attach to the parallel port, and for non-character graphics, my hardware hacker friends swapped the character generator ROM for RAM, and I had to code in assembler to swap the display data in time.

Now my son thinks nothing of mixing 10 polyphonic Midi tracks in an afternoon or editing hi-def video (and yes, it's on an OS I helped to make capable of that).

Dave's revolutionary impulsiveness has a germ of truth, but what really happens is that successful technologies become invisible infrastructure for the next things that build on them.

I no longer need to write assembler, heck I no longer need to write C code. Dave's very URL - scripting.com - shows how we have built up layers of utility to work upon.

HTTP, HTML, JSON, Atom and Javascript are infrastructure now. Our deepest role as developers is to build the invisible infrastructure for the next generation to take for granted, so they imagine new abstractions atop that. Dave did it with feeds.

What we're doing with the Open Stack — OpenID, OAuth, PortableContacts and OpenSocial— is part of this evolutionary cycle too. We're combining building blocks into a simplified whole that makes sense to people who want their websites to become social.

It comes down to what you can take for granted as the baseline to build the next exciting cycle on.

When a site designs an API, what they usually do is take their internal data model and expose every nook and cranny in it in great detail. Obviously, this fits their view of the world, or they wouldn't have built it that way, so they want to share this with everyone. In one way this is like the form-fitting lycra that weekend cyclists are so enamoured of, but working with such APIs is like being a bespoke tailor - you have to measure them carefully, and cut your code exactly right to fit in with their shapes, and the effort is the same for every site you have to deal with (you get more skilled at it over time, but it is a craft nonetheless).

Conversely, when a site adopts a standard format for expressing their data, or how to interact with it, you can put your code together once, try it out on some conformance tests, and be sure it will work across a wide range of different sites - it's like designing a t-shirt for threadless instead.

Putting together such standards, like HTML5, OpenID, OAuth or OpenSocial or, for Dave's example of reviews, hReview, takes more thought and reflection than just replicating your own internal data structures, but the payoff is that implementations can interoperate without knowing of each others' existence, let alone having to have a business relationship.

I had this experience at work recently, when the developers of the Korean Social network idtail visited. I was expecting to talk to them about implementing OpenSocial on their site, but they said they had already implemented an OpenSocial container and apps using OpenID login, and built their own developer site for Korean OpenSocial developers from reading the specification docs.

I'm looking forward to more 'aha' moments like that this week at I/O.

He says:

Your data host’s job is to perform actions on your data. Rather than giving copies of your data out to a thousand companies (the Facebook and Data Portability approach) you host the data and perform actions on it, programmed by those companies who are developing useful social applications.

Which is exactly what an OpenSocial container does - mediate access to personal and friend data for 3rd party applications.

This environment has complete access to the data, and can do anything with it that you want to authorize. The developers provide little applets which run on your data host and provide the functionality. Inside the virtual machine is a Capability-based security environment which precisely controls what the applets can see and do with it.

This maps exactly on to Caja, the capability-based Javascript security model that is being used in OpenSocial.

Your database would store your own personal data, and the data your connections have decided to reveal to you. In addition, you would subscribe to a feed of changes from all friends on their data. This allows applications that just run on your immediate social network to run entirely in the data hosting server.

Again, a good match for OpenSocial's Activity Streams (and don't forget persistent app data on the server).

Currently, everybody is copying your data, just as a matter of course. That’s the default. They would have to work very hard not to keep a copy. In the data hosting model, they would have to work extra hard, and maliciously, and in violation of contract, to make a copy of your data. Changing it from implicit to overt act can make all the difference.

The situation is worse than that; asking people for their logins to other sites is widespread and dangerous. I'd hope Brad would support OAuth as a step along the way to his more secure model - especially combined with the REST APIs that are part of OpenSocial 0.8

If you're interested in these aspects of OpenSocial, do join in the linked mailing lists, and come along to the OpenSocial Summit on May 14th (just down the road from IIW).

When you are browsing the web, you often encounter pages that show different things depending on who you are, such as blog, wikis, webmail or even banking sites. They do this by getting you to log in, and then using a client-side cookie to save you the bother of doing that every time. When you want to give a site access to another one's data (for example when letting Flickr check your Google Contacts for friends), you need to give it a URL to look things up at.

The easy case is public data - then the site can just fetch it, or use a service that caches public data from several places, like the Social Graph API. This is like a normal webpage, which is the same for everyone, returning a HTTP 200 response with the data.

The other common case is where the data is private. OAuth is a great way for you to delegate access to a web service for someone else, which is done by returning an HTTP 401 response with a WWW-Authenticate: OAuth header showing that authentication is needed. If the fetching site sends a valid Authorization header, it can have access to the data.

The tricky case is where there is useful data that can be returned to anyone with a 200, but additional information could be supplied to a caller with authentication (think of this like the social network case, where friends get to see your home phone number and address, but strangers just get your hometown). In this case, returning a 401 would be incorrect,as there is useful data there.

What struck me was that in this case, the server could return a 200, but include a WWW-Authenticate: OAuth header to indicate that more information is available if you authenticate correctly. This seems the minimal change that could support this duality, and much easier than requiring and signalling separate authenticated and unauthenticated endpoints through a HTML-level discovery model, or, worse, adding a new response to HTTP. What I'd like to know from people with deeper HTTP experience than me is whether this is viable, and is it likely to be benign for existing clients — will they choke on a 200 with a WWW-Authenticate header?

HTTP does have a 203 response meaning Non-Authoritative Data, but I suspect returning that is more likely to have side effects.