Microid mailing list

[jer <jeremie AT jabber.org>]

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