Johannes Ernst’s Blog

O’Reilly Etel

Just looked through the program. This is going to be an interesting conference … thanks Surj for having me.

Dave Winer proposes to use URLs for digital identity

Dave Winer proposes to use URLs instead of e-mail addresses to identify the document creator in OPML feeds. His proposal is another sign in the rapidly growing consensus to use URLs for digital identity: from LID, OpenID to YADIS and now OPML.

He says:

When OPML was designed, over five years ago, spam wasn’t the problem that it is today. It made sense then to identify the owner of a document in the most straightforward manner, using an email address…

In 2005, it’s really hard to recommend that people include valid email addresses in a public document[s]…

For discussion: A new sub-element of <head>

<ownerId> is the address of a web page that contains an HTML form that allows a human reader to communicate with the author of the document via email or other means.

Example

<ownerId>http://www.opml.org/profiles/sendMail?usernum=1</ownerId>

It’s great that someone as senior and influential as Dave Winer comes to the same conclusion: URLs are very well suited not only to identify companies (like http://www.amazon.com/) and documents (like http://www.opml.org/spec) and so forth, but people as well (like myself at http://netmesh.info/jernst).

The consensus for the use of URLs to identify people is emerging as follows:

  • The user sets up a home page at a URL of her choice. This could be her blog, her ISP’s web account, a Geocities home page or any other page she has control over. She makes sure the home page contains a “magic marker” that states that this is an identity URL (exact details currently being finalized within YADIS.org — the place where all people interested in URL-based identity approaches come together — but most likely an HTML <link> or <meta> tag containing a URL, with shortcuts for those who can configure their own web server).
  • The magic marker points to the identity service that the user chooses, such as a LID or OpenID server. Given that all URL-based digital identity technologies are inherently decentralized, she won’t be locked into one particular company that provides this service, and she might even run her own identity service (e.g. by using an open source implementation).
  • When the user needs to identify herself on the net, e.g. as author of a document (OPML or otherwise), as submitter of a blog comment, or to identify herself when logging into a website, she uses the URL of her home page. The identity server will perform single-sign-on for her, so she doesn’t need to remember more passwords either, and identity-enabled software can easily confirm that it is indeed her instead of somebody impersonating her.
  • When somebody wants to find out more about the user, they can simply go to her homepage and find out whatever she chooses to publish there. She might put a web form there that allows others to contact her as suggested by Dave; of course, there’s nothing OPML-specific about the need to contact people on the internet.
  • If she pointed her magic marker to a LID-enabled identity server, she would also get things like controlled information sharing, and LID profile exchange based on access rights she can define on a per-user or per-group basis. LID Authenticated messaging expands on the idea of a simple message-sending form by allowing the submitter to identify themselves, and allowing the identity owner to define different message routing rules based on the identity of the message sender.
  • Many other interesting features are being created as we speak around URL-based identity by variety of people. They are possible only because it’s easy to build new cool things based on URLs (think tagging, for example), and not so easy with non-URL-based technologies, which is another great argument for URL-based identities.
  • By setting up as many independent home pages as she likes to, she can have as many independent identities as she likes to.

We’ll publish how to do all of this with your home page and a MyLID digital identity and other implementations as soon as the YADIS spec is finalized. You can sign up for one already or download code (open source, or commercial license) to run your own.

Talk at O’Reilly’s ETel conference in January

I will give a talk at the new O’Reilly “Emerging Telephony Conference” on January 26, 2006, at the San Francisco Airport Marriot. Here is the summary:

Indentity Crisis: Namespaces Out of Control - Johannes Ernst, Netmesh/Yadis.org

Date: Thursday, January 26th, 2006
Time: 11:30am - 11:45am
Location: Grand Ballroom A-F

In the old days, all we needed to know was a telephone number of the person we wanted to communicate with. Today, there are fixed and mobile phone numbers, email addresses, instant messaging handles, VoIP user names, account names at dozens of websites, blog URLs, and more. The list keeps growing as new methods of communication and collaboration are invented and innovation proceeds with no end in sight.

Radical simplification is needed not just because all these identifiers and the passwords that go with them can’t be remembered. It’s also needed because this fragmentation holds back new applications that take advantage of the new communications cornucopia: unified posting and messaging, user-centric remixing of a variety of data streams, multi-technology presence and communications, and many others.

Recently, a number of bottom-up projects (such as LID, OpenID, SXIP, i-names) have sprung up to provide unified identification and authentication across a range of IP-based services. Internet-wide identity interoperability, enabled by the YADIS project, is becoming a real possibility and will turbo-charge the development of a range of compelling new applications. In this talk, Ernst provides a brief overview over these projects, explains how to take advantage of interoperable digital identities, and discusses a couple of innovative applications.

Why at a telephony conference? Simple: it’s not just about web single-sign on. It’s about allowing people to be first-class entities on the network, and that also means I shoulnd’t have a phone number from Cingular and one from SBC and a Skype handle and an AIM handle, but I should be able to give you a single identifier — a REST-ful LID or YADIS URL that I pick — which is sufficient to allow you to contact me through any of those technologies, tag me, point to me, and so many other things that open up a myriad of possibilities … not the least of which is to drive more business to those systems because using them becomes simpler, again.

Bombings in Amman Today

Leaving aside technology for a moment, today’s news about hotel bombings in Amman, Jordan, remind me of my stay there a couple of years ago to attend a World Economic Forum meeting. I blogged about it.

I’ll always remember the very tight security they had in place with humvees all around the hotels, and the mysterious fire alarm in the middle of the night… I guess it was just a matter of time until bombings like today’s simply had to happen in Jordan — yes, the hotel I was staying at was one of those hit.

I guess I’m not intellectually capable of understanding what motivates anybody to walk into the lobby of a hotel and blow up the tourists or the wedding reception there. I do not comprehend how anybody could think that anything good could come out of such a thing. If you guys have legitimate grievances … anybody remember Gandhi? There is another way! (Or you will never get any sympathy from people like myself, never mind what exactly your grievances are; I don’t even want to find out if this is what your means are.)

My thoughts are with the Jordanians, the people who were hurt or killed, and in particular the Jordanian King Abdullah, who is one of the most impressive leaders I’ve ever met and who has set out his country on a very courageous course of education and bottoms-up empowerment — probably the very things that the bombers and their brethren hate about it. Let’s hope he can keep the situation under control and keep moving society moving forward.

How does one control access to information in LID?

Dan Libby asks about this in private e-mail. I got his permission to post some of the exchange because I’m sure others are pondering the same questions. I edited it a little bit.

Dan writes:

In reference to: http://lid.netmesh.org/wiki/LID_2.0_VCard_Profile:

1) Am I missing something? It seems to me that any profile exchange mechanism that people will actually trust must allow for privacy of the users data.

