[security] security

[Martin Atkins]

Eddy Nigg (StartCom Ltd.) wrote:
> Martin, your suggestions are interesting! However isn't there a danger 
> of a split of networks and fragmentation? Perhaps it might be useful to 
> include a "trust anchor" in the OpenID specs, which would define, how 
> trust networks should be approached? This could be some identifier or 
> list of known "trust networks", which allows an RP to select and act 
> accordingly to the networks specific specifications...This would 
> guaranty, that all RP's still can talk to all (requested) IDP's, without 
> failing to to talk to X or Y, because it doesn't know, which specs it 
> follows...Something like "trust discovery"?
> 
> Since third parties must be involved in this (i.e. "OpenID Registry", 
> "Verisign Trustnetwork" ;-), "xdi.org"), which according to their policy 
> control adherence to it, the RP must know about them in first 
> place....Otherwise very soon, none of the various networks will be 
> compatible...or requires from the RP to implement many different specs 
> in order to stay compatible with them all...
> 

I tend to think about it in much the same way as people have been 
dealing with spam. There are lots of methods of detecting whether a 
given message is spam, and some are more effective in different 
situations than others.

Mail servers all over the world are employing different combinations of 
these techniques with varying degrees of success, but the key thing is 
that (on the whole) *everyone is still inter-operating* in spite of 
these differences.

This is one of those things which I believe will work itself out. RPs 
won't want to use an overly-restrictive trust system because they will 
lose potential users, much like overly-enthusiastic spam blocking can 
lose legitimate mail. Except in some special cases, RPs will *want* to 
accept users from as broad a range of IdPs as possible, so they will 
choose trust techniques that will still "keep the network together" but 
will exclude a few parties that are, in the eyes of the RP, "bad players".

RPs with more particular requirements will of course have to exclude 
more potential users, but it'd be a mistake to set in stone what RPs are 
allowed to require now as security requirements are likely to change in 
the future as new applications emerge that we'd never thought of, or new 
security protocols are invented.