several years ago, someone helped me in my first ever openid experience. They told me how to add link metadata to a blogger website, that would use myopenid as the IDP. My name to the world of relying parties would be that of my blogsite, however. I think it was the first blogging service I ever used.
I repeated that experiment today with a new blogspot site, using the foundation's member enrollment page as the relying party. It all still works fine.
http://yorkporc.blogspot.com/ is registered with the relying party as the openid, and myopenid duly challenged me for user credentials.
There is a nice opportunity to cooperate with the W3C's (incubating) webid project - since it ties in SO CLOSELY with openid ideas.And, it can be done practically, using infrastrcture that exists. Either the foundation's site (as relying party) or the myopenid site (as identity provider) could be ask for https client auth certificates. The RP site could just be interested in the user's card for public claims, and the IDP COULD be interested in said card for claims and/or user authentication. In either case, the card augments whatever public claims and cards the particular OP pointed to by delegation is maintaining. Obviously, the latter goes away, once the user/IDP relationship goes sour.
The myopenid site already gives me the option to use SSL and client certs (that works for some users, apparently). It thereby avoids passwords on the wire - the bane of much of the worlds users. Now, these days, that cert can usefully contain upto 3 webid URIs - the user's openid(s) with some #tag appended, that humans hopefully never see. In my case, the working openid
http://yorkporc.blogspot.com/ becomes my webid URI in the cert as
http://yorkporc.blogspot.com/#me. When I use the webid URI at the foundations site, it even works as my openid URI (since technical folks were clever, long ago).
Under the semantic web idea set that could now be EASILY and OPTIONALLY augmenting openid culture, of course, that webid URI can be deferenced, and even be used as a identity check by IDPs. But MOST importantly it can simply be a set of public claims that are managed by users (out of the control of IDPs). This are claims SIMILAR to, but distinct from, the "identity page" of (public) claims tied to the openid as managed by an IDP, nicely demonstrated by myopenid's services. The webid claims are managed by the user, on the same blogger site as that which was faciliating the name delegation and exist even if I lose myopenid subscription rights tomorrow. They have the same authoritiveness as my delegation metadata, that is.
Its a very user centric OVERLAY on otherwise commercial-centric identity management - merging points of control (for good cryptopolitical karma). It merges only what already exists in the wild at 99%: client certs with URIs, openid URIs, webid URI variants with #tags, and the use of sich as blogspot as glueware to pull some of the infrastructure together.
Wouldnt it make sense for OPs on recognizing a webid URI in a client cert, when used to authenticate the user instead of a password, to at least PASS the webid URI to relying party sites in the openid Assertion? Could not the extended sreg URI (website) claim be used for this, PERHAPS?
Speaking as an RP site that talks to 100 million folks (occasionally), this kind of "infrastructure integration" makes all the difference to adoption when the relying party sites are themselves mini-cloud providers - and ever tenant (of such as the realty "mini-cloud" service provider) demand their own variant of the web login experience, their choice of IDPs, their choice of blog provider vendor, their choice of certs over passwords, their choice of CA for minting certs, etc etc.
now, it was REALLY nice that - in PRACTICE -I could use my Google Apps openid2.0 provider to get a blogspot account, create a delegate openid, bind my webid profile to the home page of the site, use my favorite CA to mint client certs with webids that a minor variant of my delegated openid URI, and then cooperate with myopenid for validting user credentials, all done when talking to a relying party site. it was even nicer that I can see how to add on the Micosoft's Azure ACS gateway service , which can hook up all that TODAY to our own production realty web apps , desperately wanting websso for occasional consumers.
If there is a will to cooperate, I think we can complete the project folks started years ago, in the UCI flavor of openid. The story I just told is SO much better than it was when I did the same experiment 4+ years ago, with the same blogger service. Now the cloud is multi-vendor, multi-protocol, multi player, and still user centric (by option).
RSS Feed