XO identity shared via Browse

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

XO identity shared via Browse

Greg Smith-18
Hi Tomeu and Browse engineers,

Talking with Martin L recently he mentioned that you have some ideas on
how the XO can communicate its identity (e.g. serial # and maybe user
name) with a web server. We're mostly thinking of the school server as
the server side but a more generic solution may be acceptable.

The main idea is to eliminate the need for students to ever type in a
user name and password. e.g. they should be able to just hit the Backup
and Restore URL and see their files without having to login or find
their serial number in a list.

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.

It should also be encrypted so that the XO cannot be spoofed. e.g. only
the XO which backed up and can see or restore its own files (possibly
with an admin override).

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

Do you have any ideas or designs for how we can achieve that?

Comments and questions welcome.

Thanks,

Greg S

_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
Can we please consider making this OpenID? It would really help to
integrate everything. I made a proposal about it some time ago, and
currently SugarLabs wiki has OpenID, which by the way, is a great.

Sebastian

2008/12/2 Greg Smith <[hidden email]>:

> Hi Tomeu and Browse engineers,
>
> Talking with Martin L recently he mentioned that you have some ideas on
> how the XO can communicate its identity (e.g. serial # and maybe user
> name) with a web server. We're mostly thinking of the school server as
> the server side but a more generic solution may be acceptable.
>
> The main idea is to eliminate the need for students to ever type in a
> user name and password. e.g. they should be able to just hit the Backup
> and Restore URL and see their files without having to login or find
> their serial number in a list.
>
> 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.
>
> It should also be encrypted so that the XO cannot be spoofed. e.g. only
> the XO which backed up and can see or restore its own files (possibly
> with an admin override).
>
> 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
>
> Do you have any ideas or designs for how we can achieve that?
>
> Comments and questions welcome.
>
> Thanks,
>
> Greg S
>
> _______________________________________________
> Sugar mailing list
> [hidden email]
> http://lists.laptop.org/listinfo/sugar
>



--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Yamandu Ploskonka
what about
 have the client send an Authorization header, in the Browse HTTP request.

This is part of standard HTTP request/response
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8

One problem that those who see the complicated future is that this
exchange will only be validated with a "home" server, would be hard to
have the XO manifest itself to other servers.

Also, re:spoofing, there would need to be an update of the data being
sent, maybe changes with the clock, daily? Don't know how to keep the
algorythm secure and still have this Open.


Sebastian Silva wrote:

> Can we please consider making this OpenID? It would really help to
> integrate everything. I made a proposal about it some time ago, and
> currently SugarLabs wiki has OpenID, which by the way, is a great.
>
> Sebastian
>
> 2008/12/2 Greg Smith <[hidden email]>:
>  
>> Hi Tomeu and Browse engineers,
>>
>> Talking with Martin L recently he mentioned that you have some ideas on
>> how the XO can communicate its identity (e.g. serial # and maybe user
>> name) with a web server. We're mostly thinking of the school server as
>> the server side but a more generic solution may be acceptable.
>>
>> The main idea is to eliminate the need for students to ever type in a
>> user name and password. e.g. they should be able to just hit the Backup
>> and Restore URL and see their files without having to login or find
>> their serial number in a list.
>>
>> 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.
>>
>> It should also be encrypted so that the XO cannot be spoofed. e.g. only
>> the XO which backed up and can see or restore its own files (possibly
>> with an admin override).
>>
>> 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
>>
>> Do you have any ideas or designs for how we can achieve that?
>>
>> Comments and questions welcome.
>>
>> Thanks,
>>
>> Greg S
>>
>> _______________________________________________
>> Sugar mailing list
>> [hidden email]
>> http://lists.laptop.org/listinfo/sugar
>>
>>    
>
>
>
>  
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Luke Faraone
Administrator
On Tue, Dec 2, 2008 at 16:32, Yamandu Ploskonka <[hidden email]> wrote:
Also, re:spoofing, there would need to be an update of the data being
sent, maybe changes with the clock, daily? Don't know how to keep the
algorythm secure and still have this Open.

