[OpenID] OpenId recycling and trust

[Thomas Matysik]

Hi All,

I seem to be very late in commenting on this, but I thought I'd put my
two cents in anyhow.

I've been keeping a loose eye on OpenID for quite a while now, although
I haven't yet implemented it in any of my projects, and I also believe
that key-pairs seem to be the best solution.  In fact, it seems to me to
be the only solution that would protect against loss of the OP domain
name.

The simplest way I'd envisage this working is something like this:

1) On account creation, the OP automatically creates a key pair for the
account.  There is no need for the key to be signed or certified.  The
public key would be published probably along the lines of
http://openid.net/specs/openid-service-key-discovery-1_0-01.html 

2) The RP includes a random challenge code in it's request to the OP.

3) The OP returns a signed version in it's response, along with the
public key's fingerprint, or even the entire key, if that's not
considered too long.  If the entire key is included, then there is
probably no need to publish the key any other way.

4) The RP checks that the signature is valid, and stores the public key
or key fingerprint along with the OpenID identifier.

If and when the identifier is recycled by the OP, a new key pair would
be created, and therefore would no longer match the identifier/key-pair
stored by the RP.

Overall this is much like the fragment system, but provides much better
protection against the fragment leaking (since the private key will
normally only be seen by the OP).

Something like this has been suggested a few times in the past, I think,
so I thought I'd address all of the potential concerns I can think of:

1) "This would mean the RP would need two database columns to store the
identity"

Not necessarily - the RP could simply append the key, fingerprint, or
even an abbreviated fingerprint to the identifier in the same way that
"fragments" are appended.

2) "What if the private key is lost by the OP?"

Then the identity is lost, unless the OP allows the user to re-upload a
backup of the private key.  This is no different from the OP losing the
identity's fragment.

3) "What if the private key is leaked?"

Then the security of the system falls back to be basically the same as
that of a fragment - an attacker would need to also gain control of the
OP domain name to gain control of the identity.

Regards,
Thomas.

On Mon, 2007-10-01 at 10:12 +0200, tom wrote:
> Hi Mark et all,
> 
> We thought along the same lines (actually we started passing the account 
> create datetime at discovery), however Peters input led us to believe 
> the that best approach to solving "trust" once and for all is to work on 
> key-pairs.
> 
> If you have a private key held in your OP account and a public key 
> available I (the consumer) can just store the public key and compare 
> that at discovery. For the OpenID community this has the added value for 
> encrypted messaging and so forth.
> 
> I was very optimistic to discover that this is already addressed in 
> http://openid.net/specs/openid-service-key-discovery-1_0-01.html
> however I now rely on two things:
> 
> 1. The OpenID community reaching general consensus on "key-pairs is 
> approach we take to tackling the trust problem".
> 2. The OPenID community rallies around implementing XRDS with public key 
> included.
> 
> Today just to take a random OP poll we have no key support and random 
> XRDS support......
> 
>     * ClaimID.com - XRDS supported; no public key.
>     * myopenid.com - No XRDS
>     * verisign - XRDS supported; no public key.
> 
> 
> So what's next? There is no point in me implementing public key 
> discovery if no OP is implementing support and there is no point in my 
> going after that goal if the community takes another direction with "trust".
> 
> Any comment? .... input from OP's would be very beneficial here;)
> 
> Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20071020/d3b4cb5e/attachment-0002.pgp>