security

[Eddy Nigg (StartCom Ltd.)]

OK, let me explain, what my thoughts on this really are:

Supposed this protocol should be used in the future for more serious
stuff than forums and blogs, than I suggest to define this NOW. Taking
adoption into account and supposed, that the specifications can provide
what's needed, than in a year or two this can be already reality...

BUT: Supposed I would give access to critical parts of a certain area
via this protocol/specifications and something happens, i.e. precious
data gets compromised for example, than I am responsible for this...Now,
if I'm the one, who has to authorize the use of this specific protocol
(openid) and this protocol doesn't provide the required protection, than
I'll never be able to do so....

Now lets break this down very simply:

- If an IDP (perhaps you) is not required to run in secured mode, than
the user specific data might get compromised and the chances are too
high...I can't allow access to critical area, where a user/password pair
might have been transfered in plain...

- If a RP isn't required to run in secured mode, than chances are, that
half of the secret of the user might get compromised (i.e. the user URI
is half of the secret).

- If a RP might transfer or receive data unsecured (and even
unencrypted) between the IDP and itself, than again part of the data can
get compromised.

Summary:

Since I have to trust on others in order to make use of this
single-sign-on network, I must be sure, that none of the above can
happen, otherwise I can't delegate to a third party and will remain as
it is...I guess, that I'm not the only one who thinks like this, but
every serious IT manager will make the same decision.

That's why, I see it crucial, that a certain standard has to be
required! I'm not even talking about better protection of the user/pass
pair, which is another issue in itself, but really some of the basic
conditions as I see it....

Hope this helps somewhat...

Dan Lyke wrote:
> On Tue, 24 Oct 2006 17:48:17 -0700, Eddy Nigg (StartCom Ltd.) wrote:
>   
>> Well, I think we all tried...We provided an existing and common
>> solution, which could provide one/another line of defense...
>>     
>
> For the second time: Can someone, please, tell me exactly what this  
> other line of defense is protecting against?
>   

-- 
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Phone:       +1.213.341.0390
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061025/e0cb1e21/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eddy_nigg.vcf
Type: text/x-vcard
Size: 636 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061025/e0cb1e21/attachment-0002.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7282 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061025/e0cb1e21/attachment-0002.bin>