[Top][All Lists]
[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
- Re: [Vrs-development] VRS and SEE/DEE goals, (continued)
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Bill Lance, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Bill Lance, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Tim Terlegård, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Open Source, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/26
- Re: [Vrs-development] VRS and SEE/DEE goals, Tim Terlegård, 2002/03/26
- Re: [Vrs-development] VRS and SEE/DEE goals,
Tim Terlegård <=
- Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Tim Terlegård, 2002/03/25
- Re: [Vrs-development] VRS and SEE/DEE goals, Bill Lance, 2002/03/25
Re: [Vrs-development] VRS and SEE/DEE goals, Chris Smith, 2002/03/24