[OpenID] How to handle byzantine failure with openid.

[Jörg F. Wittenberger]

Am Donnerstag, den 30.08.2007, 18:41 +0200 schrieb Lukas Rosenstock:
> Hello!
> I haven't thoroughly read all details on what Askemos is about, although  
> this project seems quite interesting to me.
> 
> The idea how OpenID confirms that a user controls a certain URL is that  
> only the user in control can place a link to his chosen OpenID server,  
> which, of course, a server administrator could do, too. The user needs to  
> trust his provider,

This, the need to trust your provider is exactly the problem the Askemos
project targets.

> because the provider has no problem to use his user's  
> identity - as email server administrators have access to their user's  
> inbox folders!

At least the trust into the provider not to (miss)*use* your identity.
That is, not to be able to initiate transaction impersonating the user.
It does not away with the need to trust the provider regarding privacy.
Your provider can still read your data/messages, but no provider can
forge messages to look to other providers as if those where send from
the individual.  Since transactions are performed in byzantine
agreement, no provider can create transactions for a user or withhold
data.  Not even by going offline.

> This is the tradeoff in security and privacy that makes  
> OpenID so lightweight and easy to use.

I like those lightweight things to combine.  ,-)

So, that's what I'm understanding: Askemos is the complement to OpenId
in a way.  OpenID conveys the providers idea, no utterance that is,
about who controls a URL.  The user must trust the provider not to lie.

Askemos does away with the need to trust a single provider.  It trust
the idea it derives from the majority's of providers utterances.

A single provider is in this view just a special case of a quorum of
providers.

> Through the use of XRDS files ("Yadis"), it is possible to associate  
> multiple servers with one URL. The intended use was to give these servers  
> priority values so that if the primary server is down, the relying party  
> can check with another server. For applications that need high security it  
> would be no problem to check *every* server in that document and require  
> that, for example, there are at least three or four of them whose IP  
> addresses are in different class A networks.

OK, that's what I need.  Let alone the network class.  ,-)

So far I understand that OpenID does not yet consider malfunctioning
providers out of itself, but does also not prevent RP's from checking
with multiple providers.  Having slept yet another night over it, I
think it's just the RP, which needs to authenticate several times.

>  Still, the identity URL  
> itself that hosts the XRDS document is a SPOF because an attacker could  
> replace all servers with his own - if he controls a bot network with hosts  
> on different networks ...

So the discovery should go through SSL.  Thereby the user already needs
to authenticate with a SSL protected URL, correct?

Then the attacker needs to control n+1 hosts from the quorum again.
When that limit is reached, Askemos style hosting doesn't help anymore.

> The list of providers could also be sent as an InfoCard of the XRDS  
> document could be signed - which is, even put apart from Askemos, quite a  
> good idea ...

I don't know much about InfoCard yet.  So what's gained from a signed
XRDS document?  How does the user send the public key to the RP?

Regards

/Jörg