[Microid] MicroID hashing algorithm(s) and normalization

eran at yedda.com eran at yedda.com
Sat Dec 9 05:31:06 EST 2006


> -------- Original Message --------
> Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization
> From: "Chris Roos" <chrisjroos at gmail.com>
> Date: Sat, December 09, 2006 2:45 am
> To: "Peter Saint-Andre" <stpeter at jabber.org>
> Cc: "microid at lists.ibiblio.org" <microid at lists.ibiblio.org>
> 
> On 12/7/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> > Evan Prodromou wrote:
> > > On Wed, 2006-06-12 at 10:33 -0700, Peter Saint-Andre wrote:
> > >
> > >> But how do we know programmatically when we create the microid that a
> > >> given URL is an OpenID?
> > >
> > > You mean, how do we know that the first string that we're putting into
> > > the hash is an OpenID? Probably because the user said, "here is my
> > > OpenID", and maybe they validated it using the OpenID protocol. Or maybe
> > > we got it out of our database from the user_openid table.
> > >
> > > The big question is: why would we care what it is? As far as the microid
> > > format is concerned, it's just a string.
> > >
> > > For the publisher of the resource, they can add a microid <meta> tag for
> > > each ID they have for the user (email, OpenID, whatever).
> >
> > I agree. So why do this?
> >
> >    ... content='openid:sha256:foo' ...
> >
> > If it's really opaque, why do we specify that it's an openid or an
> > i-name or anything else? Just hand over the microid and the other end
> > can figure out what it is (if it even cares, which I doubt).
> 
> Agreed.  The verifier will already have to have an existing
> relationship (email, openid or more that I can't think of - are there
> any?) with the user.  They can therefore just try each one in turn.
> 

Why not help the verifier? It's not like it's actually going to be hard for the implementer of microids to implement it? They will probably use a set of standard libraries for each of the common languages (I'd be more than happy to contribute to such a thing) that will generate all the necessary information for them without them giving it a second thought.

Why make the verifiers do more work, waste more processing time, network bandwidth and time if you can avoid it?

Why not making it easier for people encountering microids in a web page to read the microid, skim through the spec and understand exactly what is the content of a given microid?

Regarding backwards compatibility, since it seems that hashing functions of any kind are not exactly immuned to attacks (someone just successfully attacked MD5 and SHA1 last year or so), why not have it built into the protocol to know what is being used and to save the option of not changing the spec (or at least only have a minor change) to support a new hashing algorithm (which I'm sure we will need at some point or another)?

Eran


More information about the Microid mailing list