Skip to Content.
Sympa Menu

microid - Re: [Microid] MicroID hashing algorithm(s) and normalization

microid AT lists.ibiblio.org

Subject: Microid mailing list

List archive

Chronological Thread  
  • From: eran AT yedda.com
  • To: Chris Roos <chrisjroos AT gmail.com>
  • Cc: "microid AT lists.ibiblio.org" <microid AT lists.ibiblio.org>
  • Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization
  • Date: Sat, 09 Dec 2006 03:31:06 -0700


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




Archive powered by MHonArc 2.6.24.

Top of Page