Microid mailing list

["Mrinal Kant" <mrinal.kant AT gmail.com>]

On 9/8/07, jer <jeremie AT jabber.org> wrote:
>  While I like the spirit of this, it makes it awfully painful to implement
> just to check/validate a microid when you consider it part of the actual
> MicroID spec.  I don't think the value gained is worth the overall pain :(

Sure, it adds pain. But that would be not-so-great a price to pay for
a far greater flexibility. And I also agree that what I am suggesting
is perhaps a layer on top of MicroID (clarified to me by Peter
Saint-Andre). Thus, I may have made a poor choice of subject for this
thread. But I think, for MicroID to be really usable by multiple sites
to which users may choose to reveal different identities while
claiming the same uri, this layer is needed. MicroID will change but
all consumers will not all change with it or in sync with each other.
Therefore, the minimum that one has to add to the MicroID is a version
number. But then again to put hashes corresponding to 3 versions and
two identities, one has to work on six entries in all the claimed uri.

Wouldn't it be far easier to have it all in one place - a place that
could probably be offered by some service provider or it could be your
own; like with OpenID. And just point to this place in the uri which
is being claimed. That way, there would be just one entry to work
with, and that too when you decide to change the place where all
MicroIDs reside.

>
> What your suggesting is already "ideally" workable though if you consider
> using links and the rel attribute, and just link to your homepage where the
> MicroID actually is published?
>

You are right. But I avoided using <link rel="..." .../> because the
freedom available with meta is not available with link as can be seen
from http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/
Nothing new about that. MicroID already sits in meta in the html head.

What I have in mind is something like the following:

// 1. The consumer goes to the claimed uri (e.g.,
http://mrinalkant.blogspot.com/)
//    and looks for, say, a meta tag like
//    <meta content='http://www.geocities.com/mrinal_kt9/microIdClaims.xml'
name='microid-xml'/>

// 2. The consumer reads the xml as stated in the meta tag and looks
for the microid(s)
//    for the claimed uri. See
http://www.geocities.com/mrinal_kt9/microIdClaims.xml

// 3. The consumer goes through these ids until a match is found. Or
else, the verification fails.
//    The consumer may go through all or only a few based on some
criteria that can be presented
//    in the xml in n number of ways.

I feel that providing an independent place for the ids which should
only be referred to by the claimed uris is a better architecture too
apart from providing unlimited flexibility to improve MicroID without
being obstructed by any issues like legacy implementations, past
errors and backward compatibility. Obviously, because many ids can
exist side by side. My insistence on flexibility comes from my
inability to anticipate the future.

- Mrinal.