<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
in myopenid profile, I long ago stuffed in the web URI field my ascii-armored cert (self-signed). It has form something like <a href="http://cert.com/path/?cert=----BEGIN">http://cert.com/path/?cert=----BEGIN</a> CERT....END CERT<BR> <BR>Thus, one could view the openid OP as a re-signer of the cert value - vouching for it in a sense (in its self-signed version). I wanted to play (3 years ago now) with myopenid taking a https client cert as user authn act, and sending the very same cert in the sreg/AX attribute to RPs (for further processing, such as webid validation).<BR> <BR>But, this scheme was always confusing since the status of the web/uri sreg field is non standard. <BR> <BR>And, of course, the public/no-fee version of myopenid doesnt support AX (or SSL client cert authn, apparently, any longer).<BR> <BR>So, while lots COULD be done to integrate webid (https client certs) with openid, lots is holding it back. For the FIRST time, myopenid no longer met the gold standard needs. Its lack of providing email address to Azure ACS was a killer, just yesterday, for example (since my joomla auto-reg REQUIRES email).<BR> <BR>So I feel we have lots of technologies, and unlike 2 years ago, we have the right attitude (encompassing bridging. gatewaying is no longer a dirty word - except in the scholarly Shib communitiy). But, there is insufficient will to make these n versions of websso really work together. I suspect the reason is simple economics - and a fair amount of ego.<BR> <BR>Folks are still at the point of hoping that one websso scheme wins out against the rest (which will never happen....since they all do exactly the same thing, in different dialects). Meantime, folks like me - trying to adopt and project national scale infrastructure (in realty) - are stuck with mapping this and that, in what is your typical american mess of always mapping this to that. Half the time, in websso, I feel the vendors are still deliberately making it all hard (even to map), so as to put off the day when commodity standards rule websso.<BR> <BR>Forgotton his name, but one of the chief architects of lotus (a firm that resisted the X.509 standard for a decade, in favor of a lotus notes blob format) taught me that one hangs on to non-standard, and then half-standards, and then non-interoperable standards, and then standard that only just interoperate...and then standards that need mapping.... for as long as one can get a million/thousand/hundred/dollar/dime out of the user.<BR> <BR>The days of million dollar SAML engagements are clearly over. We seem to be at the $3 for 100,000 transactions level, price point (ref Microsoft Azure, list price); with free compiler and well-engineered websso toolkit thrown in. Within 2 years, perhaps 3, we may reach commodity status, whereupon the conditions for national infrastructure may be met - since the vendors will be no long trying to compete (over nothing, not even mindshare, at that point). Its then about cost *elimination*, which means **maximising** standards compatibility - after the flip point. At this point, websso becomes viable as a 30 year infrastructure (like certs)<BR><br>All good fun. Microsoft has really changed the curve, with its deliverables last year. Ive no doubt Goog'es timing helpe MSFT decide when the market was ripe, for commodization. I *can* now get from myopenid to joomla, without installing a openid plugin - which is how it should be. If myopenid were to accept SSL https client certs for no-fee customers, Id even be in a position to benefit from webid's, values too! But, of course it doesnt, as yet still wanting to make a dime (now) per user.<BR><div>> Date: Fri, 8 Jul 2011 14:22:13 +0200<br>> Subject: Re: [OpenID] Re: last mile politics<br>> From: melvincarvalho@gmail.com<br>> To: sysadmin@shadowsinthegarden.com<br>> CC: home_pw@msn.com; openid-general@lists.openid.net<br>> <br>> On 8 July 2011 08:00, SitG Admin <sysadmin@shadowsinthegarden.com> wrote:<br>> >> Much as in the PKI era, these will not be built in the interests of<br>> >> individuals in society. Lose your access as a subscriber at an IDP or lose a<br>> >> rights to a name during a pending dispute, you WILL lose access at your SP<br>> >> sites -since they are tightly bound to the OP.<br>> >><br>> >> This is not a viable national infrastructure. Its certainly not a viable<br>> >> trans-national infrastructure.<br>> ><br>> > Recent years have seen projects for UCI independence (Tor in every router,<br>> > wallplug servers every person can carry with them, p2p wifi over low-orbit<br>> > hot air balloons), words like "convergence" coming to mind. The technologies<br>> > were all there; OpenID seemed like one of them, but active use slowly left<br>> > more of an impression that it was developing in a different direction.<br>> <br>> Just a thought. Why not add a simple OpenID extension:<br>> <br>> <link property="openid2.PublcKey" content="ABCD..." /><br>> <br>> and bring openid into the world of PKI?<br>> <br>> ><br>> > The practical limits are not just Name (unique entry in namespace governed<br>> > by authoritative gatekeeper) versus Number (signed crytographic<br>> > key/card/cert/etc), where those sites unable (or unwilling) to make the<br>> > switch toward a more secure means of authentication must deal with 3rd<br>> > parties that promise to have done those security checks, and will translate<br>> > it to a unique corresponding entry in namespace; SP's will also have access<br>> > to their immediate networks only. (Yes, some sites can alternately be<br>> > reached through Tor/I2P addresses - but if you gave them a street address,<br>> > they would choke in puzzlement, whereas a different company on the main<br>> > internet might offer to provide a proxy service for reaching a person at<br>> > that address through snailmail, whatever.) When there *is no* direct channel<br>> > of communication between SP and IDP, they *must* relay information to each<br>> > other through trusted (by both) proxies, possibly a chain of them. (XRI was<br>> > supposed to help with this.)<br>> ><br>> > Proxies seem to challenge the OpenID security model at first, but on further<br>> > reflection are probably integral to the future use-cases. I still have<br>> > doubts about using proxies within the same network (where direct<br>> > communication *can* take place), but it's likely I just don't understand<br>> > what the service is trying to offer.<br>> ><br>> > -Shade<br>> > _______________________________________________<br>> > general mailing list<br>> > general@lists.openid.net<br>> > http://lists.openid.net/mailman/listinfo/openid-general<br>> ><br></div> </div></body>
</html>