distributed identity for the cert-centric

Jens Alfke jens at mooseyard.com
Thu Feb 2 21:17:49 UTC 2006

I've been talking with some people at work about YADIS, OpenID, LID,  
etc. Some people come at "identity" from a more traditional PKI  
mindset: they want to have a certificate to represent an identity,  
use the public key in that cert for authentication, and use a  
certificate-revocation-list protocol to periodically check its validity.

This is somewhat different from the approach taken by LID and,  
especially, OpenID. I'm wondering how to bridge this. I'm by no means  
an expert at security, crypto or distributed-identity, but that won't  
stop me from offering some ideas. Stop me if I go off into the weeds:

0. (I'm using LID in this example because I know it uses key-pairs  
and is pretty extensible. As far as I know, OpenID is keyless and is  
aimed more specifically at web-based single-sign-on.)
1. A LID identity server already generates a key-pair and uses  
signatures to respond to identity challenges.
2. The key-pair can easily be wrapped in a self-signed X.509 cert.
3. The cert can include a signed copy of the identity URL it's  
associated with.
4. There can be (or perhaps already is) a LID profile to fetch such a  

Given that, the mechanism for verifying such a cert (if you didn't  
get it directly from the identity URL) would be to extract its URL,  
use the LID protocol to fetch the current cert from that URL, and  
compare the key. And rather than checking a revocation list, you just  
periodically repeat that process. (The cert can be given a short  
expiration time, to enforce this.)

In other words, to revoke your identity cert if your private key is  
compromised, you just have your LID server generate a new key-pair. A  
nice side effect is that as the holders of the old cert re-verify it,  
they end up with a copy of the new, valid one.

A simple protocol like this might make it feasible to write a plug-in  
that would add distributed-identity support to traditional cert-based  
security implementations, not to mention making URL-centric  
distributed identity more understandable and approachable by those  
used to more traditional security mechanisms.

Does this seem reasonable?


More information about the yadis mailing list