Re: Signs of adoption of CCG specifications

On 04/08/2025 22:33, Alan Karp wrote:
> (Adding cap-talk back into the discussion. My bad for dropping it.)
>
> --------------
> Alan Karp
>
>
> On Mon, Aug 4, 2025 at 12:23 PM David Chadwick 
> <d.w.chadwick@truetrust.co.uk> wrote:
>
>
>     On 04/08/2025 18:06, Alan Karp wrote:
>>     Is there a reason you didn't continue the discussion on cap-talk?
>>
>>     On Sun, Aug 3, 2025 at 2:14 PM David Chadwick
>>     <d.w.chadwick@truetrust.co.uk> wrote:
>>
>>>         Because you can invoke a method with one capability granted
>>>         to you and another capability delegated to you by whoever
>>>         invoked you.
>>
>>         You are missing the point. The requestor sends a bunch of VCs
>>         to the gatekeeper asking for access to resource X, who, in
>>         your case gets a capability back. The requestor then sends
>>         this capability to X to access the resource and gets the
>>         result back. In my case, the gatekeeper accesses resource X
>>         and returns the result back to the requestor. This is more
>>         efficient.
>>
>>         So there is no confused deputy in either case, or there is in
>>         both cases. There is no difference except in efficiency
>>
>>
>>     What if X is something that Alice has asked the requestor to access?
>
>     Alan, please access the bank and send me the money. Does this
>     sound like something you would do for me? I think not.
>
> That's almost exactly what happens when you present a check to Alan 
> the bank teller.

No its not, since a bank teller is the bank as far as the customer is 
concerned. We assume he has the money in his drawer under the counter. 
My example was asking You (not a bank teller) to go to the bank, draw 
some money out using your credentials, and then give the money to me. I 
am sure you would not do this. You would not be a confused deputy would you?

Using my example again with the bank teller, where the latter is the 
gatekeeper. The customer comes with his passport (a VC) and asks to draw 
money from his account.  Say that the money is held by a chief cashier, 
so the bank teller has to go to the chief cashier, request the money, 
and then return it to the customer. This is efficient from the 
customer's perspective. In your scenario, the bank teller returns a 
capability to the customer, who then goes to the chief cashier to ask to 
draw money from his account. This inefficiency would annoy most customers.

> The check is your authorization (capability) to collect the specified 
> amount of money from that account.  You can make it work with 
> ACLs, but you'd probably need to set up an account at my bank.
>
>>     The access decision is based on the requestor's credentials, not
>>     Alice's.  In many cases, you want the requestor to forward the
>>     result to Alice, e.g., a web server, but there are times when the
>>     decision should be based on Alice's credentials, not the
>>     requestor's.  While there are many checks you can do to prevent
>>     the error, it's a hazard that you must deal with.
>
>     There are lots of scenarios we can think of where users can do
>     dumb (or illegal) things, or programmers can program in errors by
>     mistake. You cannot avoid this. You are simply specifying one of them.
>
> I call them "hazards' because they're something your system needs to 
> deal with.  In my recent Stanford talk I walk through about 10 of them 
> and describe how you can handle them either with ACLs or with 
> capabilities..  In every case, the ACL approach can be made to work 
> but with much more complexity than with capabilities (or in one case 
> violating the law).  For example, you can implement delegation by 
> changing the ACL, but logs generally only show who made 
> the change, not who asked for it.  As a result, you don't know who has 
> permission to revoke access.
>
> You earlier stipulated a "no delegation" scenario, but I think 
> delegation is impossible to avoid.  We give permissions to people, but 
> they are not in the computer; the programs they run are.  That means 
> you are delegating every time you run a program.  In today's 
> non-mobile OSs, that takes the form of impersonation, a particularly 
> crude form of delegation.  Polaris did better than that without 
> capabilities at some cost in complexity.  Things are far easier if the 
> OS and applications are capability aware, as shown by CapDesk.
>
>>     --------------
>>     Alan Karp
>