That is mistake #1: Secret algorithms are _less_ secure than open ones,  as secret ones have a smaller group of testers. There's a reason why _everybody_ uses AES, Blowfish, and the lot; it's because they've been publicly tested and held up to it.

OpenID, specifically, would be hard to implement in the current version of the spec, as our devices FQDNs will be changing often. Locally, it might work, but remote identification is a problem.

A tried-and-true way to go about this would be using Client Side Certificates, which has found to work under browse. In addition, the user data can be encrypted using GPG prior to transmission/storage, and if you want escrow of data you can encrypt it for two keys.

-lf


_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
> OpenID, specifically, would be hard to implement in the current version of
> the spec, as our devices FQDNs will be changing often. Locally, it might
> work, but remote identification is a problem.

Actually, my regular laptop's FQDN changes all the time and I have no
problem remembering my OpenID ? Perhaps my browser can help me with
this?

Frankly I think its the only way to scale. No problem doing OpenID
either on network or locally. Added bonus of distributed single sign
on (for instance, to the sl wiki).

--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Luke Faraone
Administrator
On Tue, Dec 2, 2008 at 17:07, Sebastian Silva <[hidden email]> wrote:
> OpenID, specifically, would be hard to implement in the current version of
> the spec, as our devices FQDNs will be changing often. Locally, it might
> work, but remote identification is a problem.

Actually, my regular laptop's FQDN changes all the time and I have no
problem remembering my OpenID ? Perhaps my browser can help me with
this?

That's a different model. We want the openID _provider_ to be either on the laptop itself or on the school server. Since the _server_ has a changing FQDN, this becomes harder. The solution would be to propose a change to the protocol or register the school servers domains (or subs) with a Dynamic DNS provider.

-lf


_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
> That's a different model. We want the openID _provider_ to be either on the
> laptop itself or on the school server. Since the _server_ has a changing
> FQDN, this becomes harder. The solution would be to propose a change to the
> protocol or register the school servers domains (or subs) with a Dynamic DNS
> provider.
>
Now we are talking, this is only a technical problem.

Clearly, the provider should not be on the laptop. That would defeat
the entire purpose of having an "Identity Provider". Now on the
server:

One solution is to provide Dynamic DNS, as you say, and its one I like
very much, I had thought about it too for our planned server
implementations.

Second, and perhaps simpler: woudnt the school server control DNS for
the laptops?
What about just make point "identityprovider.local" to your local
schoolserver? - Ah - i got it, the other end must reach the identity
provider too... !

So one solution, dynamic DNS, is pretty robust an tried plus simple.
+100 for that.

Sebastian



--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Benjamin Schwartz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Silva wrote:
> Clearly, the provider should not be on the laptop. That would defeat
> the entire purpose of having an "Identity Provider".

You misunderstand our purpose.  The immediate technical goal is to
authenticate that a given connection goes to a particular XO.  The machine
itself then becomes the identifying token used to authenticate the
identity of the user.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk1tuEACgkQUJT6e6HFtqSraACghQTdVFQ393qfQtMmaunUNpW8
FR8AnRgqh871GjKC5SfTwVRXCzFMPXb1
=fLmO
-----END PGP SIGNATURE-----
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Luke Faraone
Administrator
On Tue, Dec 2, 2008 at 17:29, Benjamin M. Schwartz <[hidden email]> wrote:
You misunderstand our purpose.  The immediate technical goal is to
authenticate that a given connection goes to a particular XO.  The machine
itself then becomes the identifying token used to authenticate the
identity of the user.

Unfortunately that will only work for web applications which are "sugar-aware"; the plus of openID is it's one standard, and everyone (soon) will support it.

-lf


