[uf-discuss] Fwd: Re: [Microid] MicroID hashing algorithm(s) and normalization

[digital spaghetti]

---------- Forwarded message ----------
From: digital spaghetti <digitalspaghetti at googlemail.com>
Date: Tue, 5 Dec 2006 19:24:40 +0000
Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization
To: Peter Saint-Andre <stpeter at jabber.org>

Hi I'm new to the list, and I appoligise I can't provide full examples
as I'm on my blackberry just now.

I agree though this needs to be settled on. I've created a module for
drupal that generates microID's and embeds them as a meta tag in the
header (and using JS also adds a class to the node's main div tag).
I've confirmed that the url it's using is correct and for myself the
correct email address, but the hash I get is different to the one on
claimID so it never validates my links.

I'm using sha1 to encode the hash, like this:


$hash = sha1(sha1(email) . Sha1(url));

It's the same algorithim as the wordpress plugin that's available.  If
you like I could post an example on here tommorow. You can also see
the module at work on my site below.  Just click on any blog post then
view the rendered source (with firebug or web developer, standard view
source does not work correctly).

Tane
http://digitalspaghetti.me.uk

On 12/5/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> Yaniv Golan wrote:
> >> Personally I don't see a big difference here between HMAC and SHA1
> >> here because we're not attempting to provide cryptographic
> >> assurance.
> >> I think we need to settle on one algorithm and leave it at that.
> >> Fewer options, fewer ways to go wrong.
> >>
> > Fewer options are good, but it's also good to indicate which option
> > you're using, just in case you'd like to change your mind later.
> >
> > So, my microid for my Yedda profile page:
> >
> >    http://yedda.com/people/9512186217351/
> >
> > which right now is:
> >
> >    <meta name="microid"
> >        content="e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> >
> > Would change to
> >
> >    <meta name="microid"
> >        content="sh1:e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> >
> > Small change, but it allows future revisions of the spec to support
> > legacy support. To rephrase the old saying, "better metadata than
> > sorry" :)
> >
> > In fact, given the introduction of OpenID into the discussion, I think
> > that it would make sense to load the content with additional metadata,
> > such as the element used as the verification anchor:
> >
> > In the case of email:
> >
> >    <meta name="microid"
> >        content="sh1:email:e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> >
> > In the case the OpenID identity is used instead of email:
> >
> >    <meta name="microid"
> >        content="sh1:openid:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>
>
> I have no deep objections to that approach since it's more flexible.
> However I think we'd want to at least maintain a registry of values for
> the hashing/MAC algorithms and the element (or elements?) used.
>
> So for hash/MAC we'd have things like sha1, sha256, hmac.
>
> Do we need to list both elements that are used to make the microid?
> E.g., the two elements could be an HTTP URL and a mailto: URI, two
> OpenIDs, an OpenID and a Jabber ID, or whatever.
>
> Peter
>
>
>
>