Skip to Content.
Sympa Menu

microid - Re: [Microid] MicroID hashing algorithm(s) and normalization

microid AT lists.ibiblio.org

Subject: Microid mailing list

List archive

Chronological Thread  
  • From: Peter Saint-Andre <stpeter AT jabber.org>
  • To: microid AT lists.ibiblio.org
  • Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization
  • Date: Tue, 28 Nov 2006 12:44:24 -0700

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.24.

Top of Page