[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 27 Mar 2002 11:14:35 +0000
I had a bright idea in the wee hours last night.
Oh, alright, kind of candle-dim, but it's a start
Assume an LDS wants to deliver a data and webService
entity into the VRS. It doesn't want anyone but
the owner of this entity to be able to alter/steal
the information/code within it. And the owner wants
to be able to download the entity at any time to
their local LDS and do what they want with it - after
all it's theirs!
It encrypts it with ITS private key.
It sends it off to the VRS.
Now no-one has the public key to be able to
decrypt this entity.
Now I'm thinking that when that webservice is
requeted, it is decrypted on-the-fly by the
executing LDS. This means that it has to get
hold of the public key for this webservice/data
and that's the bit I haven't worked out yet - cos
I went back to sleep.... The nearest I got was that
the decrypting key is somehow embedded within the
entity itself..... hmm....
Assuming that the key aquisition bit can be solved
then this scheme has advantages in that (technically)
only the owner of the entity can decrypt it.
So someone can allow their code/data to be held on
my LDS, safe in the knowledge that I can't look
inside and steel any intellectual info or change it.
Also, we don't need to
But we've got to set it up so that the LDS sandbox
thingy can decrypt it on the fly and execute it.
The webservice component could then use it's data
Or something like that. As you can see I've not
thought it all through yet.
Anyway, something else for the think tank!
Technical Architect - netFluid Technology Limited.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk