Identity

I have been signing outgoing electronic mail, on and off, for many years.

It’s getting harder.

Now available for your normative referencing pleasure:

Young, I., Ed., Johansson, L., and S. Cantor, The Entity Category Security Assertion Markup Language (SAML) Attribute Types, RFC 8409, DOI 10.17487/RFC8409, August 2018.
See https://www.rfc-editor.org/info/rfc8409.

This has been cooking for quite a long time: the original discussions about the need for something like this go back to early 2012, and the initial specification drafts are from later in that year.

Some very early mail I have from Leif credits RENATER (the operator of the French research and education identity federation) with the original idea, but as you can see from the Acknowledgements section it has definitely been one of those “it takes a village” enterprises.

The technical content hasn’t changed very much in the last five years, but it’s wonderful to have a stable reference available for the many use cases and specifications we have already built, and continue to build, on top of the entity category concept.

It has been more than a decade since I wrote Responsible Behaviour, in which I mused about how many Wikipedia articles the man on the Clapham omnibus would need to read to understand a particular cryptography-related joke. I saw this, in part, as a proxy for whether cryptography was becoming mainstream. I ended with:

Do you agree? More interestingly, what do you think the answer will be in ten years?

The 38th meeting of the REFEDS (Research and Education FEDerations) group took place this weekend. After Matte Miettinen had summarised the state of the Shibboleth Consortium, I gave a brief presentation updating everyone on the project’s technical status. You can download a PDF copy of the slides.

My podcast application of choice is Overcast by Marco Arment. He has just released Overcast 4.2, and the announcement is notable for its enlightened approach to user privacy:

Your personal data isn’t my business — it’s a liability. I want as little as possible. I don’t even log IP addresses anymore.

If I don’t need your email address, I really don’t want it.

…

And the first time you launch 4.2, people with email-based accounts will be encouraged to migrate them to anonymous accounts:

Of course it’s not possible for all applications to operate anonymously, but the principle is important: you should collect only as much personal information as you require and no more. Anything more than this is a GDPR concern and a data breach waiting to happen.

The 35th meeting of the REFEDS (Research and Education FEDerations) group took place this weekend. After Anne Harding had summarised the state of the Shibboleth Consortium, I gave a brief presentation updating everyone on the project’s technical status. You can download a PDF copy of the slides.

The key ceremony for the REEP service took place on 2014-05-18 after the REFEDS meeting in Dublin, Ireland.

I witnessed this ceremony and was convinced that the key attached to this post as a self-signed X.509 certificate was generated during the ceremony within the hardware security module in Sweden that will be used by the REEP service to sign metadata served by it. To certify this, I have generated a detached signature file for reep.pem using my PGP key.

To the extent that you trust me to have taken care while witnessing the ceremony, you may find that validating my signature on reep.pem gives you some comfort that metadata documents signed by the private key associated with reep.pem are, indeed, legitimate outputs of the REEP service.

As an aside about the ceremony itself, proof that a particular computational event has occurred in a particular way is almost impossible in a world of networking and virtual machines. We’ve known this for a long time: the paranoia goes back at least as far as Ken Thomson’s Reflections on Trusting Trust. We’re not quite living in The Matrix, but the evidence of ones senses doesn’t really go very far towards absolute proof. So what the other witnesses and I did during the ceremony — all we could do, really — was gain confidence by asking questions, taking photographs of the steps and trying to think of ways to validate them. For example, I was later able to verify that the pkcs11-tool command being used was indeed the one which would be installed on a system running 64-bit Ubuntu 12.04. Unless, of course, Leif foresaw that trick and subverted the md5sum command as well. It’s turtles all the way down.

I’m speaking later today as part of a session on the Future of Federations at the Internet2 Fall Member Meeting in Philadelphia.

Here is a PDF version of my slides. They are really just a list of the emerging technologies I think may affect identity federations in the short to medium term future; I think things are changing quickly enough that looking further forward than a couple of years is just too difficult.

One of the systems I work on is the back end of the UK federation’s metadata system. Although I’ve talked about this in several presentations, the bare structural diagram isn’t very informative on its own. Here, I present a snapshot of the architecture, and go into a lot more depth on the what, how and why than you’d get from just the slide on its own (click on the image to get a larger version).

