[OpenID] HTML-Based Discovery incompatibilities

[Peter Williams]

Don't  give up, Eran. I've personally sat in your seat, and can empathize (over a wire, even).

Recognize that scalable security cultures are always capable of serving different management cultures. Anytime a crypto technology gets overly biased towards low assurance (or high assurance) it fails to take off on the scale we all intend for OAUTH and OpenID.

The feature you are so focused on today are an entirely optional feature of openid. That's why it has exactly the right name : the "vanity" openid. 90+% of people won't use it. Those that do, will swear by it (and will put up with the vagaries). The feature is also current a _distinguishing_ feature between openid and OAUTH tho.

Do recognize, that this is the  second crisis point that made you back off (the last being there mere discussion of anonymity in a formal setting, that a minor journalist got to rant about since he had nothing else to say). Recognize that others feel that these structural issues are vitally important here (even for ~10% of users). It cost RPs almost nothing to accommodate that 10% over and above the OPs that will serve the 90% of folks.

Take heart from SSL. For years and years, piece by piece..folks added X.509 to SSL. It's almost complete, per the 1988 standard (in 2008). First they would not do certs at all (they only had time to make an compiled array of 4 public keys in Netscape 1.x). Then they added 1 layer certs. Then they did the cn= convention. Then, they made the sessionid unecrypted so they could be proxy aware, for load balanced environments and crypto offloading (since RSA was so slow in software, in those days). Then they added cert chains (but only those that are ordered never ever doing the bag.) Then they added X.509 v3 extensions. Then dod had taught them non RSA ciphers, and adjusted the handshake to become properly cipher independent. Then they had the crisis of bad key gen, export grade derivate functions, and then mandatory key escrow through rigged PKI. Then they did CRLs, and later delta CRLs. Stupid MIT patents caused folk to avoid adopting merkle hash trees, and micro-status signals. But, they did get to add plug and play crypto, with fully componentized assurance allow for the world of smartcards and MIPS-based exponentiations. Then, they got to dump the USG-crippled cipher modes that had been part of the motivation of the very handshake closure concept! With that gone, they got to add SSL hello extensions customized to new asymmetric cipher math that targets low-power CPUs in first generation phone handsets. Later the vendors got the power to register their own private extension and SSL became connectionless with non-traditional cipher modes suited now for multicast apps .

If I can put up with this for 15 years, you can tolerate 15 months. Here, folks clearly want the merger: there is simply an absence of mature political mechanism that allow us to focus collectively on the issues of merging OAUTH's AuthZ focus  with OpenID's AuthN focus.

As always, producing working code REALLY HELPS.

I spent the day studying how SAML does RP affiliations, by tagging the request to its OP with  a community tag - trying to conceive of how it would best apply to the downstream network of AC->SPs. This would influence how the likes of Yahoo should be handling their generation of the pseudonyms. If an AC has a co-resident OpeniD RP module, I can see how the affiliation tag (which implies the OP would use a common pseudonym across the affiliation members) should be able to bind ACs to particular SPs in its affiliation group. Now I know Pat is experimenting with a different direction (using OpenID assertions to distribute public keys). I suspect the minting of an affiliation-common pseudonym by an OP would make for a rather better password-distribution mechanism between an AC and the USERS set of SP data source, given the culture of OAUTH today. But, who know!

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 09, 2009 9:26 PM
To: Chris Messina
Cc: general at openid.net
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

Given a valuable product and a market for it, I have no doubt you will do a superior job than me getting that product to the hands of the people who can use it. You will do an outstanding job.

But this insistence on the 0.0001% "*a* use case" is costing you the little shred of competence implementation in the OpenID community. It take a lot more than an uneducated user cut/paste a couple lines of markup they do not understand to build a trusted identity infrastructure. If this is the product you are selling, good luck.

I'm giving up.

EHL


From: Chris Messina [mailto:chris.messina at gmail.com]
Sent: Friday, January 09, 2009 6:39 PM
It isn't that that will be the dominate use case, but it will be *a* use case, and many like it are sure to emerge over the course of time between where we are today and where we aspire to get to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090110/f4889bce/attachment-0002.htm>