Microid mailing list

[eran AT yedda.com]

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