[OpenID] openid query

Sat Mar 1 17:28:17 UTC 2008

Forming trust relationships (leveraging EV certs) can be explored at https://account.live.com/addlink.aspx?mkt=en-us. Its basically account linking, but between two accounts of the same user. If you follow the link, note the legal twist that is interesting in and of itself.

Its fun to see the changes in the market in the last year. 1. Google issuing a SAML IDP toolkit, to talk to Google Apps. 2. Yahoo launching an OP that imposes a hub-centric federation model. 3. Microsoft letting local cardspace IDPs bind to LiveIDs, SP-centric. 4. AOL doing its thing (?). 5. Ping launching “immediate auto-connect” for SAML2, to emulate openid discovery.

When people as dumb as me can finally get on the bandwagon, you know a market has reached tipping point. The days of $6000 per connection (per direction!) annual fees are over, as are the rules that made it take 3 months to connect two folks. Even when FIRST TIME RP partners do new programming/integration using open source toolkits, I know after 10 rounds of this that in reality connection setup is about a week. And, most of that concerns agreeing the UI handoff between hub/spoke!

If anyone has an RP site accepting unsolicited openid2 auth, with no association (but optionally accepts leverages https), Id like to do some interworking trials. I want to get the IDP-side code down to a page of simple script, for this minimal profile.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Friday, February 29, 2008 1:20 PM
To: Martin Paljak
Cc: OpenID General
Subject: Re: [OpenID] openid query

Martin Paljak wrote: 

Do I trust the 50+ 'authorities' pre-selected by somebody else for me  
in Firefox? I doubt it. Do I trust the OpenID providers I've chosen to  
use? More likely.

So this is entirely off-topic (well, maybe it isn't), but it seems that you have no clue  about how CAs are admitted and governed in the Mozilla NSS store. Not only is the full process of inclusion of a CA performed publicly, a concrete set of policy [1] (and practices) control inclusions and included CAs. The CAs in NSS are not just "pre-selected by somebody" but each CA undergoes an not so easy process, some are rejected entirely or held up for inclusion until meeting certain requirements. Mozilla does provide a set of CAs included within their software on behalf of the user, because it's very inconvenient to read and understand of each CA its policies and attestations in order to make a decision.

OpenID providers don't have to undergo any vetting and don't have to adhere to any outlined requirements and policies whatsoever, so what you are saying here is absolute rubbish. Joe Candoall may be an OpenID provider but certainly not a CA included in NSS (or other software I guess). I suggest to be careful with such baseless and bold comparisons if you don't know about it...else please explain what is the basis of your trust in OpenID providers compared to the Mozilla included CAs, because what you are saying right now is that:

- I trust a provider which has his site hosted at some shared hosting provider somewhere
- I trust a provider which hasn't any policies and practices implemented
- I trust a provider which doesn't need to meet any requirements whatsoever
- I trust a provider which hasn't undergone any wetting by a third party
- I trust a provider which which doesn't have to take any responsibility
- I trust a provider which doesn't give me any guaranties nor insight about its authentication methods

- I don't trust a set of CAs which must meet declared requirements set forth by Mozilla...mmmhhh....

[1] http://www.mozilla.org/projects/security/certs/policy/

-- 

Regards 

Signer: 

Eddy Nigg, StartCom Ltd. <http://www.startcom.org> 

Jabber: 

startcom at startcom.org

Blog: 

Join the Revolution! <http://blog.startcom.org> 

Phone: 

+1.213.341.0390

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