browser change; little, nothing or a lot?

One output of the group can be to outline changes to browsers (and http
libraries used in multi-site apps).

 

We tended to start with: FOAF+SSL has to work with the last 5 years' worth
of deployed browsers.

 

But, we also see threads that say:

 

Change the UI

Change the ClientHello Extensions (to tie into the likes of SRP, to help out
HTTP)

Define a new cert-type like PGP did (hello extension..)

Tie SSL crypto state to HTTP headers, so that MITM of SSL is at least
detectable (the "channel bindings" feature that the Shib group seem to be
looking at, FINALLY!)

 

Anyone looking around has seen Browser plugin toolbars that login to
facebook (with a toolbar generated popup), pre-caching session cookies ready
for websso flows to test, when doing a pingback to a facebook profile page.

 

So one consensus topic can be: how much do we want to recommend changes to
browsers - on a scale from none to significant.

 

IF we argue that login/logout/clientcert state needs to be accommodated in
UI design, my gut tells me: that is so massive in political reality that we
might as well go the whole hog: and define a new cert type for use in SSL's
cert msg, getting past X.509 once and for all for clients. So long as it's a
variant of xmldsig, the level of roar from the crowd is going to be
deafeningly positive. If its otherwise, it will be a groan, and history will
consign another generation of humanity to ASN.1

 

Just imagine a world in which one had xml-dsig signed XRD files sitting as
simple files on hosts, and xmldsig self-signed credentials for webid
protocol. and xmldsig-updated p3P files.. all due to W3C.

 

Just needs will, selling and vision. IE#10 must already be now being
conceived.

Received on Saturday, 12 February 2011 01:25:27 UTC