Microid mailing list

["Paco NATHAN" <ceteri AT gmail.com>]

Fred,

Those two arguments sound good. The first one, about "sameness" and
identity between A and B - I'd like to understand your thinking on
that point better.  Your second point about crypotographic hashing
seems essential for a problem statement (and starts to answer my prev
question...)

I have a hunch that a reasonable "problem statement" for MicroID might
need to be articulated in at least a few cases.


There's a related idea - from what I understand of it - where Kim
Cameron argues about allowing a user to select from multiple claims -
for better security, to avoid replay attacks using relatively
static/known/guessable personal data:
http://www.identityblog.com/?p=651

The one-way hash aspect of MicroID seems to fit well with whatever
comes out of the "InfoCard vs. OpenID" debate on that point. Since an
application could embed multiple hashes generated from the owner's
different communication URI/cardspace claims - then MicroID could help
make the "sharing" of identity more robust in the way that Cameron
suggests.

That's hardly a "problem statement", but maybe cuts closer to a list of 
issues?


Another problem that MicroID helps resolve involves using it as a
microformat.  It's not represented quite like other microformats, but
close enough to be machine-readable (I'd imagine format could be
improved in later MicroID spec versions?)

For example, my employer has a need for crawlers to read web content
and automate decisions about a user substantiating their online
identity: combining page claims, online reputation, relationships,
etc.  We've integrated ClaimID API for a portion of that. Since a user
could cite content just about anywhere online, MicroID helps us
qualify the reasoning and analysis which come out the other end of our
crawler.  Ultimately we hope to use GRRDL
http://www.w3.org/2004/01/rdxh/spec to pull RDF out of the web content
and reason based on it - so microformats come in handy, to get to the
point of GRRDL. That leads to a "data quality" argument for MicroID,
in this case to help establish about the reputation of a user.

In another area we're looking to use MicroID, the claimed URL
represents geolocation info, which is perhaps another aspect of your
scalability argument - on the claimed URL side.  That's a weird one,
because in practice it might imply embedding/encoding a geo
microformat into the claimed URL element of a generated hash.  Not
sure that's ready for prime time yet, in terms of "problem statement",
but we're looking ahead.

Thanks,
Paco

HeadCase Humanufacturing
http://headcaselabs.com


On 1/18/07, Fred Stutzman <fred AT metalab.unc.edu> wrote:
> MicroID is a simple, extensible way for third parties to verify sameness
> between two web-based resources.  For example, Sarah may have accounts on
> site A and B.  With MicroID implemented on sites A and B, these sites can
> verify sameness between A and B, establishing a useful identity link.  Of
> course, the communication identifiers must be verified in both A and B,
> though this is common practice for websites.
>
> The reason for the crypotographic hashing is twofold.  First, it provides
> reasonable protection against the scraping of communication identifiers by
> spammers.  Second, it allows the MicroID to contain more than one hashed
> element (in this case the communication URI and the claimed URL).  This
> allows extensibility as the protocol scales to accept new forms of
> communication URI's or URL.  That is, by using the hash, the MicroID
> maintains simplicity and affords great scalability.