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 …]