_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Martin Langhoff
In reply to this post by Sebastian Silva-2
On Tue, Dec 2, 2008 at 8:19 PM, Sebastian Silva
<[hidden email]> wrote:
>> That's a different model. We want the openID _provider_ to be either on the
>> laptop itself or on the school server. Since the _server_ has a changing
>> FQDN, this becomes harder. The solution would be to propose a change to the
>> protocol or register the school servers domains (or subs) with a Dynamic DNS
>> provider.
>>
> Now we are talking, this is only a technical problem.

Hi! We've discussed openid several times on this list -- do google the
archives for the full argument :-) --

It's reasonably likely that the XS will be an OpenID IDP (noting all
the serious caveats around OpenID that make it a phishing-magnet), but
_first_ the laptop needs to identify itself to the xS.

So we are talking about that first step. As you've spotted, we can't
use openID there. The plans that seem viable, after a lot of
consideration, are

 - A backchannel call using SSH - Browse.xo when connecting to
something that looks like the XS will trigger an ssh connection to the
server, grab a one-time-use token over the ssh connection and use it
to prove its identity over http.

 - A challenge-response call using the fact that the XS knows the
public SSH key of the XO. So Browse could request a special url, the
XS respond with a random string that the XO has to sign with its key
and post it back to the XS - which can verify the sig.

Once that step happens, the XS hands a cookie to the XO (the process
above is fairly expensive!). From that point onwards, we are
vulnerable to spoofing unless we switch to https (which we will
eventually do, but right now is very complicated for a long list of
reasons).

If we could switch to https easily, we could skip all this song and
dance and just use client certs.

cheers,




m
--
 [hidden email]
 [hidden email] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Martin Langhoff
In reply to this post by Greg Smith-18
Thanks for your opening email - one quick comment...

On Tue, Dec 2, 2008 at 6:56 PM, Greg Smith <[hidden email]> wrote:
> 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.

the plan for that is that

1 - the special authentication scheme we come up with is exclusively
between Browse.xo and the XS -- based on a preexisting relationship
(registration!)

2 - other standard webapps can recognise the identity of the XO via
OpenID, a scheme whereby the XS says "yes, that XO is Greg as it
claims to be". An openID "identity provider" acts a bit as a country
issuing a passport.

cheers,



m
--
 [hidden email]
 [hidden email] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Luke Faraone
Administrator
In reply to this post by Martin Langhoff
On Tue, Dec 2, 2008 at 17:42, Martin Langhoff <[hidden email]> wrote:
If we could switch to https easily, we could skip all this song and
dance and just use client certs.

Why can't we, exactly? More and more non-standardness is _bad_ for security.

-lf

_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Benjamin Schwartz
In reply to this post by Luke Faraone
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke Faraone wrote:

> On Tue, Dec 2, 2008 at 17:29, Benjamin M. Schwartz <[hidden email]
>> wrote:
>
>> You misunderstand our purpose.  The immediate technical goal is to
>> authenticate that a given connection goes to a particular XO.  The machine
>> itself then becomes the identifying token used to authenticate the
>> identity of the user.
>
>
> Unfortunately that will only work for web applications which are
> "sugar-aware"; the plus of openID is it's one standard, and everyone (soon)
> will support it.

This situation is confusing; perhaps Sebastian is right.  OpenID 1.0
identities are URLs, so in order for the XO to be the identity provider,
it must have at least one guaranteed FQDN.  The DNS system then provides
the authentication mechanism.  If Scott is able to achieve his goal of One
Domain Name Per Laptop, then this seems entirely reasonable.  We can run
an identity provider on the laptop as a trivial HTTP server.

If we cannot come up with a way to provide oersistent DNS (or for OpenID
2.0, even XRI) names for each laptop, then we cannot run the identity
providers on the laptops.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk1u0YACgkQUJT6e6HFtqQeYwCdHwKz11clxtT/YKKCVkCz/ZNi
G9wAnjojHcjUyWgkwy1wSzl6uQ+Uzuh0
=2nk7
-----END PGP SIGNATURE-----
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
In reply to this post by Martin Langhoff
> It's reasonably likely that the XS will be an OpenID IDP (noting all
> the serious caveats around OpenID that make it a phishing-magnet), but
> _first_ the laptop needs to identify itself to the xS.

