Google Groups

Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)

Peter Williams Aug 31, 2009 11:44 AM
Posted in group: OpenID



From: John Bradley []
Sent: Sunday, August 30, 2009 2:06 PM
To: Peter Williams
Cc: Story Henry;;
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)


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 one iota)).


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.