[cap-talk] Bank accounts, file/directory capabilities, mashups (was: Re: Scope/span... network reach)

[Jed Donnelley]

At 03:53 AM 3/3/2009, Marcus Brinkmann wrote:
>Jed Donnelley wrote:
> > At 11:16 AM 2/27/2009, Marcus Brinkmann wrote:
>...
> >> send me per email a capability that designates the authority to 
> make deposits
> >> to your bank account (presumably in a US bank).  I further 
> assume that I can
> >> get or already  have a capability to my bank account (in a German national
> >> bank) that allows to make withdrawals.  Would I be able to use these two
> >> capabilities to transfer 1 EUR from my account to yours?  Where 
> is the service
> >> located that I would need to use to do that?  Who owns and runs 
> that service,
> >> and who pays for it?  Who regulates it?
> >
> > This doesn't seem to me a very interesting example, because we
> > essentially already have such "capabilities".  Of course I would only
> > send you a "deposit-only" capability to my account.  This is
> > essentially an account number.  You could send me such a capability
> > to your account.  I could deposit into your account by using my full
> > access capability (typically in current electronic form with
> > username, password, various registered info, etc.) and the deposit
> > only account that you sent to me.
> >
> > The service is of course provided by the banks.  Nothing new there.
>
>But the account number is *not* a capability.  It is pure designation.

The above is literally true, but as I noted, such a designation is all
that is needed to accept money into an account - at least into my account.
Why wouldn't my bank, acting on my behalf, accept money from any source?
The place where authorization is needed is for transfers out, withdrawals.

>I picked this example because transferring money from one account to another
>can be seen as a single operation that involves two capabilities (at least)
>which likely come from very separate domains (separated by organization, even
>by nation).  A system where such an operation would be implemented by
>capabilities (real capabilities, not by can-be-seen-as-such designation) seems
>virtually impossible to achieve to me, for many practical reasons.
>
>The service of international money transfer seems to be quite complex.  It
>takes weeks, money is moved across several organizations, and you have to pay
>a premium to get any guarantee that it will even arrive.

I don't see how that complexity is relevant.  As long as the cost is born by
the "sender" of the money, I also think the cost aspect isn't significant.

> >> Would it work also if I were to live in Cuba or N. Korea instead 
> of Germany?
> >
> > Certainly...
>
>The reason I picked Cuba and N.Korea was to amplify the practical differences
>in agreeing to a single world-wide capability system.

I don't believe the issue of authorization (in this case for a bank withdrawal)
is significantly related to the complexity or indeed any practical differences
and/or complexities of the action enabled by the authorizations.  Look at how
many operations are enabled by essentially simple username/password pairs.
Some such operations the very sorts of banking transactions that you are
concerned about, many are complex, but all are authorized by a very simple
mechanism.  Capabilities, even network standard capabilities, are just such
a simple mechanism.

I can see where some concern is legitimate with what might be high value
transactions - perhaps life and death like medical authorizations or
high value bank transfer authorizations, etc.  However, in some cases
even access to a file (perhaps a national or corporate secret) can be
a high value transaction where proper authorization is essential.  I
believe the mechanisms for authorizing actions can be considered and
developed distinctly from the actions that they authorize.  In fact
that philosophy applied to computerized actions was the essence of
the Distributed Capability Computer System:

http://www.webstart.com/jed/papers/DCCS/

> > I prefer working with files and directories as examples because these
> > are the main objects managed by the current market leading OSs of
> > Windows, Mac, and Unix.
>
>But nobody needs capabilities to share files and directories from such
>systems.  Between internal distribution, public distribution and sending
>copies around by email all common use cases I can think of are covered.

Hmmm.  While I agree that many useful things can be done with one time
copying of files (e.g. send in email, etc.) and with public read access,
the case that I consider useful is that of managing read and write
access to individual objects by individual subjects.

A simple example is that of a corporate wiki, where there may be
project directories containing information (presentations, data,
spreadsheets, etc.) about sensitive high value projects.  Sorry to
others for the repeat, but an example is where some people need
to be able to access (read and sometimes write) financial information,
and other people need to access (read and sometimes write) technical
information.  We have real wikis and real projects of this sort.
Sadly they currently can only function inside our corporate
environment (with shared IDs and password authorizations).  I would
like to have such a facility on the Internet.

Such systems of limited scope have been useful for many, many years.
Widening their scope across organization boundaries on the Internet I
consider a significant value add.

