[OpenID] How to handle byzantine failure with openid.

[Jörg F. Wittenberger]

Hello all,

these days I considered to implement OpenID support for Askemos
<http://www.askemos.org>.

To my current understanding the spec appears to be underspecified.  Now
I contemplate about solutions and/or seek advice of someone OpenID
wizard on reading the hairy details of the spec which I missed.

So far I understand OpenID is about users proofing to each other, that
the individual controls a URL. OpenID does not specify how the users
ensure that they control the URL.

In fact most users don't do that at all: The URL is usually hosted at
some web server and at least the administrators of that server farm have
factually more control of the end users URL than the users themself. Let
alone that the administrators often enough don't know how little of
their own control is left over, when intruders evaded the servers.

Askemos empowers users to factually own and control their URL's in the
presence of byzantine failure of their web host providers as long as the
majority of servers doesn't fail at once.

So it looks as if we, the Askemos developers, need to support at least
Identity Provider service and maybe Relying Party support. Let's see:

== As Relying Party 
=== The Problem
As a relying party, our Askemos servers would need - as the name
suggests - to rely on a remote identity provider's idea of the identity
of the user.

However the OpenID specs eventually rely on a single remote server,
don't they?  Doing so would introduce a remote single point of failure
into the Askemos network, which is not acceptable according to the
Askemos design principles.

Hm, I might drill this hole into private installations if someone needs
it. But not into the published source.

=== Possible Solution
The specification should require that: when a Claimed Identifier
resolves to several OP-Local Identifiers (optional if a single OP-Local
Identifier one resolves via DNS to a set of distinct hosts) then the
Relying Party MUST NOT rely on the authentication until it has verified
with the majority of those OpenID Providers the Identifier resolved to.

Would this be reasonable?

== As Identity Provider

The situation is better as a OpenID Identity Provider (OP).

Using OP-Local Identifiers, users can point Relying Parties via several
network paths particular mirror copies of the users identity. However
that's inconvenient and right now I'm not sure that browsers will accept
multiple CN attributes in SSL certificates. (This appears to me as the
only solution if all those OP-Local Identifiers resolve to the same
place just on different providers. Alls those hosts come under one SSL
CN but different locations (X509 L-attributes).  I'm in the dark how we
will have to keep the reference correct, but this seems doable from a
birds point of view.

But: At least when the OP Endpoint URL resolves via DNS to several A
records, the OpenID specification could suggest on the handling
association requests. Once the User-Agent has associated with a OP via a
certain DNS address it should stick to it with all further
authentication requests for that realm. (Otherwise most authentication
requests will fail, since the other copies of the OP don't share the
secret the one OP copy shared with the RP -- or should we share those
secrets? ;-) No kidding, I assume there is no sharing of RP/OP shared
secrets among several OP's intented.)

Thanks for your replies.

/Joerg

Note: I'll archive the essence of your replies here:
http://www.askemos.org/A231f1a67e1aa44d0ef613c02e1db0baa