Absolutely. Anything from “you get everything” to “you get nothing” to “you get only fake data”. (I’m not necessarily condoning the latter, but a system must support it, otherwise so many people simply won’t adopt it for many kinds of interactions.)

This implies:

a) the profile data is not at a publically accessible URL unless the user so authorizes. If this is not the case, what is to stop me from writing a spider to aggregate profile info ( in handy xml format even ) and sell it to spammers?

Because the URL will not return any data unless the owner of the URL allows the particular client to have access to it.

Sort of like HTTP Basic Auth — you can have the protected URL all you want, because you can’t see what’s behind unless you provide the correct credential.

b) the profile exchange mechanism permits the consumer website to access profile data only after the profile owner has authorized the consumer to do so.

c) b, in turn implies some sort of authorization token that the identity server provides the consumer.

and possibly:

d) the user can control exactly which data the consumer can access/view.

I had assumed that LID has mechanisms for the above, but the above-referenced page doesn’t metnion them. So, am I not looking in the right place, or…? It occurs to me that possibly this is defined somehow in another LID profile. If so, perhaps you can acknowledge/reference that and/or provide examples?

The LID profiles are designed to be orthogonal. You can use LID_2.0_VCard_Profile with or without making the URL a RelyingParty aka Identity Consumer. If it isn’t a Relying Party, it does not rely on identity assertions (tautology) and thus it cannot implement a big switch/case statement on who the client is, and so it must return the same information to everyone.

But if it is also a Relying Party, then I knows who the client is — and can dispatch appropriately, say, “give cell phone number to Joe only”.

This kind of orthogonality is generally a LID design principle, which now implicitly is also used for YADIS. Other profiles use that as well.

Add-on at 11am:

do you have any suggestions for integrating LID style authenticated profile exchange on top of openid? Is that a realistic possibility?

It absolutely should be. While at NetMesh, we haven’t done this yet in code, the basic idea is the same: browser authenticates with identity consumer (aka relying party) and then performs a query for certain profile information. The identity consumer, which would also be the target of the query per current YADIS spec, can look at the OpenID session cookie (or whatever it does to keep track of browser sessions) and filter its response appropriately. Another example of orthogonality in action…

Next Page »