>Let's imagine that for some reason (which?) we decide that transfering files
>by capability is a good idea.  Then you send me a directory capability of some
>good music you recorded, and I want to copy it to my own storage for later
>access.  Now, either you have your computer turned on 24/7 and have special
>expertise or a maintenance contract for somebody to take care of the server
>software on your computer, or you are using a web service, say Google Drive,
>for those files.  But I don't trust Google and use Tahoe instead.  How do the
>capabilities (and/or the data) move from Google to Tahoe?  Now we are getting
>closer to an example that is similar to the money transfer example.

As I noted in another message, I think Tahoe is quite a good example.  If I
could include a capability to a Tahoe file or directory in a message, e.g. here
as with this wideword capability:

https://wideword.net/doc/jDrHFnTlHnFn%2BzTIGKIk8A%3D%3D

then I feel we would be closer to what I'm looking for.  Particularly if
such a capability could be to a deep read-only directory of objects.
I think the current Tahoe read-only notion would be fine for now.

Unfortunately, unlike with Web access, it seems one needs a Tahoe client
to access Tahoe objects.  This raises the barrier to entry.  I wonder
if we could get them to offer a Web interface to their objects?  The
value they offer of being able to essentially "mount" a directory
as a file system is terrific, but the cost to getting there seems high
to me.  I have the client installed and some file/directory data stored,
but still find it awkward to use for sharing.  Who can I send Tahoe
capabilities to?

>Again, I can easily see how this could be made to work if we both use Google
>Drive, or in general the same service provider.  I don't see it scaling across
>multiple providers.

I believe this is an important point.  It's a point that to me seems to be
a common misunderstanding in people who've dealt mostly with IBAC
authorization systems.

One absolutely needs to be able to access the provider of a service to
be able to exercise an authorization provided by that service.  So,
for example, if you give me a file or directory capability, I need
to be able to access (communicate to) the server of the capabilities
that you've given me to avail myself of their services (e.g. to read
or write a file or directory).

However, I think the directory example is a particularly good one.
Consider a directory service that simply stores name/capability
pairs.  Capabilities that are in some network standard form
(as with your discussion with David-Sarah Hopwood (e.g. as with
a URL), but may be serviced anywhere (again as with a URL).

In that case then just as with fetching links from Web pages,
I can exercise an authority on one object (say read access to
a directory) on one server, and fetch (e.g. "fetch abc" which
returns the 'abc' capability) a capability to another object
on a distinct server.

Such a pattern of operation is very much like fetching links
from Web pages (in fact the fetch of the read-only capability
to the above wideword page I think qualifies exactly), BUT
(and for me it's a large BUT) what you get back combines
designation with authorization (as with YURLs/Web keys).

>The advantage of the money transfer example is that it is an important real
>world use case for common people, while the example involving files seems
>contrived to me.

I admit that I'm an IT professional, but I exercise authorized
access to files of varying value dozens (hundreds?) of times
a day, whereas I exercise my authority to do such a banking
transaction perhaps once a week or once a month?

I can't tell you how many times I set up username/password
pairs for people - e.g. for access to wikis, svn repositories,
email (e.g. imap) services, chat, etc., etc., etc.  Five
just today...  Do you ever run htpasswd?

Let me ask, how many passwords do you have Marcus?  If you
are anything like me you have at least dozens.  I don't know about
you, but most of mine authorize access to information read/write
access (whether called "file" or not - perhaps databases, etc.)
of one form or another.

Being able to store object authorizations in such information
objects and use them across organizational boundaries (esp.
over a network like the Internet) is what I'm looking for.
To me this is the essence of what has been referred to as
the "mashup" problem, e.g.:

http://blog.programmableweb.com/2007/10/01/douglas-crockford-on-the-mashup-problem/

I consider this problem very substantive, familiar to anyone
who has a username/password pair that authorizes some Web service,
and essentially solved by network standard capabilities.

You got me a bit worked up, but there you go.  I can understand
how this problem is difficult to appreciate in today's environment
where there is essentially no controlled sharing across organizational
boundaries via the Internet/Web ("mashup"s for services that require
authorizations).  When Apple's "Hypercard" hypertext system was
new and being discussed, I was quite familiar with the Internet and
concepts like distributed capabilities, but I still didn't "see"
(grok) what is obvious to me now, the value in even hyperlinked
network access that doesn't include authorizations.  If what you're
"used to" and consider a valued "norm" is an environment where object
authorizations can be communicated between people and processes in
messages, stored in directories and other objects, etc. and you
recognize the significant added value in such a "mashup ready"
environment over and above such linking without authorized access
control, then I believe you would actively seek such an environment
as I and others on this list do.

--Jed  http://www.webstart.com/jed-signature.html