So there are two threads here, the first being authentication and the second whether the standard browser could be used  (I am still interested in a user story as to why collaborative browsing is interesting/useful as opposed to a shared bookmark or scrapbook).  While I am mostly interested in the second issue personally, I can certainly produce a proof of concept for the first, using client certs via Scott's  Firefox 3.  I don't think it is as hard as you think, and I promise to provide something concrete by the end of the weekend.<br>
<br><div class="gmail_quote">> As to the PKI infrastructure, I don't think it is any harder to work this> out than any of the other key management issues already in play.<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>
<br>
</div>Well, it's a ton of work, and if I can take you on your offer of<br>
patches... we cannot provide a PKI infrastructure as a significant<br>
proportion of schools is disconnected, and we are not keen on imposing<br>
a complex school server setup procedure. So, assuming each XS does the<br>
classic self-signed-cert creation, what we want to do is to follow the<br>
current trust model, which is dead simple: the XO trusts the XS that<br>
it is registered to.<br>
</blockquote><div><br>I am puzzled about the PKI infrastructure you envision.  I envision having a private certificate authority that runs on the teacher's XO and keeps its keystore on a USB thumb drive.  So my favorite CA tool is TinyCA (currently version2) which is written in Perl.  This works very well for me, it has a GTK interface and does its PKI using OpenSSL like everyone else.  This is what I am going to use and document to create the certs.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
During the registration, the XO gives the XS its public SSH key. We need to<br>
<br>
 - change the "Registration" protocol to grab the public part of the<br>
self-signed cert, and add an exception to the PKI checks in Browse.<br>
The registration stuff is implemented in a tool called idmgr (XS side)<br>
and in Sugar profile (XO side). If you looking at idmgr is horrible<br>
enough that you want to help me reimplement it, I have further notes<br>
on that track ;-) We also need to tackle the protocol change in a<br>
reasonably backwards compat manner.<br>
</blockquote><div><br>Please point me to your notes on this, if you would be so kind.  <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
 - figure out a way to use the existing SSH key that the XO has as the<br>
SSL client cert, and to detect it, and match it on the server side.</blockquote><div><br>There are a couple of ways this can work.  I will implement this in my POC.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The server-side apache-embedded code we are doing with mod_python<br>
handlers, and this is a perfect fit for an authen handler.<br>
</blockquote><div><br>Not promising to do the Apache side in Python for the POC.  I write in Perl by choice, so hold your nose.  But are you planning to use Apache or lighttpd for the lightweight XS?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Counting on your help to break this silly thread with actual working code :-)<br>
<div><div></div><div></div></div></blockquote><div><br>I'm happy to oblige!  At last a project that doesn't require me to create a GUI.  Brickbats regarding this plan of action are gratefully accepted.<br><br>Carol Lerche<br>

<br></div></div>