I hope that this article can perform double duty as a case study for the Shibboleth metadata aggregator tool, which acts as the engine behind the metadata system and to which I also contribute as a developer.

I’ve been pretty disappointed by social networking “products” up to this point. I do use Twitter once in a while, but it’s pretty ephemeral stuff. I think that’s fine, it means I don’t have to worry about missing anything.

When I was very young and naïve, I thought Facebook looked pretty interesting. In practice, the level of sheer malevolence displayed by the company and its founder have stopped me from using it for anything other than keeping up with the family.

Ever hopeful, I now have a presence on Google+. It’s possible that this new service will end up as malign as Facebook, but for now at least I feel much less like I am being packaged up and sold as product. It seems, really, like a social network done right.

All that seems to be missing is the people.

I gave a presentation to FAM10 back in October in Cardiff, in the “Not for the faint hearted” session. You can download the slides as a PDF file from the illustration on the right.

My working title was “How to Survive the Coming Zombie Apocalypse”, but the presentation was really about how to survive the transition from cozy local federations to federated operation in the global internet. Whether that looks like a scary prospect depends, of course, on how conservative you’ve been to date: UK federation recommendations have always emphasised the difference between technical trust and behavioural trust, and the talk goes into some detail on this topic.

Understanding trust allows you to protect yourself against the zombie hordes (sorry, I mean “entities not bound by your local federation’s behavioural norms”). The other topic covered in detail is how to benefit from interfederation by making sure that you’re running software capable of interoperating widely.

BEER is the current attempt at a decent acronym for a new service in the federated identity space. BEER stands for [Bunch|Bucket|Bag] of End Entities Registry, and you should be profoundly glad we didn’t go with any of the earlier names.

You can find out more about it at the project’s wiki; Nicole Harris has a pretty good summary of the idea and what it might mean.

One thing that seems to be confusing people about BEER is that it’s easy to make the assumption that it’s trying to be a federation along the lines that we have at present, just with less strict membership rules. I’m not saying that such a thing wouldn’t have a use (TestShib has been very useful for many people, although it leans so far towards openness that some would argue that it falls over), but this is not what BEER is about.

It’s probably more helpful to look at BEER as a new kind of thing, an independent registrar of metadata. Its job is to assure the authenticity of the metadata it publishes (in terms of establishing that the metadata for an entity has a connection to the owner of the associated domain) without attempting to make guarantees about any of the things you might later layer on top of that “technical trust”. As such, it’s aiming to be a component in an overall trust framework rather than a complete solution in the way that many of the existing federations see their role.

Whether such a service has a long term role to play depends on whether the various existing federations start to converge in terms of their view of their own roles, and of course whether that convergence is in the direction of monolithic trust or in the direction of separation of the different trust components. Both approaches have supporters, of course, and we’ll just have to see how things work out. It will be obvious from previous posts that I’m in the “separate the concerns, behavioural trust is end-to-end” camp, which I’d broadly characterise as the design we chose for the UK federation, and which I think has worked out pretty well in that community.

By coincidence, I’ll be talking at Federated Access Management 2010 (FAM10) next week about how to survive a scary post-apocalyptic future in which not all UK federation metadata originates from the federation’s own members, and BEER will certainly be on the agenda. As will beer, of course, although probably not during the talk.

The Thawte Web of Trust, for which I was a fairly junior notary, was shut down recently. This included revoking all existing certificates back in November, at least according to Thawte’s FAQ on the closure. Amusingly — but perhaps not surprisingly to anyone familiar with the area — I’ve had to date precisely no queries relating to my continued use of the supposedly revoked personal e-mail certificate.

The only other S/MIME certificate authority I’m aware of that does Web of Trust type identity validation is CAcert; unfortunately their root certificate isn’t trusted by most browsers and e-mail clients and until that happens (if it ever does) I can’t recommend them as a replacement. Similarly, the lack of built-in PGP/GPG support in current mail clients rules that system out for most people.

If you had a Thawte S/MIME e-mail certificate, you may have been able to trade it in for a 1-year equivalent from VeriSign free of charge. Unfortunately, after the first year it looks like VeriSign charge $19.95 per annum even for a “persona not validated” certificate, which doesn’t sound to me like a lot of bang for your buck.

