Microid mailing list

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

Yaniv Golan wrote:
>> 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.
>>
> Fewer options are good, but it's also good to indicate which option
> you're using, just in case you'd like to change your mind later. 
> 
> So, my microid for my Yedda profile page:
> 
>    http://yedda.com/people/9512186217351/
> 
> which right now is:
> 
>    <meta name="microid"
>        content="e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> 
> Would change to 
> 
>    <meta name="microid"
>        content="sh1:e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> 
> Small change, but it allows future revisions of the spec to support
> legacy support. To rephrase the old saying, "better metadata than
> sorry" :)
> 
> In fact, given the introduction of OpenID into the discussion, I think
> that it would make sense to load the content with additional metadata,
> such as the element used as the verification anchor:
> 
> In the case of email: 
> 
>    <meta name="microid"
>        content="sh1:email:e5de55ef248b5f8b06d38253cac0ae725d6455fb" />
> 
> In the case the OpenID identity is used instead of email:
> 
>    <meta name="microid"
>        content="sh1:openid:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>

I have no deep objections to that approach since it's more flexible.
However I think we'd want to at least maintain a registry of values for
the hashing/MAC algorithms and the element (or elements?) used.

So for hash/MAC we'd have things like sha1, sha256, hmac.

Do we need to list both elements that are used to make the microid?
E.g., the two elements could be an HTTP URL and a mailto: URI, two
OpenIDs, an OpenID and a Jabber ID, or whatever.

Peter

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