Re: Signs of adoption of CCG specifications

Our analogies, like all analogies, only make sense if they aren't stretched
too far.  I think we've gone past the point of no return.  I remain
convinced that capabilities simplify the handling of IAM hazards.  You are
not.  I suggest we leave it there.

--------------
Alan Karp


On Mon, Aug 4, 2025 at 3:11 PM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> 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
>>
>>