One alternative for the cost-conscious is Comodo’s Free Secure Email Certificate product. Again, this is “persona not validated” but should be sufficient for most uses and you can’t beat the price.

[2019-10-08: Removed link to Comodo’s product, which no longer exists.]

Metadata aggregation as a route to cross-federation inter-operation continues to be my main focus for the year, and yesterday I delivered a presentation on the subject at JISC’s Federating: The Next Generation event.

I think the talk went reasonably well; a couple of people remarked that they liked having the key concepts separated out and clarified. People even chuckled in the right places a couple of times.

Checking Twitter for the #FAM09 tag I find that the main thing a couple of people took away from the talk was a snarky remark I made about XSLT. Curiously, I find that I’m fine with that.

As usual, here’s a PDF version of my slides from the presentation:

• 20091123-Metadata-Aggregation.pdf

There are a fair number of animated diagrams in this talk, and not as many words as usual. That might mean that some parts are hard to follow without hearing me talk. I’m going to try and get hold of the audio recording made at the time and will upload a slide-synchronised version of the talk later if possible.

Bonus: 60 Seconds with: Ian Young

I’ve talked about a metadata exchange approach to inter-federation working here before. Since my last update, I think we’ve seen some level of acceptance in both the technical and policy communities that this is — at least in principle — a valid approach, and there is work going on in a variety of places on that basis.

One thing that has become apparent as that work has developed is that we need to look at some of our basic assumptions with a fresh eye: complex problems can be often be simplified by looking at them from a different direction. To that end, Chad La Joie (of SWITCH and Shibboleth) and I have put together Interfederation and Metadata Exchange: Concepts and Methods, the current version of which you can download here:

• concepts-v1.10.pdf

The main aim of Concepts is to provide a framework in which it is possible to think clearly about identity federations in a multi-federation world. This involves first separating concerns and then recombining them in new ways, leading to what we think is probably best thought of as a global metadata layer. There is also coverage of some of the technical implications of such an approach, but we’ve tried to keep that part as light-weight as possible here.

During the recent Internet2 Member Meeting in Arlington, this document was also reviewed by Scott Cantor, Steven Carmody, Josh Howlett, Leif Johansson, Thomas Lenggenhager and Valter Nordh. We are grateful to our colleagues for their many constructive comments, which we have have tried to incorporate faithfully in the current version. I will leave it to those individuals to state whether, and to what degree, they endorse our conclusions.

I’m in Arlington, Virginia this week for the Internet2 Member Meeting. As usual, lots of good hallway conversations and meetings. I had to work my passage this time by contributing a presentation to a joint session on Building on Success: from Identity Federation to Interfederation.

As well as the traditional statistics about how large the UK federation has become, I talked a bit about some of the things I think contributed to its success. This was more in terms of broad concepts than details, the idea being to give people thinking of setting up new federations a guide to some of the tradeoffs involved.

As usual, here’s a PDF version of my slides from the presentation:

• 20090428-Lessons-iay.pdf

Earlier this month, I led a couple of breakout sessions at the UK Serials Group’s conference in Torquay.

I knew that I’d have a wide range of people in the room in each session, so I put together a slide deck that would have something for everyone and talked about different subjects to different levels on each of the two days.

Some of the slides won’t make much sense without explanation, but others do stand alone, I think. If you’re interested, here’s a PDF version of the slides stripped of the animations:

• 20090331-Futures-noanim.pdf

Alastair at UHI comments on my most recent Metadata Interchange document revision. His post highlights a couple of places where I can see I need to clarify what I’m proposing in a future revision. I recently purchased a copy of the OmniGraffle diagramming tool, and Alistair’s post is a good example of why… sometimes a simple diagram really can be clearer than large amounts of plain text. Misunderstandings aside, I think we agree on most things.

One area where I’ve felt for some time we all need to express things more clearly is with regard to that thing we call “trust”. I usually break this down first into “technical” trust (which allows you to know you’re talking to the entity you think you are) and “behavioural” trust (which gives you expectations about the behaviour of a known entity). This isn’t the whole story by all means, but does allow us to see that trust isn’t a singular property; it’s more like a stack or chain of elements that we can build up into something we can actually use.

