In my quest to learn more about the good stuff that other identity projects have come up with (and that often is subject to a NIH syndrome which I’m not a particular fan of), Drummond Reed has again been the target (victim?) of my questions. [The deal is that he answers my questions, but I need to blog the answers; sounds fair to me!]

This time it’s on Link Contracts in XDI, which are one implementation of the very intriguing concept of Identity Rights Agreements. If you don’t know what that might be, consider this:

You don’t like to hand out your phone number to vendors because you don’t know how they will use it, right? (like sell it to every telemarketer on the planet.) What you need is a Identity Rights Agreement that you attach to the phone number. Then, you only hand out a package, consisting of phone number and Identity Rights Agreement; never the phone number by itself. The vendor only gets the phone number if they commit to meeting the terms of the (legally binding) Identity Rights Agreement, such as "you can call me as long as I am a customer, but no more than once a month". Or whatever the terms are that you choose. As consumers, I think we’d all greatly appreciate this. Obviously, the same concept would work for your home address, the names of your kids, your bank balance, your recent blood tests, or mobile phone bill.

So here is my "transcript" of my e-mail conversation with Drummond on the subject of XDI Link Contracts:

Johannes:

Do I understand it correctly in my layman’s terms, that link contracts work like this:

• A tries to get data element X from B. (X could be the phone number of B)
• B responds with the equivalent of a 401 Unauthorized (the HTTP protocol code that tells your web browser you need to enter a password), and sends along a contract template. (Is that exactly one contract template, or could A have a choice, like "pay more, get more" or something?)

Drummond:

Yes, it’s just like real-world contracts — you can have as many as you want. But in most situations, you want a small set to facilitate reaching agreement. Thus the Identity Rights Agreements Working Group [in the Identity Commons, that counts some good technologists and high-powered lawyers as charter contributors].

Johannes: (continued sequence of steps from above)

• A decides to accept the contract template, and indicates this by signing the contract template with his private key.
• A tries to get X from B, passing the signed contract template along.
• B validates the signature, checks it’s the right contract, and returns X.

Is that about right?

Drummond:

All correct.

Johannes:

Is there some notion of a "session" or do I have to go through this scenario every time I want another piece of data? Say, I’d like to subscribe to your location stream (via cell phone GPS or such), but you only let me get at it if I promise not to show it to your wife There is an update of the coordinates every 2 minutes. What happens on the second and subsequent exchanges?

Drummond:

That’s the beauty of link contracts. They govern the data interchange relationship. If I give you a contract to subscribe to my location stream if you won’t show it to my wife, and the contract lasts until I cancel it, then you’ll be able to ping me for the location updates (or I push them to you) just by reference to the contract.

That last part — "by reference to the contract" — is pretty important. We call it a "rights path". You don’t just ask for the data. You ask for it via the contract. That means a longer XDI address, but one that builds in all the necessary access & authorization control. For example, you don’t just ask for:

=drummond.reed/(+location)*(+gps)/($current)

…because you, =johannes.ernst, are not =drummond.reed. Instead you ask for…

=drummond.reed/($link)/(=johannes.ernst)*(@idcommons/(+contract)/(+person-to-person)*(/(+location)*(+gps)/($current))

…which translates to, "Hi, Drummond, this is Johannes, and under my Identity Commons Person-to-Person link contract with you, please give me your current GPS location."

Johannes:

Also, the above scenario is a “pull” scenario. Is there a “push” scenario where maybe the first exchange is pull ("get me Drummond’s current location") but the subsequent ones are "push" ("Drummond has moved!")

Drummond:

You bet. Link contracts can control any aspect of data sharing, including push synchronization. If the link contract above said that I will notify you when my location changes, then when that happens my XDI service provider would send you an XDI message that would look just like the XDI document you would get if you pulled the data, only it would be pushed.

Personally, this has always been one of my favorite aspects of XDI and link contracts: push or pull, take your choice, they both work equally well.

[There are more questions in the pipeline; later ...]

If you are a techie, I highly recommend you look at the presentation "JavaScript malware just got a lot more dangerous" by Jeremiah Grossman and T.C. Niedzialkowski from WhiteHat Security, Inc. An MP4 recording of the demo is here.

Wow, is this scary! They are demonstrating how to completely hijack a user’s browser session without the user noticing, and running things like keystroke loggers right in the browser, re-configuring the user’s firewall, attacking other servers on the user’s intranet, print on the user’s printer, and sweet stuff like that. Without using any browser exploits! And without leaving any trace because the JavaScript and other content just goes away after the browser is closed.

Missing 10,000 dollars in your bank account, but your bank’s website says it’s still in your account? That’s the kind of thing …

He said:

.

If it doesn’t have a URL, it doesn’t exist.

This happened to be in a hallroom conversation at Digital Identity World, in the context of URL-based digital identity. But his insight is much broader.

The thought that immediately springs to my mind is Wag The Dog’s "Of course it’s true; I saw it on TV." It’s that kind of profound.

Assume the internet keeps growing at the same rate for another decade or more. In some sense, it will be larger than meatspace. Assume innovations like tagging keep springing up in the future: tagging would have been impossible without all things worth tagging having URLs. URLs give those things a handle, a way of attaching to them. No URL, no way of attaching to them… and they disappear from sight.

If there’s a thing changing in the forest and nobody can attach to it, does it make a sound, ahem I mean, does the thing really exist?

This argument has of course been the essence of why we came up with URL-based identity in the first place: people matter, so they should have URLs.

Wow! By unanimous vote on its mailing list, the all-new Identity Commons has created the following 15 Working Groups:

• Collaborative Tools (Eugene Eric Kim)
• Internet Identity Workshop (Kaliya Hamlin)
• Identity Gang (Paul Trevithick)
• Standards Gang (Dick Hardt)
• I-Tags (Drummond Reed)
• Identity Schemas (Joaquin Miller)
• OSIS (Dale Olds)
• OpenID (David Recordon)
• SAML (Peter Davis)
• Identity Rights Agreements (Dan Perry)
• I-Broker Interoperation (Owen Davis)
• XRI Registration (Victor Grey)
• XDI.org (Bill Washburn)
• Identity Mashup (Jon Ramer)
• EUCLId (Brett McDowell)

The people in parentheses are the representatives from the working groups into the Identity Commons board of Stewards.

If the user-centric Digital Identity industry has an organization, this is it; if it has a supervisory board, this is it!

Congratulations all around!

I suspected that one could write a full OPML editor completely without server-side code, using some XSLT and JavaScript trickery.

The Hyperscope project has now done exactly that. It’s very cool. Try it out here.

They have applied it to something rather interesting in itself: a modern version of Doug Engelbart’s famous Augment system, which was shown at the "mother of all software demos" in 1968. A streaming version of the demo is archived here and if you are interested in computers, you simply must have seen it. Almost 40 years later, we still don’t have all the features that Engelbart had working in 1968!)

But back to OPML: what Eugene and friends have accomplished there not just works but even looks pretty; it also appears a lot more usable than many server-based OPML renderers. If I understand this correctly, the only thing one has to do to render OMPL through their code is to add a single line (<?xml-stylesheet …) to the OMPL file.