MicroID

MicroID is a decentralized identity protocol. It was originally developed in 2005 by Jeremie Miller . A MicroID is a simple identifier comprising a hashed communication/identity URI (e.g. email, OpenID, and/or Yadis) and claimed URL. Together, the two elements create a hash that can be claimed by third-party services.

Ben Laurie demonstrated privacy problems with it in 2006 ,[1] as did Chris Erway in a Brown CS Technical Report in 2008[2]

MicroID exchange

Here is an example of a MicroID hash, in pseudocode:

MicroID = sha1( sha1("mailto:user@example.com") + sha1("http://example.net/") );

The computed MicroID would then be placed on a web page to be claimed. A verifier, which would independently generate the MicroID, would then visit the page to see if the generated MicroID is the same as the MicroID on the page. If they are the same, a claim exists.

MicroID is based on a communication URI. Since both the MicroID provider and verifier can verify the communication URI, a proper MicroID implementation allows for trusted identity claims.

Security limitations

A MicroID is essentially a content URI signed with an email address or other attribution. Since the content URI is known for comparison purposes, a MicroID claim can be forged by anybody who knows the communication URI (e.g. email address) associated with the identity.

In particular, since a verifier must generate the MicroID in order to compare it, it follows that any party who is trusted to verify a user's MicroID must also be trusted to generate new authorship claims with it.

So if you can verify - you can forge.

Or in other words anyone (e.g. Alice) who can verify someone (e.g. Bob) their MicroID on a resource 'X' can also generate (spoof) a MicroID on any other document (e.g. Alice can generate a valid MicroID for a document Y, not equal to X, in Bob's name).

Assuming the identity is not known (e.g. 1) the publisher has chosen to remain anonymous and 2) denies others the ability to verify the MicroID claim until a time in the future when he or she reveals her identity) then someone with email addresses can perform a trivial dictionary attack to find ownership of resources, someone with a URI can perform a trivial dictionary attack to find an email address.

So the (only) remaining usecase is where an entity generates a strong cryptographic nonce (e.g. a UUID); uses this to publish documents over time—and at some time in the future reveals the UUID as to prove that he or she wrote those documents (and accepts that from that point forward anyone can make any claims on his or her behalf).

Privacy limitations

As explained above, a MicroID is a hash made from a public URI and a semi public email. Those who know both can verify the identity claim on a page. The hashing helps to hide the semi public email address to people that should not know it, in particular spammers.

However, research[2] on popular social websites such as Last.fm, Digg and ClaimID show that a brute-force attack can decrypt the email address in 20–25% of the cases.

The brute force attack guesses email addresses derived from the public user name and other information available on the social websites, and thus only checks a dozen or so candidate addresses per MicroID. Despite this, the study showed a simple attack like this one could still be successful one quarter of the time while spending a fraction of a second to check all candidates for each user. The hashing scheme thus does not guarantee the privacy of the email address.

Architecture of a MicroID claim

An example of a successful MicroID claim is as follows:

  1. A user signs up for a web service. That web service verifies the user's email, and creates public web pages for the user that contain a MicroID. That MicroID comprises the hashed email (communication URI) and the URL of the webpage.
  2. The user then signs up for a verifier service. The service also verifies the user's email.
  3. The user inputs the URL of the page she wishes to claim into the verifier service. The verifier service computes the MicroID and attempts to verify the MicroID in the claimed page.
  4. If the MicroID in claimed page is the same as the one in the verifier service, a claim exists. The verifier will then claim ownership of the page.

MicroID and the DOM

MicroID allows for the claiming of semantic HTML elements. For example, a MicroID inserted in a block-level element will constitute an ownership claim of anything in the element. A MicroID inserted in the header of a page will constitute an ownership claim of the page. Claims are only verifiable at the granularity of URIs.

Known MicroID providers

The following web services provide MicroIDs to their users:

Known MicroID verifiers

The following web services verify MicroID claims:

gollark: But what if I want to process bees instead?
gollark: I'm sure you can represent data as it somehow.
gollark: Maybe I'll just use an infinitely recursive lazily evaluated list. That would probably be something I could implement.
gollark: Strings are NOT GENERALIZED and TOO TIED TO THE INPUT!
gollark: LASER BEES ACTIVATED

References
  1. Laurie, Ben (2006-03-28). "MicroID". Retrieved 2009-05-08.
  2. Erway, Chris (2008-08-22). MicroID considered harmful (to privacy). Brown University Computer Science. Retrieved 2009-05-08.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.