One thing we do lack is a consensus
on what openID is other than a redirect based protocol with a symmetric shared
secret between the OP and RP per the openID 2.0 spec.
So a good first question to tackle
is should asymmetric cryptography RSA/ECDSA be a part of the core spec.
If the answer continues to be no
then it takes a bunch of options off the table.
I think the answer for extensions
like CX and secure discovery may well be different than for the core spec.
I am interested in what people
thing openID is or should be going forward.
That which folks could not do to
enhance SSL itself for websso (because of the way IETF works, and who runs/influences
the contributors/editors of that forum), I see openid as having done through
market forces. Openid is to me an enhanced session manager for ssl sessionids,
with the added value of discovery and authorization controls – that allow
multiple “SSL connections” to be proxied UNDER policy control
(rather than ad-hoc http proxy/connects that just fashioned a MITM space).
Now, the deployed SSL would need to be unhooked from the https-level
de-facto policy of tying trust to the DNS – which is currently partially governing
end-end connection policie (under ideas from 15 years ago (that have not moved forward
So, just as facebook have treated openid as a hidden protocol under
a UX flow (using only a slice of the protocol furthermore to do machine-machine
signalling), so one can continue the trend, working towards openid supporting machine-machine
authentication for web services, etc. This obviously leaves behind the
restriction of openid as being ONLY a foreground protocol, addressing UCI,
privacy, control and all the other in-your face issues.
So, the more the SSl handshake/event-handlers and openid state
machines merge, the better. Then, a market will emerge for hardware that can do
NAT/load-balancer offloading of https/openid today, just as the same switches now
do multi-gigabit/s ssl offloading and proxing.
If the same trends were also to be incorporating the yet more
powerful foaf+ssl ideas (which are admittedly 3-4 behind the adoption curve of
openid2), those switches would able to set to do what many used to think of
secure XML routers doing (the so-called AOS devices, from the likes of HP and
Intel). But rather than do it with messages, one would be doing it with
sessions – which we know has proven itself a scalable winner for fast
hardware. But those sessions would now have inferecing based routing –
which takes us above and beyond the dynamic routing regimes of the internet
backbones and into true virtual routing.
If one goes with this trend analysis, yes public key is part of
openid, but through an ever tighter association with the SSL handshake and
event handlers, not because openid does an alternative( relatively crappy) job
of repeating what SSL does so well.
There were attempts to add certain NR-features to openid, that unfortunately
got caught up in patent issues. But, many folks see a need for SSL to ALSO
allow the servers behind the loadbancer offloaders to retain a measured
of crypto-level relationship to the client. Here, again, I suspect openid could
be adding that something back to SSL (and be doing something useful without
getting into the patented areas).
If one accepts any of the above, then yes CX and secure
discovery are simply using this “new https” as a bearer, and openid
“extensions” are to such an ssl+openid-bearer what https apps are
to the SSL record layer today – consumers of generic session-oriented security
services. But, the https layer has moved on a generation.