• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: Mark S. Miller

Markm wrote:
> If I have a capability URI string that designates a
> particular object, and
> therefore grants a certain authority, why shouldn't I be
> able to use that
> either from a browser (Droplet/CGI style) or from E
> (Pluribus style), if the
> object is accessible in both ways? It seems strange that I
> would need a new
> designation token in order to invoke the same designated
> object through a
> different message conveyance medium.
>
> Besides, the protocol binding mechanism you already
> proposed would be
> adequate: httpy: gives back other URIs that contain their
> own protocol
> identifier. If an object can be reached through both
> https: and cap:(?),
> then you could get both back. You might also say in your
> httpy: query which
> protocols you are prepared to speak.

I introduced something like this in my response to Ben. The idea was to create a family of schemes, all ending in 'y' that use SLS to locate multiple possible hosts. This is similar to the family of schemes that append 's' to indicate protocols that will be run over TLS. I like the way this turns SLS into a general replacement for DNS that all schemes can use.

Ben referred to this as a "URI -> URL transformation". I think that this is the best way to look at the service that the SLS provides.

In my last message, I suggested a transformation that turns a URI into a list of URLs of a particular scheme.

Since you're expressing a desire for a single, protocol neutral, capability URI, maybe we should create a URN that can be transformed into a list of URLs of mixed schemes (where I started from in the first httpy post).

I'll suggest:

urn:cap:<public-key-hash>/<cap-string>

where <cap-string> is a host specific string. In the case of an E Vat, it's a SwissNumber. In the case of a Droplet database, it's a <zone>/<database>/<context>/<swiss-number>.

So now our SLS responds to two types of location queries.

When the user-agent has a urn:cap, it sends a location request (public-key-hash) and gets back a list of (scheme, DNS hostname, IP address, port).

When the user-agent has a URI like HTTPY, it sends a location request (public-key-hash, scheme) and gets back a list of (DNS hostname, IP address, port).

> However, I notice something present in cap: URIs that's
> missing in your
> proposal: The list of TCP/IP addresses of the SLSs to
> consult.

Since I use SLSs to localize requests, as well as to route them, it doesn't make sense to specify SLSs in the URI. The entity creating the URI can't know in advance where the URI will be used from.

> Sure, the
> browser can be configured to check some well known ones,
> but if you're going
> to have a truly decentralized and non-corruptible system,
> it's important for
> the URI string to carry its own list of suggested SLSs as
> well. Otherwise,
> the well known SLSs becomes a point of vulnerability.

I wasn't expecting to have any 'well known SLSs'. I was expecting each region of the web to have its own SLS. If you're concerned about the security of the local SLS, you can run your own without having any security dependencies on any other SLSs. This is why the signed SLS entry message is just forwarded, as is, around the web of SLSs. You might then configure your user-agent to query multiple SLSs and report any discrepancies between them.

I believe this is a truly decentralized system that can strongly isolate any corruption.

Tyler

[ Next ]
• [ Previous ] In reply to: Mark S. Miller