[OpenID] Rule of thumb

[Eddy Nigg (StartCom Ltd.)]

Hi Peter,

Peter Williams wrote:
> So lets carry forward the issue to openid, 
Excellent! :-)
> where we have more or less clean slate. 
Yes we do...
> We don't have any legacy trust or organzational practices, in OpenID. Or, do we?
>   
Correct! No legacy trust or organzational practices...
> Do we want to emulate the pki world, 
Perhaps somewhat...
> where four or five software vendors would set a criteria bar on op providers by default
No, absolutely not! However be warned, that if we don't do it, the top 
providers will do exactly that...Who will loose? Most of the 
enthusiastic community members and early adopters of today!
>  (and auto enforce it, with something equivalent of the https world's nasty, consumer unfriendly popups for the rest of the open world that can play, but only with the handicap ?
>   
This is exactly what I fear will happen if no precedents is set by the 
community today! Let us define the rules and make it the de-facto 
standard for all IDPs before somebody else is doing it!
> Lets now the test for the hardcase. 
>   
I think this is premature, but lets go...
> I create an openid provider that accepts ssl client certs from cacert. It issues openid assertions, using signed-mac security mechanisms.
>
> Are you advocating that now the the major RPs now refuse to accept that OP provider - because of its earlier association with the unacceptable cacert?
>   
It might be...Or it might depend on what you advertise...You see, this 
is already something which the organization/body I envision has to 
decide and provide the mechanism to set the level a RP might 
require/request. Similar to the examples from her: 
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#examples
So one level might be GPG and web-of-trust verified authentication. 
There is nothing wrong with that, except there should be a mechanism 
which would the RP to accept/allow it or not. The important issue is, 
that your claims (whatever they are) have been verified and you don't 
advertise something wrongfully. Even the fact of having undergone a 
certain verification process will prevent a rough IDP from operating.
> Hardcase 2.
>
> If I use a cacert ssl session to protect the openid auth flow, are we saying agan : by default, reject BY DEFAULT (or accept with handicaps) on those grounds?
>   
Well, is this going to be an issue around Cacert? Does OpenID depend on 
Cacert? There are other alternatives than CAcert...

But practically an RP (web server) might look at its ca-bundle and check 
if the root exists. If it does it will initiate the connection, else it 
will fail. Fair enough? Or the RP might decide to require only 
connections to sites with "trusted" certificate or not (same ca-bundle 
again or not).
> Are we saying that there will be a preferred world of certain op providers, much as there is a similar notion in the ca world?
>   
No, I don't think so! Quite the opposite! I think it should be possible 
for every sincere operator to get "verified" by the verifying body I 
envision.
> If we go this route, openid will have the same adoption dynamics as pki, and the same meta trust model. There is nothing web2.0 about it. The fully decentralized ID system  with websso properties label will be a sham. Like pki in practice for the web, power would be entirely centralized ( and we can agree or not on what certain trade associations may or may not be doing, to influence the bars applied -almost uniformly by both the community-centric or business-policy making bodies.)
>   
This is what will happen anyway if there is no precedent set by todays 
community! Think about it...the business-policy making bodies have far 
more power and money than a few early adopters...except if you prevent 
it from happening now.

-- 
Regards
 
Signer:      Eddy Nigg, StartCom Ltd.
Jabber:      startcom at startcom.org
Phone:       +1.213.341.0390
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070714/4e8939a1/attachment-0002.htm>