FAM Futures

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:



Avoiding the Martians

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.


Metadata Interchange V3

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.


Metadata Interchange Notes

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.


UK federation Technical Statistics

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.


McShib Talk on Core Attributes

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:


Responsible Behavior

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 — — 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:

Never bring tequila to a key-signing party.

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

Thawte WoT Notary

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.

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.

"Trust" Bonus Track

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:

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…



Subscribe to RSS - Identity