[sugar] XO identity shared via Browse

[Greg Smith]

Hi All,

I'm copying in Devel and will drop the sugar list on further replies 
(hope that's the right netiquette in this case...).

Of all the e-mails I have sent this week I never would have guess that 
this one would generate the most responses! Maybe it was the use of the 
term SSO :(

I updated the requirements to address Michael's comments below.

The one which did not engender a requirement update are noted here:

 >   what software, on the XO, should be responsible for proving identity?
GS - It says Browse and I mean only Browse (that's why I sent it to the 
sugar list initially)

 >      if Browse, how does Browse talk to the registration code?
 >      if Browse, what about Gmail, Help, WikiBrowse, ...
GS - Not a requirement either way on "registration code". Not a 
requirement to work with Gmail, Help or Wikibrowse, but I left in other 
server (Gmail case?) as nice to have.

 >   when should we make use of an ability to prove user identity?
GS - Not sure what this is asking. Its purpose is to make it easier to 
work with XS. The identity should be tied to the XO hardware (except as 
noted below). I want the XS to know that its talking to the same XO as 
before without the user needing to enter anything.

 > security)   who are the principals?
 >   what are their goals?
 >   what attacks concern us?

GS - In general I don't want any other devices to be able to appear to 
be the XO. We can assume that the XS <-> XO is a secure network not 
visible to the outside workd (whether that is true in practice is 
another story). So I moved the encryption and stringent security 
requirements to the optional case where the XO is talking to a non-XS 
server.

 > users)
 >   what do we do if something looks wrong?
 >      fail silently?
 >      log an error somewhere?
 >      fail loudly?
 >      are there any user overrides?
GS - Make sure it never fails! Just kidding. Give me some concrete 
examples for how it might fail and I'l think about it some more.

 >   can I turn this off?
GS - Good suggestion. Added.

 >   can I have multiple identities?
 >   can I share my identity with someone else?
GS - No for both. The XO is the indentity.

 >   what happens if the user loses their laptop and gets a new one?
 >   what happens if the server breaks and a new one is installed?
 >   what happens if I move from an old school to a new one?
 >   what happens when the XO's software is upgraded? downgraded?

GS - I added two server side requirements to cover this. In general, I 
assume the XS is secure and that any identity data can be passed 
securely from one XS to another.

HTHs. Good questions and let me know if the requirements are still not 
clear.

BTW This came up because the current XS restore interafce requires that 
you type in the serial number of the XO to find its backed up files. 
There was also a request on the server list to make the backup and 
restore secure (hidden from devices other than the backed up XO).

That is the must have requirement. The use of password less identity 
outside the "secure" environment of the school is nice but not critical. 
Just have the kids log in once then use cookies or HTTPS or OpenID for 
that, I'm not partial to the technology and if there's no consensus we 
can live without it.

I'm OK with the debate but if we release 9.1.0 without making it easy to 
get your files off the XS and to automaticaly associate with the right 
Moodle identity, then we will miss an important user valuable feature.

Thanks,

Greg S

Michael Stone wrote:
> On Tue, Dec 02, 2008 at 03:56:06PM -0500, Greg Smith wrote:
> 
>> We're mostly thinking of the school server as the server side but a
>> more generic solution may be acceptable.
> 
> I'm relatively comfortable with our vague identity plans for the XS but
> I'd like to know more about your idea for "a more generic solution"
> before going further in that direction.
> 
>> That's one example. I would also like any Web server to be able to 
>> extract the XO identity and use it in CGI (e.g. PHP) for processing.
> 
> "What could possibly go wrong?" -- anonymous.
> 
>> I put a stub of a requirement for it on our roadmap here:
>> http://wiki.laptop.org/go/Feature_roadmap#Single_Sign_on_from_Browse
> 
> This seems decent so far.
> 
>> Do you have any ideas or designs for how we can achieve that?
> 
> We discussed it at SugarCamp. The essential idea from that discussion
> was to have the XO and the XS exchange certs at registration time so
> that they can later prove their identities to one another on demand.
> 
> The tricky bits involve scope, security, users, and maintenance:
> 
> scope)   what are we proving identity to? e.g.:
>      one single XS, ever.
>      one single XS, whichever we're currently registered with
>      several servers at once
>      other XOs
>   what software, on the XO, should be responsible for proving identity?
>      if Browse, how does Browse talk to the registration code?
>      if Browse, what about Gmail, Help, WikiBrowse, ...
>      if something else, how does the something else talk to Browse?
>   when should we make use of an ability to prove user identity?
> 
> security)   who are the principals?
>   what are their goals?
>   what attacks concern us?
> 
> users)
>   what do we do if something looks wrong?
>      fail silently?
>      log an error somewhere?
>      fail loudly?
>      are there any user overrides?
>   can I turn this off?
>   can I have multiple identities?
>   can I share my identity with someone else?
> 
> maintenance)
>   what happens if the user loses their laptop and gets a new one?
>   what happens if the server breaks and a new one is installed?
>   what happens if I move from an old school to a new one?
>   what happens when the XO's software is upgraded? downgraded?
> 
> Regards,
> 
> Michael
>