Microid mailing list

["Chris Roos" <chrisjroos AT gmail.com>]

On 11/29/06, Yaniv Golan <yaniv AT yedda.com> 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.
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.shtml
>
> 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 disagree.  Sounds like over-engineering based on theory not
practice.  Playing devil's advocate, what's the point of designing for
legacy use?  This microid stuff is relatively new (in terms of
deployment not necessarily concept), why waste time working out how it
might go out of date.  Surely it'd be better to get the spec out there
and get people using it.  Then we'll _know_ the actual limitations.
What's the reason for wanting to specify (and by implication, change)
the hashing algorithm?  If it's security concerns, does it _really_
matter if two pages by different authors have the same microid?  If
it's to give microid publishers flexibility then what happens if a
publisher rolls out a new hashing algorithm that none of the verifiers
support?

Same goes for additional communication identifiers.  I'd guess that
email is by far the most common a the moment.  Apart from openid*, are
there any others that people could practically use right now?

So, lets assume we go with the spec as it is (apart from maybe some
uri normalisation).  If at some point in the future the spec is
updated to require the hashing algorithm, 'legacy' will be defined by
the lack of hashing algorithm in the microid.

* I assume that openid as an identifier is based on the fact that I
will have logged into both my verifier account and 'microid publisher'
account (e.g. del.icio.us) using the same openid account.  Can someone
correct me if I've missed the point on this one?

Cheers,

Chris

> Yaniv
>
> --
> Yaniv Golan
> My profile on Yedda: http://yedda.com/people/9512186217351/
>
> _______________________________________________
> Microid mailing list
> Microid AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/microid