Any federation can choose to act as a trust broker at many levels; for example, one federation may have strictly enforceable rules controlling member behaviour while another may leave behavioural trust to bilateral arrangements between members (such as the commercial contracts that are usually present in content licensing situations). The UK federation is towards the latter end of the scale: as all federations do, it acts as a broker of technical trust, but mere presence of an entity within the UK federation’s metadata has never carried any behavioural guarantees.

What this means is that if you’re used to operating in something like the UK federation, your stance is already to treat everyone as a potential ray-gun-toting Martian unless you have some specific reason to view them otherwise. Adding more Martians from other federations therefore doesn’t change anything; the important thing that an inter-federation agreement adds is the assurance that the originating federation has registration procedures strong enough to prevent a Martian from masquerading as someone you have a real relationship with, and conversely provides technical trust strong enough to support you in picking the entities you do want to do business with out of the sea of entities you don’t care about.

Many thanks to everyone who commented on the previous edition of Some Notes on Metadata Interchange. I’m in New Orleans for the Internet2 Fall Member Meeting this week, and as I expect to be discussing this area with a number of the other people attending I think this seems like a good time to publish a revision. This edition goes into more detail in some areas, as well as improving sections which needed clarification.

• snomi-v3.pdf is a clean copy of the document for new readers
• snomi-v3-diff.pdf includes change indications for people who have read the previous edition

I continue to welcome comments and discussion. The next edition might be a couple of weeks away, but will likely go into more detail on what I think an aggregation appliance might need to include.

I’ve been working with SAML-based identity federations for a bit over four years now. For most of that time, it’s been obvious that after basic federations like the UK federation and InCommon were up and running in production, the next big question would be how to break out of the “federation of my close friends” model. I’ve spent the last couple of years bending ears at conferences with my own particular views about how this might be done.

Impromptu in-person rants of that kind are very useful for finding out whether ideas have any appeal to other people at all, but I’ve felt for a while that something more coherent might be useful. I’ve therefore put together Some Notes on Metadata Interchange as a personal position paper on this area.

• snomi-v2.pdf is the current version of the document;

• snomi-v2-diff.pdf is the same document with change bars from the previous version. This means you can deduce what V1 looked like if that’s of interest.

I very much welcome comments and discussion on this document. If you’d like to, you can leave a comment here (if you don’t have a TypeKey account, there will be a delay before it’s published) or post on your own blog or just send me e-mail.

Some disclaimers: This document does not represent the official position of any organisation or group, nor is it an attempt to describe any consensus view; it’s purely a personal summary. It’s not a collaborative document, except in the sense that if you change my mind I’ll change the text.

I expect this document to change fairly often over the next few months; hopefully, some consensus-building (and even specification-building) efforts can be budded off from it when that seems appropriate; they will probably be hosted elsewhere.

I was recently asked to give a presentation to a group of people involved with service delivery for the UK federation. The result is Technical Statistics: What they tell us, and what they don’t.

There are some interesting statistics in there (for example, the high degree to which the fairly young JANET Server Certificate Service has already taken off) but the other theme of the talk was that there is an awful lot going on that we probably can’t understand without a lot more direct interaction with the membership.

I’ve also uploaded the slides to slideshare, if you’d like to give that a try.

I gave a presentation to the second meeting of the McShib group last month covering An Identity Provider’s Guide to the Core Attributes (of the UK federation).

I made an audio recording of the presentation. I ran “a bit long” on the day (70 minutes), but once I have edited out the coughing and some of the rambling I’ll post a synchronised audio+slides version.

Links referenced during the talk:

• Technical Recommendations for Participants

• Recommendations for Use of Personal Data

• Attribute Usage page

People have observed that this blog can from time to time be characterised as “a nearly impenetrable thicket of geekitude”. I can’t really argue with that, and I have no intention of making any kind of New Year resolution to “mend my ways”.

On the other hand, I do sometimes wonder about rating my posts in terms of a new metric: how many Wikipedia entries would you have to reference to explain this to the man on the Clapham omnibus?

