Ivan Krstić wrote:
Ian Bicking wrote:
By "system-wide", do you mean global, country, or school-wide?
I meant operating-system level. Any application will be able to use a
stable API to verify and issue a digsig; each kid will have an
(obviously) unique keypair.
This provides an emergent PKI based on key continuity management (KCM);
it's PKI minus all the really ugly bits that make PKI not work in normal
situations, basically.
OK, I'm trying to get a handle on the kind of identification you are
talking about then. Like Martin I kind of thought we were talking about
laptop/clients identifying themselves to servers.
So are we talking about laptops identifying themselves to other laptops?
Or even the laptop identifying itself to... itself? If HTTP-based RPC
is a major means of communication inside the system, then one can
imagine a need for identification. If nothing else, probably untrusted
Javascript could initiate a local RPC call; and if we want to allow more
peer-to-peer code sharing that isn't entirely trusted (and I'm not sure
how feasible that is) then we'll need to really consider the security of
those communications.
One interesting thing is that URL-based capabilities -- where knowledge
of a URL implies permission to do some action -- is feasible on
localhost since there's no real danger of someone intercepting the
communication. For peer-to-peer communications, does the mesh
networking mean the opposite, that interception should be assumed to be
possible?
Anyway, I'm not sure if any of this relates to KCM. I'm not
particularly familiar with KCM, but I'm guessing it's a little like how
SSH works? -- i.e., you assume that there's a secure initial connection.
That would certainly be better than chain-of-trust systems; I've been
rather shocked how hard PGP clients make it to mark a key as trusted,
when using my human intelligence I can be 100% sure of an identity.
Hmm... anyway, thinking about how this would work with a server,
presumably the student connects to some server and the server sees their
key. How? I don't know... maybe using normal HTTP, like:
# Student goes to a page that specifically requires authentication
GET /login
401 Authorization Required
WWW-Authentication: olpc some-nonce-thingy
# Student gets some popup -- like HTTP Basic login, except it doesn't
# ask for username/password; maybe it asks for an identity, plus
# confirms that a login should occur; maybe offers to automatically
# login in the future?
GET /login
Authenticate: olpc UUID signature
I imagine that the child is identified by some arbitrary thing like a
UUID, instead of a username, which has to be unique within some scope
and can't necessarily be common across all systems. (Even if there is
the possibility to have multiple IDs/profiles, is that sufficient
privacy? In all likelihood most students would use the same ID
everywhere and thus be trackable through all services they might use.)
Oh, and really the response has to give the public key for the user, and
then sign the nonce/UUID with the private key. Then the server stores
the UUID with the public key, and makes sure that the public key doesn't
change in the future. If it does change, then there has to be some
resolution that is probably human-based. Should there even be an ID, or
can the public key be the ID?
Also, communication of any other information (e.g., the student's name)
would be handled separately.
Handling a classroom server environment would probably mean all the
students logging into the system, then the teacher giving them all
permission.
I never much liked HTTP authentication. It's very chatty. It's very
stateless. It doesn't allow for both anonymous and authenticated access
to the same resource. The particulars of HTTP Basic aren't great, but
the problems aren't just with Basic. If we could resolve those thing,
that'd be great.
I guess something like a common identity system would be the sort of
thing that would make up what Martin was talking about as a "web app
framework". That's not normally what's talked about as a "framework",
but I'm not sure what to call it, and I can certainly see the value.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