Ok yes I did misunderstand the original problem, sorry.
Please let me be of all assistance I can in integrating OpenID on the
XS or trying out stuff here in Peru. This is an important part of our
strategy down here.

--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Michael Stone-7
In reply to this post by Greg Smith-18
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
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Daniel Drake-5
In reply to this post by Greg Smith-18
On Tue, Dec 2, 2008 at 8:56 PM, Greg Smith <[hidden email]> wrote:
> 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
>
> Do you have any ideas or designs for how we can achieve that?

I think this can be quite simple. The XOs will already be signed onto
the school server through jabber, so the XS can therefore map IP
addresses to the registration details of XOs?

Daniel
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Benjamin Schwartz
In reply to this post by Martin Langhoff
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Langhoff wrote:
>  - A backchannel call using SSH
>  - A challenge-response call using the fact that the XS knows the
> public SSH key of the XO.

You really like SSH!

I'm less sure, though.  I'd prefer a standard system.  One interesting
option is OpenID authentication over Jabber (standardized as XEP-0070),
e.g. http://openid.xmpp.za.net/.  In this system, OpenID authentication
requests appear to the user as chat messages.  This means that the
Identity Provider can live on any jabber server with which the school
server is federated.  In fact, if we can accept standard chat invitations
in the UI, we could simply federate the school server with xmpp.za.net and
declare victory!

Architecturally, this approach is appealing to me because Jabber IDs, not
SSH pubkeys, are our principal identifiers.  It also gives us the
flexibility of putting the identity provider almost anywhere.  If the XO
runs its own jabber server, then the identity provider can live on the XO
or any jabber server with which the XO is federated.

An ideal form of this scheme would include creating an implementation of
XEP-0070 (still standard-compliant) that sends the authentication approval
request over XMPP in a machine-readable format, to be received by a
consumer on the XO that approves or denies the request, possibly based on
some interaction in a special-purpose GUI.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk1xM8ACgkQUJT6e6HFtqQYOwCfX94DBVpPikPkvmDGkaXYezgV
Ql0AoIg7iizkouSv7Ake6856qJT/GqRM
=SJ0s
-----END PGP SIGNATURE-----
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
In reply to this post by Benjamin Schwartz
Heh, so it ends up I did have an interesting unintended proposal to make.

Then, if it  was to use OpenID, it would be in a novel way. Still it
does make perfect sense. See:

1.- The user requests access.
2.- The server checks with his laptop.
3.- The laptop confirms the user is requesting from it.
4.- The server considers the user identified.

This looks like bending the scope of OpenID but in reality it is not.
It was intended all along that Identity Providers can be pretty much
anything or validate against anything (not just user/pass but also
say, biometrics).

To implement this would be much more standard and much less
*"magical"* than underground ;-) ssh tunneling voodoo. Its even sort
of intuitive.

Now it really becomes interesting when the laptop uses face / voice
recognition to validate your identity... Heheh. ( /me puts on his
tinfoil hat ).

So for the laptop to be your identity provider, it needs a FQDN. If
the schoolserver has one by Dynamic DNS, can't it also provide DNS for
the CNAME?

As in say:     sebalaptop1.myschool.myregionsdns.edu...
Being the "myschool" dns subdomain administered by the school server?

If Scott can provider one domain name per laptop, then i really think
this is the most sensible, simple and standard solution.

Let activities deal with OpenID themselves, there are libraries in
python for it.
This also sidesteps all wierd sorcery regarding communicating with browse.

Sebastian

