[OpenID] For the nominees

Peter Williams pwilliams at rapattoni.com
Thu Dec 4 18:35:35 UTC 2008


Fair enough, Brett: though do understand I've lived through similar wars over CAs tuned to "web culture", when "PKIs" and their often-US government backed assurance frameworks attempted to "promote" assurance frameworks ...controlling who could assert which cert to which cert-user - even in the private sector.

We pushed back the tide last time(PKIs), to ensure the world of cert assertion/reliance infrastructure promoted/implemented self-signed certs (chains) at the same level of legitimacy and commodity support as TTP certs ...allowing low assurance frameworks to bootstrap. (As the world of PKI shows, none of that in any way prevented high-assurance, high-value, well governed frameworks existing, as overlays).

The core issue is the certainly the role of TTPs and any inter-TTP pacts concerning shared-governance. Mostly functionally  equivalent bit formats and signaling protocols (Kerberos, ldap binds, certs, GlobalPlatform/PIV, SAML, openid auth,  ...) are obviously irrelevant to issues of control and governance of public networks.

To UCI. UCI is a term that has definitively morphed ...to mean different things  to different communities, often with different "control constituencies".

In OpenID's design concept, the CLAIM is/was that "web" user-centric means/meant that TTPs do not "control" users (as bound subscribers). OpenID's notion of UCI is not delivered, for example, merely by supporting law#4 (directed identity). UCI in the openid sense requires that a user's ability to access their subscription at their RPs CAN BE (by user care) largely un-impacted by the cessation of the relationship between the user and any particular OP.

The OpenID control thesis forUCI is shown nicely in the Plaxo model, where any one of several openids managed by several OPs may be bound/linked to the user's plaxo/RP account by one, user-controlled discovery file. In a given act of signin, the User induces the RP to discover the user-named/controlled discovery file. This delegates to several OpeniD2 OPs - any one of which the RP may use, and some multiple of which will presumably usefully link to the RP account.

With judicious account linking at RPs and by ensuring delegation CAN be 100% controlled by users (if they care enough), UCI in the openid sense is NICELY implemented. Of course, none of this low-assurance world (equivalent to self-signed certs) stops openid protocols being used in closed-community overlays to implement the more TTP control model facilitating high-assurance, governance based control practices over a subscriber's web-life.



From: Brett McDowell [mailto:brett at ictprojects.com] On Behalf Of Brett McDowell
Sent: Thursday, December 04, 2008 11:03 AM
To: Peter Williams
Cc: Nat Sakimura; Eddy Nigg (StartCom Ltd.); general at openid.net
Subject: Re: [OpenID] For the nominees

Peter, you seem to be conflating Liberty Alliance (an organization with a broad mandate, including user-centric identity) with SAML 2.0 (a federation protocol that -- in large part, but not entirely -- came out of work Liberty Alliance did).  I also think you're giving SAML a black eye it doesn't deserve, but I'll let my technical betters defend the user-empowerment of SAML.

On Dec 4, 2008, at 12:56 PM, Peter Williams wrote:


Assurance in the "system"? Or assurance about an individual operator?

Liberty has active programs for facilitating governance of IDPs, and IDPs control over Users and RPs. OpenID  encourages a contrasting world of UCI, which has no governance model and no assumption that governance is particularly relevant.

I do hope OpenID Japan is not acting as an (undeclared) proxy for Liberty initiatives. There is little or no conception of UCI in the Liberty view of the world. Liberty is a full power TTP control model, where the IDP "controls" users as subscribers and (indirectly) governs their conduct on RP systems.   In OpenID, if one OP removes your access to your assertions or attributes signaled to a given RP, you can ALWAYS dump them and SIMPLY use another on the same RP, ___with no impact to the User__. This is (obviously) not the case with the TTP model, where the IDP _controls_ the level of impact on one or more RPs.


From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net] On Behalf Of Nat Sakimura
Sent: Thursday, December 04, 2008 7:32 AM
To: Eddy Nigg (StartCom Ltd.)
Cc: general at openid.net<mailto:general at openid.net>
Subject: Re: [OpenID] For the nominees

Hi Eddy,

Here is my answers inline:
On Thu, Dec 4, 2008 at 10:14 PM, Eddy Nigg (StartCom Ltd.) <eddy_nigg at startcom.org<mailto:eddy_nigg at startcom.org>> wrote:
There are a few questions I'd like to ask the current nominees in order to get a better picture about which ideas a nominee represents. Of course the questions are specifically what I feel important:

 1.  Adoption of OpenID by relying parties isn't on-par with the amount of providers available. How would you improve that ratio?
In Japan, we are doing the following:

- Individual visit to potential RPs to persuade them the value of being an RP.
- Technical seminars to get them up to speed.
- Create an Assurance Framework (this is in progress) to let them have better "trust" in the system.

I personally think we should replicate it in the global scale.

 1.  What is it that should be done in order to have big providers like Google, Yahoo!, Microsoft rely on other operators?
 Assurance framework is a key. Right now, we have no good way of assessing the assurance level of the assertions. Once it is solved, it will become much easier for them to start accepting the assertions created by a third party.

Also, we have to show the relevant parties the market and profit potential.

 1.  Do you think that a trust relationship framework should be created, similar to PKI auditing (or any other/similar idea) in order to allow relying parties easily trust on other operators? Or what would you suggest instead?
Obviously, an assurance framework coupled with auditing is a key factor. I think we should look at Liberty Alliance's Identity Assurance Framework (IAF). IAF is protocol independent so we can profile it to OpenID. Also, Assurance does not come in the form of Technology alone. Legal systems have impact on it. In Japan, we are working closely with the Japanese government to sort out the issues. I think this needs to be replicated to anywhere in the world. That is why we need to have a good representation from the different jurisdictions for the board.

Having said that, the assurance framework alone does not solve the problem. We should use reputations services in conjunction with it. That is why I have created ORMS TC at OASIS.


 1.  Do you think that instead of hiring an executive director, the load of the different tasks could be shifted to a small group of different persons instead (foundation management)? Would you view a such a scenario possible and perhaps more efficient? (Considering the amount to be paid for an ED, I suspect that many highly motivated and capable individuals from within the community or from outside could do a better job than one individual and receive fair compensation for their work.)
This is exactly what we are doing in OpenID Foundation Japan. Instead of hiring an ED, we have distributed tasks to (business-wise) motivated group of people for each topic. Providing them the benefit of doing it seems to deliver a better ROI at least in Japan. I am not entirely sure about the situation in the U.S. and other countries, but considering that OIDF is resource constrained, it certainly is a path that should be considered.


--
Regards



Signer:

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

Jabber:

startcom at startcom.org<mailto:startcom at startcom.org>

Blog:

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

Phone:

+1.213.341.0390




_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general



--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

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


More information about the general mailing list