I’m working on a few tools to do semantic web stuff in Safari. Since I’m just at the prototype phase, I’m handling this stuff with javascript. I just want to make some useful bookmarklets and be done with it. The trouble is I normally can’t depend on Prototype or jQuery to make my life easier.

Fortunately, Mr. David Hochman whipped together a little Protoype bookmarklet that pulls down Protoype wherever you need it. It’s pretty spiffy, but a bit special purpose. It depending on a script link to use an id of "prototype.js", which won’t always be true. Instead, you should check the value of Prototype.Version, which has the added benefit of letting your stuff be version dependent. Also, doesn’t everyone DRY out their code to the point that Huffman coding fails to improve anything?

(function() {
  var d = document;
  try { Prototype.Version }
  catch(e) {
    var s = d.createElement('script');
    s.type = 'text/javascript';
    s.src = 'http://scripts.example/prototype.js';
    d.getElementsByTagName('head')[0].appendChild(s);
  }
})();void(0)

To install this bookmarklet, just drag it to your bookmark bar or right-click and save. If you haven’t noticed, you’ll still need to point your script at a copy of Prototype. Version checking is left as an exercise for the reader.

But let’s not forget I hacked this up so I could use Prototype to a real end. Sadly it’s not RDF or microformats or HTML5. In fact, it’s just for a feature from HTML3.2, rel="next". I’m far too attached to Safari’s minimalism to suffer Firefox just for the plugins, and Opera just feels funny. Don’t get me wrong, it’s quite a nice sort of funny. I do enjoy using substances that make me feel pleasantly funny; I just gave up my habit of doing that all the time. Now it’s more of an occasional celebration. Say, in honor of passing acid. No really, the other Acid.

But I digress. I just want a simple tool to go back and forward. I know it’s in vogue to have little text hanging about the page that does that. But it’s also in vogue to say that the web will never supplant books. And that journalism is dying. Probably fnords as well. But I’m not that kind of gas-guzzeling, coke-drinking, twitter-checking sheep. No, I’m the other kind. Really, I’m glad they finally took the next- and previous-page buttons out of books. But they’re turning around that sort of innovation and putting them back into newspapersites. Come on!

So I proudly present to you—in this original, exclusive, and one-time event—my next and previous buttons. Once you’re done, lock up and turn the lights out.

I really want a decent reputation network. Reputation networks are simple concept. Many have tried, but they just haven’t been done well yet. None has brought science fiction’s imagination of the reputation network into reality.

Cory Doctorow’s Down and Out in the Magic Kingdom is the best fictional reputation network idea I’ve seen. Everyone uses its whuffie system, pervading its society like Google has ours. People would hardly have a conversation without checking your whuffie, seeing who strongly trust and distrust you, seeing who you mutually respect, who hate you both. Just like you’d quickly Google to research a bit of trivia.

But there is nothing yet like this system. There are networks where all your friends might have an account, but it’s hard to see what that social graph really implies. Still, there are some interesting tools today.

One of the first reputation networks was Pretty Good Privacy’s Web of Trust. Originally invented in 1992, there are a handful of good and free plugins to work with Outlook, Mail.app, or GMail in Firefox. And while I use PGP for all my email, I only have three people in my Web of Trust. Compare that to my Facebook friends or Twitter followers and it’s easy to see this old school reputation network is probably past its prime.

At the moment, Karmasphere and Naymz are the only companies trying to make whuffie real. Karmasphere is designed for programmers, not regular folks. It is just a database with reputation scores for certain identifiers like URIs and IP addresses. Naymes vaguely resembles a poorly designed LinkedIn with a reputation number tacked on. And it can’t manage to import much of the existing I already have spread about the web. So while these things aren’t well known or easy to use, they are out there.

The trouble with these networks is that their goal is to provide my One True Reputation™ value. Whereas PGP only says whether someone really is who they say they are. EBay ratings don’t mind if you are lying about your legal name, but they do care if you satisfy your customers. But startups like Grocio give real information we can use. Grocio just compares stores by reporting the prices of certain items. It doesn’t waste our time rating cleanliness, customer service or trendiness. It is hard data that we need while we’re getting used to searching to compare real things.

Eventually, places like Consumer Reports and the Better Business Bureau will start requiring claims be written by people who can prove they are who they say they are. That means if you won’t login with an OpenID or a X509 client certificate or a PGP key, then they won’t trust what you say at all. Once that happens, then I can decide if I want to trust your Yelp review based on whether you are someone I really trust.

Marc Canter has been talking about his idea of the Open Mesh, especially its dashboard. In the new web, I’ve got all my services spread all over. The dashboard presents a centralized place to tie all these outside services together. To actually make all of these things work together, there are a bunch of pieces missing. The dashboard needs a way to connect to these services, a way to group the people who can access those services, and a way tell those services what rights those groups have to access them. So this is the first in a series of brainstorming about the gaps in the OpenStack to be filled to make this work.

Today, plenty of people want to tie together their identity from different places on the internet. They maintain a list of their identities at Flickr, Twitter, Magnolia, Plaxo and Brightkite. If they’re geeky, they may even mark these links with hCard attributes, so those places are marked rel="me". The geekiest keep a single page showing everything happening at those services, perhaps with Plaxo or FriendFeed or an Activity Streams plugin on their blog. But when you’ve got an account over at Ma.gnolia, there isn’t a good way to push that service back to your OpenID so it can advertise that you store your links there. Right now, you have to collect those identities manually. Doesn’t that just smell ripe for automation?