2008/12/2 Benjamin M. Schwartz <[hidden email]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Luke Faraone wrote:
>> On Tue, Dec 2, 2008 at 17:29, Benjamin M. Schwartz <[hidden email]
>>> wrote:
>>
>>> You misunderstand our purpose.  The immediate technical goal is to
>>> authenticate that a given connection goes to a particular XO.  The machine
>>> itself then becomes the identifying token used to authenticate the
>>> identity of the user.
>>
>>
>> Unfortunately that will only work for web applications which are
>> "sugar-aware"; the plus of openID is it's one standard, and everyone (soon)
>> will support it.
>
> This situation is confusing; perhaps Sebastian is right.  OpenID 1.0
> identities are URLs, so in order for the XO to be the identity provider,
> it must have at least one guaranteed FQDN.  The DNS system then provides
> the authentication mechanism.  If Scott is able to achieve his goal of One
> Domain Name Per Laptop, then this seems entirely reasonable.  We can run
> an identity provider on the laptop as a trivial HTTP server.
>
> If we cannot come up with a way to provide oersistent DNS (or for OpenID
> 2.0, even XRI) names for each laptop, then we cannot run the identity
> providers on the laptops.
>
> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkk1u0YACgkQUJT6e6HFtqQeYwCdHwKz11clxtT/YKKCVkCz/ZNi
> G9wAnjojHcjUyWgkwy1wSzl6uQ+Uzuh0
> =2nk7
> -----END PGP SIGNATURE-----
>



--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Sebastian Silva-2
In reply to this post by Benjamin Schwartz
> I'm less sure, though.  I'd prefer a standard system.
+1

>One interesting
> option is OpenID authentication over Jabber (standardized as XEP-0070),
> e.g. http://openid.xmpp.za.net/.  In this system, OpenID authentication
> requests appear to the user as chat messages.  This means that the
> Identity Provider can live on any jabber server with which the school
> server is federated.  In fact, if we can accept standard chat invitations
> in the UI, we could simply federate the school server with xmpp.za.net and
> declare victory!
Yes and no. Yes, jabber integration will make the GUI better. I'd
suggest resource access requests (authentication is already done via
jabber) NOT show as chat messages of course (even if using XMPP
internally).

>
> Architecturally, this approach is appealing to me because Jabber IDs, not
> SSH pubkeys, are our principal identifiers.  It also gives us the
> flexibility of putting the identity provider almost anywhere.
This is exactly what OpenID is made for.

> If the XO
> runs its own jabber server,
Oh no I would not go there no way! Perhaps it can respond (and
confirm) resource access requests via having a http identity provider,
as suggested in prior message.

> then the identity provider can live on the XO
> or any jabber server with which the XO is federated.
Why on earth would you run a jabber server on your XO?

> An ideal form of this scheme would include creating an implementation of
> XEP-0070 (still standard-compliant) that sends the authentication approval
> request over XMPP in a machine-readable format, to be received by a
> consumer on the XO that approves or denies the request, possibly based on
> some interaction in a special-purpose GUI.
Yes, or perhaps no gui is needed if the point is just to identify the laptop?

> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkk1xM8ACgkQUJT6e6HFtqQYOwCfX94DBVpPikPkvmDGkaXYezgV
> Ql0AoIg7iizkouSv7Ake6856qJT/GqRM
> =SJ0s
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar mailing list
> [hidden email]
> http://lists.laptop.org/listinfo/sugar
>



--
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/
_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
Reply | Threaded
Open this post in threaded view
|

Re: XO identity shared via Browse

Luke Faraone
Administrator
In reply to this post by Sebastian Silva-2
On Tue, Dec 2, 2008 at 18:35, Sebastian Silva <[hidden email]> wrote:
3.- The laptop confirms the user is requesting from it.
 
This is somewhat of a problem: how can we do this without giving the user too many "did you really mean this" prompts?

-lf


_______________________________________________
Sugar mailing list
[hidden email]
http://lists.laptop.org/listinfo/sugar
123