One of my favourite cartoon sites — xkcd.com — also finds the need to peg the MOTCO-meter once in a while. Responsible Behavior is a good example; I have to rate it a four at least:

Do you agree? More interestingly, what do you think the answer will be in ten years?

I am now a (very junior) notary in the thawte Web of Trust. An assurance from me is worth 10 points towards the 50 required for a personal e-mail certificate with your own name on it.

More details are available for those who are interested.

[Updated 20100118: Thawte recently closed down their Web of Trust and stopped issuing personal e-mail certificates. This article is now of only historical interest.]

As part of one of the more deeply nested yak shaving exercises I’ve been working through recently, I have added MicroIDs to various pages on this site. For example, the header for the main index page for this blog now includes the following elements:

<!-- MicroID for '/' variant of URL -->
<meta name="microid"
  content="mailto+http:sha1:b887e662ed3d811e665ef4a034e018a521a5467d" />
<!-- MicroID for '/index.html' variant of URL -->
<meta name="microid"
  content="mailto+http:sha1:ed938d07588303f4eeee45adfef090221e0c692e" />

A MicroID is a very simple way of making a verifiable statement about the ownership of a page. The specification goes into more detail, but essentially the value you see is constructed by independently hashing your e-mail address and the URL of the page in question, concatenating those results and then hashing once more.

The way you use a MicroID in practice is as supporting evidence for a claim of ownership to some third party who already knows your e-mail address. If you say “I own that page” to such a third party, they can compute the same MicroID value from your e-mail address and the page’s URL and then check for a match within the page’s <meta name="microid"> headers. You can see this claim checking by looking at the “verified” links in my claimID profile.

[2018-02-14: updated to remove the link to claimid.com, which has shut down.]

MicroID is an improvement on the perhaps more obvious approach of just embedding your e-mail address in the page because it doesn’t reveal your e-mail address to things like spam address harvesters. It also improves on a simple hash of the e-mail address by including the URL in the calculation because all pages owned by the same e-mail address are thereby given different MicroIDs. This in turn means that pages can’t be grouped together, even anonymously, by web spiders. Looked at from this point of view, a MicroID is a salted hash of the e-mail address.

I’m pretty sure that you could do the same job with one or even two less hash operations (for example, the URL is known by definition, so hashing it serves no purpose that I can see), but for static pages performance is not a concern. If I was running a large content site with dynamically generated pages, though, this aspect of MicroID might put me off a little.

Note that although a MicroID looks a little like a digital signature (of the URL) it really isn’t; in particular, a MicroID can easily be repudiated because anyone knowing your e-mail address can generate MicroID values “for” you and put them on any pages they please. In other words, you can use it to help confirm ownership of something by a claimant, but not to prove ownership by someone who denies the connection.

Generating the MicroID values for blog pages in particular was made simpler for me by Phil Windley’s MicroID plugin for Moveable Type. I did have to tweak it a little to correspond to the current MicroID spec, as Phil’s plugin as distributed generates what is now thought of as a “legacy” format lacking the scheme and algorithm specifiers.

I’ve previously mentioned my Networkshop 35 presentation in Exeter, and the fact that some of the material I prepared went unused because of lack of time.

As an experiment, I’ve narrated the unused slides and they are now available for download in one of the following formats:

• QuickTime 800x600 H.264 (24MB)
• iPod video format (19.5MB)
• Windows Media 640x480 (26MB)

The presentation is a little under 20 minutes long. Please let me have feedback if you find this kind of thing useful, or for that matter if you find my voice too soporific or annoying. I’m considering doing more along these lines, and it would help to know in advance whether I’d be wasting my time.

Gearheads can read on for technical details…

View from Networkshop 35
Originally uploaded by iay.

I recently attended Networkshop 35 at the University of Exeter and presented a short talk on The UK Federation and Shibboleth: Nuts and Bolts. The idea was to discuss some of the technical challenges involved in the interplay between the UK Access Management Federation for Education and Research and the Shibboleth software, and talk about some future solutions to some of the issues.

As you can see from the integrated slide and video version of the talk available from the conference site, I knew in advance that I’d be short of time so on the day covered only the first two main topics: metadata and discovery.

