Skip to Content.
Sympa Menu

microid - Re: [Microid] Summary and Hello

microid AT lists.ibiblio.org

Subject: Microid mailing list

List archive

Chronological Thread  
  • From: jer <jeremie AT jabber.org>
  • To: microid AT lists.ibiblio.org
  • Subject: Re: [Microid] Summary and Hello
  • Date: Mon, 11 Dec 2006 13:21:30 -0600

Hey guys! My inbox is a mess so apologize about missing most of the thread(s) thus far, hopefully this will catch up :)

1) URL Normalization

We should not make assumptions about capitalization or www or *. or
co.uk - calculate the URL as it is. The verifiers will work it out -
the publishers should calculate and publish with the simplest of steps
with the least number of assumptions built in to those calculations.

+1, I'm much more into organic solutions, it's too easy to over- specify things that will just sort themselves out :)

2) Hashing algorithms

We should stick to SHA1 for now - the point about this not being an HMAC
or cryptographically secure... it doesn't matter all that much as the
keys themselves aren't secret. The claim itself is being made by two
parties who have independently verified the communication identifier.
That said, the point against SHA1 because of the potential for collision
(shown in feb 2005), I think might hold more water and should be
discussed more.

Collisions don't matter, nor does the extra work that HMAC does. The point of a microid is to obscure the original source (which a sha1 absolutely does), it doesn't matter how crypto-secure the result is as long as it's not simply reversible.

It's too easy to misunderstand this though and think it's important somehow, that's a communication issue about the use cases of MicroID :)

3) MicroID is not a microformat

Microformats are being 'created' to map to current practice (roughly
calculated as 80% of use cases in the wild). MicroIDs are used on less
than 10 sites as far as I know and does not constitute anything close to
the bar set for talking to the microformats community. We move ahead
with the formalization of the spec here itself - and other conversations
will follow as needed.

I consider there to be two parts of microformats: structural and human. The structure is the divs, spans, tags, attribs, etc, whereas the human is the readable contents. MicroID is a structural element without a human component in it's purest form, but the original goal is to benefit other microformats and create new ones that use MicroIDs as an integral structure.

The most important use-case for me is open distributed reputation. I want a microformat along the lines of the example:

<span class="score microid- a9993e364706816aba3e25717850c26c9cd0d89d">5</span>

The simplicity is that the score is relative only to the url in which it was found (slashdot, blogger comment, flickr account, etc), and tied semantically to a MicroID. Any service can crawl and aggregate this microformat which depends structurally on a MicroID, creating a relative scoring system between the different engines out there (a /. 5 relative to a digg rank, etc).

It's just an example, but the point is the potential relationship to Microformats.


4) Default publication of MicroID

I do think that sites that implement MicroID should offer a choice of
whether to publish a microID to a user. And I think the admin should
select a good default based on the particulars of that software
installation. The software itself should probably ship with the default
for the admin setting set to [off] - although that will slow adoption
perhaps. I agree with the sentiment expressed earlier on this list.

The potential harm here is that someone could deduce ownership even if the owner wanted the account to remain anonymous, and I agree that would be bad in general. It depends mostly on the context of course, but it's important to protect privacy first if there's any question about the intent of the content being ID'd.

Again, apologies for missing out on a month or more of pointed discussion.

Ditto!

Jer





Archive powered by MHonArc 2.6.24.

Top of Page