We just returned from a great week of vacation south of Cancun in Mexico. Everything worked out just fine, except for the trip back home when we made the mistake of eating Guacamole at the "Taco Guacamole" (I think its name was) at the Cancun airport. My wife and I are still recovering … you can imagine the details … kid is fine, he didn’t eat any. So: don’t do it, eat at a real restaurant!

Also, I agree with most of what people said about the Gran Porto Real. Very nice hotel, its architecture reminded me of the Fairmont Princess in Arizona (where PC Forum was this year), but the front desk is definitely a turn-off. I could also have done with a little less of the up-selling (as a matter of principle, I don’t do "only eat at our hotel" kind of deals — who knows what you’d be missing!).

I didn’t check my e-mail or voice mail even once … Yeah! … and given the above, please bear with me while I resynchronize with the world.

It occurred to me that we might not have to do “round-trip nonces” at all between a Relying Party and the LID site to prevent replay attacks.

The following one-directional protocol seems to be sufficient (using our patient Mr. LID Demo User and FirstSSO Inc. as an example, as always)

• The challenger (e.g. the LID Relying Party) sends a redirect to the LID, such as:
  http://lid.netmesh.org/liddemouser/
    ?lid-action=sso-approve
    &lid-target=http://firstsso.netmesh.org/infogrid-php/
  without specifying a nonce.
• If the LID site successfully validates the browser session, the user gets redirected to the following URL:
  http://firstsso.netmesh.org/infogrid-php/
    ?lid=http://lid.netmesh.org/liddemouser/
    &lid-nonce=NNN
    &lid-credtype=gpg%20–clearsign
    &lid-credential=CCC
  where CCC is the appropriate signature on the URL, and NNN is nothing else than a current time stamp according to the LID site’s clock, in some suitable encoding.
• The Relying Party (e.g. FirstSSO) now performs the following algorithm:
  1. Check whether the signature is valid on the request, and corresponds to the LID that was provided in the request. If not → access denied.
  2. Check the provided nonce NNN. If not present → access denied.
  3. Calculate the delta time between the current time (as measured by its own clock) and NNN.
  4. If the delta is outside of a defined time window → access denied. The time window could be something like “nonce issued not longer than 6 hours ago according to local clock, and no more than 1 hour in the future”. The time window’s parameters are not critical for this algorithm; the size of the time window is determined by the maximum clock skew a party is willing to tolerate.
  5. Check whether this nonce has been used by the given LID during the past 6 hours (whatever the boundary of the time window). If it has been used before with this LID → this is a replay attack, access denied.

As an attacker, I thus cannot successfully replay any request that I have observed. If the observed request was made in the recent past, its nonce will still be in the database and access will be denied. If it was made in the more distant past, it will be rejected because it is too old. And while the nonce is predictable (the current time), I cannot construct a URL myself because that would require me to fake the signature on the URL and thus to break GPG.

As a Relying Party, I will have to keep track of all nonces used within the time window, but I think that is a manageable task. The size of the required store is determined by the maximum clock skew I’m willing to tolerate and how often I invalidate my own session cookies and request a new signature from the LID site, so the relying party can put the trade off where it likes to.

Special thanks to Dick Hardt of SXIP, who recommended that we should tighten our use of nonces during OSCON to better protect against replay attacks.

Adrian Blakey recently started blogging at family.blakey.org/adrian. He is one of the few people who everybody says can see things just beyond the horizon… and has done so consistently over many years. Welcome Adrian!

He started out commenting, as an insider, on a recent NY Times article on the future of healthcare. Both article and comment are very worthwhile reading if you are interested in this subject. As with so many other things, accelerating technology and market competition has led to a dramatic increase of choices for the consumer/patient, and the only person in control is: you, the patient. What is emerging here is clearly the worst of all possible systems, except maybe for all the others.

P.S. thanks for the very nice words on LID at the end of the post.

Dave Kearns recently introduced the work of Danah Boyd to the Identity Gang. I just read through her MIT master’s thesis which has an interesting, and probably sociologically quite valid view on what might constitute "identity" both off-line and on-line. It rings a lot more true to me than much discussion that’s currently going on in "digital identity" circles.

I also very much like her term "face" instead of what we techies usually call "persona".

BTW, if anyone ever wondered why we talk about both "situational software" and "identity" at NetMesh, this thesis provides some very good answers: identity is situational, too, and situational support requires identity. In fact, she uses the term "situation[al]" 71 times in her thesis that’s really about identity…

One point in my recent REST vs. SOAP — there are more nouns than verbs! post I don’t seem to have communicated well. Let me try to augment what I said…

Imagine two software systems that both process the same amount of information and generally do the same thing. The first of those systems is not a web-based system, and thus does not allow anybody to address any part of its functionality or information using URLs. The second of those systems is exposing absolutely everything as URLs. Which of those two systems is more conducive to third-party innovation?

Well, think innovation a la del.icio.us or Technorati Tags. It’s very obvious that the non-web-based system cannot work with those innovative services — there’s nothing that those services could refer to, and this kind of innovation would not occur.

I meant to conclude that if two otherwise equivalent information systems expose a substantially different number of "things" as URLs, all other things being equal, the system with the more URLs would provides more points to which innovation can latch itself, del.icio.us being the prime but by no means the only example. (One could argue that a SOAP-based architecture might allow the same number of latching-on-points but they are much more "hidden" behind so many messages instead of being "up front" as in case of REST. The conclusion is the same).

People generally seemed to agree with my view that SOAP-based architectures expose fewer URLs than REST-based ones, and so I conclude that (outside) innovation can attach itself more easily to a REST-based architecture than a SOAP-based one. On the first glance, fewer URLs could mean that an architecture was simpler, but I’m assuming the exact same functionality for both systems for my thought experiment: one could say that the REST-based architecture simply has a much "broader" API… at least the easily and uniformly accessible parts …