Microid mailing list

[Peter Saint-Andre <stpeter AT jabber.org>]

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