[2018-03-02: Updated to remove links to the JISC archive of the Networkshop 35 site, which no longer exists and which was not captured by the otherwise reliable Wayback Machine. The video of the talk appears to be lost to the ages.]

I didn’t want to lose my thoughts on “trust” in the federation context, though, so instead of deleting the slides entirely I left them attached to the published version of the presentation. You can download the slides if you’re interested.

The University of Exeter, where Networkshop 35 was held, is fairly photogenic. I’ve uploaded a few snaps to give the idea.

We’re moving house at the end of next month. I’m told that the new neighbours have been told that I’m “in computers” and that they are all looking forward to meeting us. Hopefully this doesn’t mean they want me to fix their broken Windows machines.

The good news is that if I need to explain what I actually do on the identity side of things, the JISC have just come to my rescue by producing a new animation explaining federated access management. The voice-over is pitched at a fairly non-technical level, and the little animated <Subject>s act out the scenes with a surprising amount of expression and a fair bit of wit. They remind me a lot of the little green guys in Darwinia, in fact.

This is not the sort of thing you’d use to communicate with a techie who wanted to know the difference between Browser/POST and Browser/Artifact, but it’s a pretty good introduction to some of the basic ideas for everyone else.

[Link]

[2018-02-15: relinked via the Wayback Machine]

In more UK Federation-related news, I’ve been invited to give a short presentation next week as part of a panel session at the Fall 2006 Internet2 Members Meeting in Chicago.

I’ve been asked to keep the impenetrable geekitude down to non-toxic levels by sticking to a description of policy issues rather than implementation and technology. You can get the other stuff from me pretty much any time.

Today was the official launch of the UK Federation, or the UK Access Management Federation for Education and Research to give its Sunday name. This is a huge deal for everyone involved, myself included: some people have been working towards this point since around 2000 (I’m a relative newcomer, only having put a couple of years into it so far).

In the longer term, this will be a fairly important system for many more people: after all, the UK Federation is a federated identity framework for the whole of the UK education and research sectors, which I’m told involve perhaps 18 million people. If we do our job well over the next few years, though, the best case is that like all good infrastructure it will just sink down below the point where people even notice it. That’s a hard job, and we’ve only just started on it.

I generated my first PGP RSA keypair way back in 1993. Some friends and I played around with PGP for e-mail for a while, but at the time few people knew about encryption and even fewer cared: the “no-one would want to read my mail” attitude meant that convincing people they should get their heads round all of this was a pretty hard sell. The fact that the software of the day was about as user-friendly as a cornered wolverine didn’t help either.

The PGP software had moved forward a fair bit both technically and in terms of usability (up to “cornered rat”) by 2002, when I generated my current DSS keypair. By this time, it was pretty common to see things like security advisories signed using PGP, but only the geekiest of the geeks bothered with e-mail encryption.

Here we are in 2006: I still use this technology primarily to check signatures on things like e-mailed security advisories (I use Thunderbird and Enigmail), but I’ve finally found a need to use my own key, and it isn’t for e-mail.

Over the years, PGP (now standardised as OpenPGP) has become the main way of signing open source packages so that downloaders have a cryptographic level of assurance that the package they download was built by someone they trust. Of course, the majority of people still don’t check these signatures but systems like RPM often do so on their behalf behind the scenes.

I’ve agreed to take on some limited package build responsibilities for such a project recently, so I’ve installed the latest versions of everything and updated my about page so that people can get copies of my public keys. Of course, there is no particular reason anyone should trust those keys; this is supposed to be where the web of trust is supposed to come in, by allowing someone to build a path to my keys through a chain of people they trust (directly or indirectly). Unfortunately, my current public key is completely unadorned by useful third-party signatures. If you think you can help change that (i.e., you already know me, already have an OpenPGP keypair and would be willing to talk about signing my public key) please let me know.

Phil Windley, Kaliya Hamlin and Doc Searls are running the Internet Identity Workshop 2006 this coming week. It sounds interesting, but Mountain View is a little out of my way.

On the other hand, who can do other than stand in awe in front of the Workshop logo, shown here? A dog, wearing a mask, sitting in front of a computer: perhaps the oldest gag in the digital identity game. I’d say “priceless”, but in fact you can buy merchandise.