If you use OpenID, there is a document somewhere saying all the services your ID supports. For the moment, the list of possible services is pretty small. Your ID might be able to send your registration information, like name and email address, or maybe your PGP key. But right now, there isn’t much you can advertise in your discovery document. There isn’t a way to send your photo gallery, your microblog, your bookmarks.

But even if there were, there isn’t a simple way to update those services. The way disco docs work today requires someone to manually edit the disco doc to add a service. Even if that disco doc is automatically generated, it’s probably only generating services for stuff the OpenID Provider knows how to play with. So your service provider needs a way to tell the disco doc it wants to play.

It shouldn’t be too hard to design a service where Ma.gnolia can send a request to be added to the disco doc. All it really needs to do is send what type of service it is, and where the service lives. Since an XRDS disco doc has a format for this info, it is natural to send it:

<Service>
  <Type>http://ma.gnolia.com/links/1.0</Type>
  <URI>http://ma.gnolia.com/josephholsten</URI>
</Service>

These services need to be able to be added to, updated and deleted. The Atom Publishing Protocol is a great example of a protocol to handle collections like this. The real trick is to treat the XRDS document as a service link collection and give each of these service links a URI so they can be updated and deleted. With this API, it would be simple to access the services attached to an OpenID.

But doesn’t that mean any site could post some new service onto your identity? Not if we ensure the service is authorized to post before we do anything. And the most powerful general purpose authentication protocol today is OAuth.

Most of the time, you know if you want the service attached to your disco doc when you log in at the service. Assuming it lets you log in with OpenID, your OpenID Provider can just ask you if it should also give the service access to add to your disco doc. If you agree, the OpenID Provider can send an authorized OAuth Access Token along when it authenticates you to the service. The service posts its disco information to your disco doc, and Bob’s your uncle.

But since the OpenID-OAuth Hybrid protocol is not finished yet, the service provider could just ask to get authorized to post to your disco doc itself. It would send you to your disco doc’s authentication endpoint, you allow access, and the service can then update your disco doc like before.

The great thing about OAuth is that it allows us to control exactly who can update the disco doc. A smart dashboard would allow you to delete a service, all the endpoints it created, and revoke that service’s access to your disco doc.

To wrap up, I’d like to mention some alternatives to an XRDS protocol modeled after AtomPub. First, this data shouldn’t be in XRDS, but microformats or RDF. I sympathize and am convinced there should be representations of this data as both microformats and RDF, but think XRDS is optimized for just this case. Alternatively, this information could be pushed back via an XML-RPC or SOAP protocol. But since the end result is to change an XRDS document, HTTP verbs are well suited to the actions that would actually be used, where an RPC implementation would simply reinvent standard HTTP procedures and unnecessarily confuse the semantics. Finally, this could be implemented as an OpenID AX pushback service. But as as I know of no services using AX, there is little precedent to build upon. Regardless, I only want the simplest protocol that does the job, so if you can present something better I will gladly support it. Whatever gets the job done.

I am tired of giving out my social security number. If you have looked into digital identity technology recently, you have probably heard of the password anti-pattern. As Jeremy Keith puts it,

asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be phished.

The same thing applies to my social security number. Every time I give it out, I am making it a habit. I am accepting identity theft.

This anti-pattern has gotten a lot of notice recently as OpenID has gained use. OpenIDs are just a URI, and if some bank told the IRS that my OpenID had earned one million dollars interest this year, there would be no way for the IRS to verify the claim. That is, unless I gave that bank my OpenID password, which would prove that they really were speaking for me.

But what if that bank were broken into? If some thief gained access to the bank database, they could go around acting like me until I changed my password. They might even be able to set my password to whatever they wanted wanted with that information. So giving out my password, even to my bank, is a bad idea.

To fix this problem with OpenID, a group of people developed the OAuth protocol. OAuth doesn’t need you to give your password to your bank. OAuth works by having your bank ask your OpenID provider for permission. Then, you can log into your OpenID provider, grant permission, and the bank gets to prove that you really are who you say you are. Entirely without giving your bank the sensitive information that would be lost in a break in.

Now, it is possible that the bank could be broken into. They would still have some OAuth credentials that the thief could use to claim to be you. But OAuth has already thought of that. With OAuth, you can revoke those credentials at any time. If your bank gets nationalized by the Fourth Reich of Zombie Hitler, have no fear. One click and there is nothing the undead national socialists can do.

But today I still need to give my bank my real and entire social security number. That is all some crook needs to ruin my credit. I have no way of revoking that information. In this modern age, this needs to change.

The IRS needs to stop making us give irrevocable identity information to everyone who asks. If I sign up for a job, let me log into the IRS web site and create a unique tax identifier for that employer. If and, given today’s security climate, when their human resources database is broken into, no big deal. I just need to log into the IRS site and let them know the identifier needs to be revoked. No more would illegal immigrants pretend to use my social security number. No more would criminals apply for loans and credit cards in my name. All because the government started using secure identity.

While I am a big fan of OAuth, it is not the first protocol that could handle this trick. Kerberos and WS-Trust and perhaps many others could be made to do the job. Of course, I like OAuth because I have been involved with it, and because it was designed for just this problem. But it is being reworked for a formal standard today in the IETF. Much is my love for OAuth, but if government is in the place to make these changes now, they will need to use something else. And I would rather have my identity be safe than wait for my pet protocol to be finished.