[OpenID] Foudnation's wiki.openid.net consumer and membership consumer: creating an sp-affiliation
Peter Williams
pwilliams at rapattoni.com
Fri Dec 19 21:22:07 UTC 2008
As we go from evangelism to adoption, we’d be well served in addressing in our own showcases the realities that others will encounter. Of course we know what they are (the spec is WELL written, on the topic of https), but can we demonstrate that those mechanisms WORK EFFECTIVELY in public networks, ourselves?
I do remember someone asserting that (https) trust in the UCI space was intended to be “sorted out by market forces” – i.e. by the “highest common denominator” function. That is: consumers will naturally migrate to OPs/CAs that “work” (ie. are accepted). Others (that have some or other hurdle) will be avoided. It’s not as if the consumer could really care less about CA’s and OPs and https, till there is an actual fraud and thus a finger has to get pointed somewhere, to collect the cash.
We can ask: it the choice of the relying party to “accept” one or other CAs for https openids (and deny others)? Well, surely it is! Who else who do it? The user cannot, do it as the claimant, and the OP cannot do it, as the asserting party. That leaves the Relying party (“consumer”).
The Foundation is obviously the relying party when delivering 2 services as member benefits. And in that role i) the vendor “CAcert” has been evidently been designated as perfectly acceptable for the https openid used for (rather legalistic) membership transactions (including vote casting, it seems), and ii) a member’s use of the https openid may or may not now work with the own Foundation’s wiki (once outsourced to pbwiki).
Now, I really don’t know if pbwiki makes any use of Debian products. But even if it does, surely it’s the Foundation (as customer of the outsourced wiki) that determines what the pbwiki -enforced reliance policy is? Using the wiki is a member benefit, and surely pbwiki ( the contractor) should be enforcing the Foundations happenstance “all inclusive” decision policies (any CA will do for openid discovery, even the ones’ whose SSL certifications are allegedly worth less than the e-paper they are written on).
Now, let me try to think like pbwiki. At Rapattoni, we too have 300+ customers each running THEIR sets of committees, posting THEIR courses, holding events, doing non-profit elections (~1 a day on average), maintaining records so professional flows can fine members who tend to be unhappy about that act, constantly orchestrating donations for local/state/national political campaigns, running accounting day books and reconciliations, posting merchant e-stores, handling recurring credit cards transactions etc.. And, doing all that, I really expect to run a trust model (concerning https openid) for each of those 300 customer, rather than impose some Rapattoni criteria.
As those (pbwiki-like) customers also procure SAAS services from our peers, and 1 member will inevitably visit multiple providers of SAAS service, I’d expect us all (as outsourcers related to a single community) to harmonize with the customer’s trust model (per membership group).
I have not yet reviewed any of the OpenID’s WG’s proposed trust discovery/negotiation/reliance protocols. But I’d hope that it might adopt some of what SAML2 got right - in its “SP-affiliation” model. This would help make a leap forward here, in handling the REALITY of trust models in the SAAS area, when multiple providers are involved. Then, what one dominant SP relies on, other SPs in the specific affiliation group may be required to similarly rely on.
(The IPR issues are well pretty settled on sp-affiliations, too!)
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Friday, December 19, 2008 12:05 PM
To: OpenID List
Subject: Re: [OpenID] [OpenID board] wiki.openid.net is now set up
On 12/19/2008 09:34 PM, Peter Williams:
I'm going to attempt join my client's (CAcert-endorsed) https Openid membership account, for voting purposes.
(Though Eddy might protest that the Foundation is not served by agreeing to that business partners legal terms)
I explained what it means, provided the necessary information for the foundation to judge it. Not going to protest, but will make note.
As a user, I'd want the CA-cert endorsed https OpeniD viable for the membership.voting site to also work on the Foundation's wiki.
Perhaps it isn't your choice which CA your OpenID provider uses, maybe it is. In the former case I'd suggest to start a dialog with the provider to have that changed, in the later case you'd surprise and disappoint me.
Regards
Signer:
Eddy Nigg, StartCom Ltd.<http://www.startcom.org>
Jabber:
startcom at startcom.org<xmpp: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/20081219/67223dbd/attachment-0002.htm>
More information about the general
mailing list