[2019-05-02: Removed merchandise link, as the items are no longer available.]

Of course, the real reason I was in Windermere was not to photograph ducks but to present some slides on the discovery problem in Shibboleth. You can download a copy of the presentation “WAYFs and Discovery” here (1.4MB PDF).

The abstract (accidentally omitted from the meeting material) was:

The standard model of Identity Provider discovery in Shibboleth deployments is that of a federation-supplied, central discovery service called a WAYF. Although an essential backstop, this approach has significant shortcomings. We present some recent work in the area of multi-federation WAYFs, and review alternative discovery technologies (both present and future) that allow deployers to improve the user experience.

My co-author Rod Widdowson can be found here.

Every so often I vanity-google my own name, just to see what happens. I’m sure you do the same; who can resist?

I’ve been the number three “Ian Young” (according to Google) for a while. At number four is a chap at Intel who also shares a middle name with me, although as he apparently has 34 patents and invented the insides of lots of cool things he really by rights ought to be higher. He gets top billing for “Ian Alexander Young”, though.

Judging by the logs, some people find it easier to google for “Ian Young” than they do to remember the URL for this site. When looking at the server logs for the last month, though, I discovered that a fair number of people look for “iay” too. I’ve been using that identifier to log into things since about 1979 and sometimes have difficulty remembering my “human name”, but I didn’t realise this applied to other people too. Of course, they may have been looking for The Institute for the Study of Antisocial Behaviour in Youth, which comes above me in that search. No, the picture of the antisocial youth on their web site isn’t of me.

This is all rather strange but to me the most bizarre thing of all is that my Second Life avatar gets two of the only six hits for “Alexander Daguerre” (with the quotes this time). I suppose if I had thought about it, I could have looked for a combination Google had no record of and had the results page all to myself. How long before people start choosing names for their children that way?

Speaking of identity, Dick Hardt of Sxip gave a cracking keynote at this year’s Open Source Conference.

If you’re at all interested in digital identity (and you’re not allergic to Larry Lessig’s presentation style), I highly recommend spending taking the fifteen minutes required to watch this. It is very light on technical details, but gets across the critical differences between “old style” digital identity and the so-called “Identity 2.0” systems that are starting to emerge. It even manages to be entertaining while it does so. And the pictures of a Vancouver “Cold Beer and Wine” store bring back memories…

I’ve been scanning old entries from Kim Cameron’s Identity Weblog, catching up on things I missed the first time round. I’m only up to January so far, but there’s a lot of good thinking in there as well as links to some gems. One of the things I hadn’t seen before is an ACLU advertisement portraying a world in which the local pizza delivery company knows far more about you than they need to.

I find this to be quite a plausible and chilling picture of Identity Gone Wrong, although I’d probably worry more about those in authority having this kind of ability than about the pizza company. I’m sure there are people who would say that such things couldn’t happen, and that the ACLU are being needlessly alarmist. However, as you’re watching each of Kim’s Laws of Identity being broken, it’s quite easy to hear someone softly saying “we’re doing this for your convenience” or “we’re doing this for your security” in the background.

[2019-05-02: ACLU have a “10 Years Later” piece here.]

I was conned into doing a formal presentation for about 80 people the other day. Normally, I’m quite happy with smaller team or client presentations to half a dozen or a dozen people; the sudden scaleup put me in a mental state where (at least to myself) I sounded like a crazed televangelist. Maybe it wasn’t that bad in reality; some people even laughed a little at the flying pig jokes and no mouldy fruit was thrown.

The good news was that almost all of the technology worked perfectly. For example, the normal experience of a tiny projector that sounds like a badly maintained lawnmower was replaced by a huge bright fixed back-projection screen that everyone could see clearly. No hunting around for books to prop the projector up was required. No “where’s the remote, Bob?” conversations because I brought my own (I hate just standing behind the lectern). The exception was the sound system: all the microphones seemed to be broken. I’m always a bit loud anyway, so this wasn’t a problem.

If you’re curious, you can download a PDF copy of the presentation.

[2018-07-09: added a link to a PDF of the presentation. Added “identity” tag.]