Microid mailing list

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

Not sure why that would be. Maybe Fred can shed some light on it. :-)

/psa

digital spaghetti wrote:
> Hi I'm new to the list, and I appoligise I can't provide full examples
> as I'm on my blackberry just now.
> 
> I agree though this needs to be settled on. I've created a module for
> drupal that generates microID's and embeds them as a meta tag in the
> header (and using JS also adds a class to the node's main div tag).
> I've confirmed that the url it's using is correct and for myself the
> correct email address, but the hash I get is different to the one on
> claimID so it never validates my links.
> 
> I'm using sha1 to encode the hash, like this:
> 
> 
> $hash = sha1(sha1(email) . Sha1(url));
> 
> It's the same algorithim as the wordpress plugin that's available.  If
> you like I could post an example on here tommorow. You can also see
> the module at work on my site below.  Just click on any blog post then
> view the rendered source (with firebug or web developer, standard view
> source does not work correctly).
> 
> Tane
> http://digitalspaghetti.me.uk
> 
> On 12/5/06, Peter Saint-Andre <stpeter AT jabber.org> wrote:
>> 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