vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] VRS and SEE/DEE goals


From: Tim Terlegård
Subject: Re: [Vrs-development] VRS and SEE/DEE goals
Date: Mon, 25 Mar 2002 20:27:24 +0100

> This request payload may have arrived at the VRS via SOAP over HTTP, SMTP,
> FTP or XML-RPC or any other 'To Be Designed' protocol.
> The PortManager -> request extraction part of the system is modular.  Once
> the request payload has been extracted by the appropriate handler and the
> recipient webservice identified, the webservice is invoked and the request
> processed.

Looks like a good plan!


> > Authentication will prevent anyone from running executable code on
> > another machine.
>
> Any code deployed into the VRS will run on *any* LDS.

What do you mean by "deploying code into a VRS"?

> However, LDS's do not have to release their services to the VRS propper.
> They may announce that they are available, but keep them private.  Anyone
> requesting these services will see them being run on the owners LDS.

Wouldn't it be nice to have access controls for the services? Could be too 
complex perhaps... But how could one decide if an MA or DataSet should be 
allowed to execute on a certain machine? Let's say I program a DataSet that 
shuts down a box, but this is just meant for my own box at home. This DataSet 
shouldn't be allowed to execute on your box. I guess you'd be quite surprised 
if that would happen  :-)


> > Do you want for instance a bank to be able to use the VRS? If so, the
> > bank needs an assurance that the user can't deny it withdraw a certain
> > amount of money. They need the non-repudiation feature.
>
> Now I think you've hit upon something I raised with Bill a while back - but
> not very eligently I admit.  I think that *some* VRS's will NOT accept
> unsolicited join requests.  That is, if the VRS doesn't know who you (the
> LDS) are in advance, you can't join.

Yes, but this is authentication, not non-repudiation. Authentication verifies 
that you are then one you say you are. Non-repudiation makes the 
authenticated person unable to deny transactions. It's like a digital 
receipt. If you go to the bank you authenticate yourself with your driving 
license (in Sweden anyway). When you withdraw money you sign a receipt. If 
you didn't have to sign that receipt, you could withdraw money without a 
trace. You have authenticated yourself, but you can deny the transaction ever 
taken place. This is probably desired for some greedy people, but 
non-repudiation is a nice feature I'd say.

-- Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]