Microid mailing list

["Eran Sandler" <eran AT yedda.com>]

> Right. This is addressed by the URI spec.

> BTW, these are URIs, not URLs. I can visualize MicroID applications that
> don't use HTTP URLs -- think SIP, XMPP, etc.

Point taken :-)
These are URIs, not just URLs.


> So the authority component is always domain.tld? That is potentially
> problematic given the market for third- and fourth-level domain names.
> I'm not sure how to handle that.

The reason I have said to cut down the "www." part is mainly because I don't
believe the "www." part to be a real third or fourth level domain name.
Everything that does not starts with a "www." is should be good to go, so
that when I have something like "erans.microid.org" (which a lot of sites
use nowadays for profile related information and the "user's homepage")
would be considered a valid domain name that will be used in the URI.


> I disagree. The point is to normalize down to something like this:
> http://microid.org/

Like Fred, I do believe that there should be a different microid for each
page, mainly due to the fact that in the same site I might want to have to
identities and having the same microid will expose me to some degree (if I'm
using the same Email on both identities). This is actually a privacy issue.


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

You are right that having too many protocols is a bit too much, but since
SHA1 has been proven to be a bit shaky, I don't think we want the whole
system to crash down just because we reached to the point where we got the
same hash value for two different underlying values.

On the other hand, each protocol has its computation overhead and that is
something we need to give some attention when choosing a hash algorithm.

I still believe that we should mark the protocol used within the microid
(like the suggestions made in the blog post) even if we are going to
eventually use only one hash algorithm.

Eran

-----Original Message-----
From: microid-bounces AT lists.ibiblio.org
[mailto:microid-bounces AT lists.ibiblio.org] On Behalf Of Peter Saint-Andre
Sent: Tuesday, November 28, 2006 9:44 PM
To: microid AT lists.ibiblio.org
Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization

Fred Stutzman wrote:
> On Tue, 28 Nov 2006, Eran Sandler wrote:
> 
>> Hello all,
>>
>> In Yedda, instead of normalizing the URL used, we are using the URL from
the
>> request itself (as it is passed in the HTTP header) and use it to create
the
>> microid.
>>
>> It does raises a few issues, one of which is the fact that we get two
>> different microids if we access a page with or without a trailing slash.
>>
>> The other is the unnecessary re-computation of the microid every request.
>>
>> My suggestion regarding normalization is relatively easy:
>>
>> -          Make sure the URL is lower cased

Right. This is addressed by the URI spec.

BTW, these are URIs, not URLs. I can visualize MicroID applications that
don't use HTTP URLs -- think SIP, XMPP, etc.

>> -          If the hostname start's with "www." (i.e.
>> http://www.microid.org/somewhere/), remove the "www." part (i.e.
>> http://microid.org/somewhere/)

So the authority component is always domain.tld? That is potentially
problematic given the market for third- and fourth-level domain names.
I'm not sure how to handle that.

>> -          If the URL ends with a file (including a file extension, i.e.
>> http://microid.org/somewhere/this.html), leave it as it is

I disagree. The point is to normalize down to something like this:

http://microid.org/

So you'd have the same MicroID at any page at that domain (or subdomain
if we figure that part out).

>> -          If the URL ends with a directory or path (not a file, i.e.
>> http://microid.org/somewhere), make sure it has a trailing slash at the
end
>> (i.e. http://microid.org/somewhere/)

See above. Use http://microid.org/

That is, I don't think we want per-page claims. At least not in general.
Do you have a specific use case where that's important?

>> Regarding hashing algorithm, I liked the suggestion specified in the blog
>> post's comments (http://microid.org/blog/?p=4)of specifying the exact
>> algorithm near the hash value. The main problem with this approach is
that
>> the various systems like claimid.com will have to handle quite a few of
>> these hashing algorithms (unless the spec specifically gives a couple of
>> options and that's it).
> 
> I think I agree with you on this though I can't claim to be an expert on 
> hasing algos.  It is easy for verifiers to verify aginst a number of 
> predictable outcomes.  Once we agree on a spec we can decide what becomes 
> legacy and what becomes mainstream.  It will be easy for verifiers to 
> maintain legacy for some time.

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