[Microid] MicroID hashing algorithm(s) and normalization
Peter Saint-Andre
stpeter at jabber.org
Thu Dec 7 12:13:02 EST 2006
Eran Sandler wrote:
> I think it's up to the site generating the microid.
>
> For example, if at Yedda we want to use email instead of OpenID we will
> genereate it according to the format Yaniv suggest:
>
> <meta name="microid"
> content="email+url:sha256:e5de55ef248b5f8b06d38253cac0ae725d6455fb">
>
> After all, I'm generating the id so I know what do to.
>
> When a verifier comes and see this microid content, it will know that it
> needs to hash the email using SHA256, hash the URL using SHA256 and hash
> both of them together using SHA256 to get the microid value.
>
> The verifier will have to understand that the value "email" refers to email
> and if it is replaced with openid it is openid.
Aha, OK, so this is for the sake of the verifier.
I still think "url" (or http) is better than "openid" because as far as
I can see the URIs are opaque. If you say that it's "email+openid" then
you must have some way to figure out that the HTTP URL in fact is an
OpenID service -- and I don't know if you can do that programmatically.
But if we just base it on the URI scheme then we can do things like this
(here I use mailto because that's the URI scheme -- why introduce
mappings from mailto to email and http to url if we don't have to?):
mailto+http
sip+xmpp
http+pres
http+aim
Etc. It's all just based on the URI scheme. Whether the resource at that
URI in fact has some other kind of fancy semantic is irrelevant AFAICS.
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.ibiblio.org/pipermail/microid/attachments/20061207/2056ec38/attachment.bin
More information about the Microid
mailing list