[cap-talk] network level designation and authorization

[Stiegler, Marc D]

> this provides advantages in terms of leverage of existing 
> infrastructure and flexible/efficient implementation and 
> frees the higher level services (YURLS or VatTP interactions) 
> from reinventing the wheel.

What existing infrastructure do you think this leverages? It certainly
doesn't leverage any existing VPN technology. You're proposing inventing
yet another wheel, when captp and YURLs already exist -- those are the
wheels to reuse rather than reinvent :-)


> 
> if you could structure VPN service in this manner (a big 
> 'if', i will admit for now), would this not be preferable to 
> implementation/protocol specific bindings ala httpsy or captp?

So, Bob has a vpn connection to Alice through which he has access only
to file1, i.e., he has authority to use Alice.file1. He also has a vpn
connection to Carol through which he has access only to carol's file
processing serviceA. He wishes to process Alice.file1 with
Carol.serviceA. With captp, he hands the Alice.file1 reference to
Carol.serviceA, they do the Granovetter introduction so that
Carol.serviceA has a direct connection to Alice.file1, and performs the
file processing. Smooth. All built into the protocol.

With vpns, first you must allow multiple vpns to run simultaneously on
Bob's machine (which is a seriously hostile feature for vpns, you should
come up with a different name for whatever it is you are visualizing).

With these mini-vpns, Bob must either forward all messages back and
forth (a problem since file1 is a big file, lots of bits moving in the
triangle), or Bob must have additional authorities with Carol and Alice
to create a new vpn connection between Carol and Alice.

With granovetter protocols, programming over the net feels a lot like OO
programming on a single machine. Much much easier.

--marcs