[OpenID] Trust + Security @ OpenID

[Peter Williams]

1. This is something I've never understood - why does an RP need to
trust an OP? 

 

2. I especially don't understand why the RP cares about "integrity of
the authentication process". 

 

3. I think this is going in the wrong direction; I would be very
disappointed if OpenID lost its decentralization, and I'm not sure why
people think it needs to.

 

[1] seems easy to answer. OpenID claims to provide cryptographic proof
that a user controls an Identifier: all cryptography-based proof systems
require the verifier's trust in (a) the validity of the proof process
and (b) the correctness and effectiveness of the cryptographic
mechanisms protecting the communication of proof statements. That's the
academic answer. There are other dimensions to the trust issue; but the
one I use is seldom disputed.

 

 

 

 

A persuasive answer to [2] must address "care". The central use case for
OpenID scheme's of enabling OPs to assert that a user controls an
Identifier seems to be to facilitate logon to webapps over the Internet,
logons that thereafter encourage reputations to be contributed, collated
and published. Do I care that a savvy competitor to the business
generating my livelihood can interfere with my EBay reputation by
fracking with the OpenID technology? Yes. Do I care that my virtual
E-bay reputation in a virtual world is being hacked and potential for
virtual riches are being lost due to exploitable vulnerabilities in the
virtual-OpenID scheme? No! It's part of the game.

 

 

 

 

 

On [3], we must first ask: What (valuable) decentralization property is
being lost? I think OpenID vastly understates in its design rationale
the benefits of its use of and advancement of decentralized, trusted
name server-based Identity protocols. However, this is my analysis of
its decentralization benefits, an analytical claim set which is rather
different to the decentralization benefits that OpenID actually claims
for itself: anyone can throw up a server and start operating, without
interaction with third parties.

 

The only example I can think of in the web-space where the right to
throw up a relying party server receiving webSSO assertions is
"controlled" ... is in the Shibboleth community - an NSF "Internet2"
experiment whose research goals include addressing privacy-based release
of sensitive and personal attributes. There, "vendors" must be first
"sponsored" by a higher-ed institution before the deployment of
Shibboleth RP servers will actually officially interwork with all the
(hundreds of) Providers of assertions. The sponsoring higher-education
institution is presumably vouching for - and giving starting reputation
to - that party; which can and thereafter presumably sell stuff to
students, staff and others vendors associated with Universities.

 

If we lose the central thesis of OpenID, are we therefore now risking
"succumbing" to the Shibboleth vision of the webspace, becoming
subjected to the whim of the evil overlords of Academia?

 

There is a personal caveat to this issue, however. In 1995, VeriSign
imposed a policy on browser vendors that they shall undergo a quick eval
of their client SSL code, before being licensed to use the VeriSign PKI
roots, controlling access to Netscape https listeners. Far from evil or
exploitative of monopoly power, this policy existed because the same
critical crypto error/bug from some source file everyone started with
was being repeated over and over again, compromising the security of -
and overall reputation of - SSL. Quick inspection; massive community
benefit. We had to just put up with the evil overlord label that came
along with the policy, being web martyrs.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070708/dec10182/attachment-0002.htm>