Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

On Thu, Sep 8, 2022 at 11:30 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Not quite.  You used the word "credential," which implies that it is more
> than simply the designation of the resource to be acted on.
>
> This is surely the flaw in your argument (which you appear to admit in the
> last line of your answer below). To paraphrase it, you are saying, with
> capabilities the deputy wont give the user access to the resource because
> it will only use the user's capabilities, but with credentials, the deputy
> will give the user access to the resource because it will use its own
> credentials.
>
> An intelligent deputy will in both cases only use the privileges of the
> user. A confused deputy will in both cases use its own privileges
> regardless of those of the user.
>
> Thus I conclude that the whole confused deputy argument for why
> capabilities are better than credentials is a spurious one.
>
Please read the first sentence above.  You keep saying "credential," which
I take to be something that carries a permission.  Replace that word with
"name," a word that does not imply any permissions, and tell me why the
argument is spurious.

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


On Thu, Sep 8, 2022 at 11:30 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 08/09/2022 17:30, Alan Karp wrote:
>
> On Thu, Sep 8, 2022 at 12:06 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
> On 07/09/2022 23:34, Alan Karp wrote:
>>
>> On Wed, Sep 7, 2022 at 11:08 AM David Chadwick <
>> d.w.chadwick@truetrust.co.uk> wrote:
>>
>>> As I understand confused deputy, the deputy is not only using the
>>> credential passed to it, but also its own credentials as well, to do
>>> whatever was requested of it.
>>>
>> The essence of the confused deputy is that the invoker designates the
>> thing to work on while the deputy uses its own permission for the access.
>>
>> So is this not a restatement of what I originally said?
>>
> Not quite.  You used the word "credential," which implies that it is more
> than simply the designation of the resource to be acted on.
>
>>   In the canonical example, the deputy gets invoked with a string
>> designating a file to write.  The deputy then opens the file, which results
>> in an open file handle with write permission if the deputy has that
>> permission even if the invoker does not.
>>
>> So why could this not happen with capabilities? It seems to me as if the
>> deputy is using its own capability to open the file, regardless of whether
>> the invoker has that privilege or not.
>>
> That is possible, but it is an avoidable error.  The deputy should use the
> capability provided by the invoker.  The error is not avoidable without
> capabilities; the deputy has no choice but to use its own permissions.
>
> This is surely the flaw in your argument (which you appear to admit in the
> last line of your answer below). To paraphrase it, you are saying, with
> capabilities the deputy wont give the user access to the resource because
> it will only use the user's capabilities, but with credentials, the deputy
> will give the user access to the resource because it will use its own
> credentials.
>
> An intelligent deputy will in both cases only use the privileges of the
> user. A confused deputy will in both cases use its own privileges
> regardless of those of the user.
>
> Thus I conclude that the whole confused deputy argument for why
> capabilities are better than credentials is a spurious one.
>
> Kind regards
>
> David
>
>
>>
> That's what comes from separating designation from authorization.  Note
>> that this attack would fail if the invoker had to provide an open file
>> handle, which does combine designation and authorization.
>>
>>  Yes we agree on this.
>>
>> So this situation could also happen with capabilities if the recipient
>>> uses its own capabilities as well as those passed to it, e.g. the deputy is
>>> asked to fill and sign a check. The deputy has the capability to fill the
>>> check, and is passed the signing capability.
>>>
>> That's not a confused deputy.
>>
>> Its a bad example, I agree. So lets just consider the write to a file
>> example. Are you saying that neither party can write to a file without the
>> help of the other one or are you are saying that the deputy has all the
>> permissions to write to a file regardless of which permission the invoker
>> has. In the latter case the check example would be changed to: the deputy
>> has capabilities to fill and sign a check and the invoker only has one of
>> them, but asks the deputy to do both.
>>
>  Yes.   Any time the invoker designates something, and the invoked uses
> its own permissions you have the potential for a confused deputy.
>
> --------------
> Alan Karp
>
>
> On Thu, Sep 8, 2022 at 12:06 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>>
>> On 07/09/2022 23:34, Alan Karp wrote:
>>
>> On Wed, Sep 7, 2022 at 11:08 AM David Chadwick <
>> d.w.chadwick@truetrust.co.uk> wrote:
>>
>>> As I understand confused deputy, the deputy is not only using the
>>> credential passed to it, but also its own credentials as well, to do
>>> whatever was requested of it.
>>>
>> The essence of the confused deputy is that the invoker designates the
>> thing to work on while the deputy uses its own permission for the access.
>>
>> So is this not a restatement of what I originally said?
>>
>>
>>   In the canonical example, the deputy gets invoked with a string
>> designating a file to write.  The deputy then opens the file, which results
>> in an open file handle with write permission if the deputy has that
>> permission even if the invoker does not.
>>
>> So why could this not happen with capabilities? It seems to me as if the
>> deputy is using its own capability to open the file, regardless of whether
>> the invoker has that privilege or not.
>>
>>
>> That's what comes from separating designation from authorization.  Note
>> that this attack would fail if the invoker had to provide an open file
>> handle, which does combine designation and authorization.
>>
>>  Yes we agree on this.
>>
>> So this situation could also happen with capabilities if the recipient
>>> uses its own capabilities as well as those passed to it, e.g. the deputy is
>>> asked to fill and sign a check. The deputy has the capability to fill the
>>> check, and is passed the signing capability.
>>>
>> That's not a confused deputy.
>>
>> Its a bad example, I agree. So lets just consider the write to a file
>> example. Are you saying that neither party can write to a file without the
>> help of the other one or are you are saying that the deputy has all the
>> permissions to write to a file regardless of which permission the invoker
>> has. In the latter case the check example would be changed to: the deputy
>> has capabilities to fill and sign a check and the invoker only has one of
>> them, but asks the deputy to do both.
>>
>> Kind regards
>>
>> David
>>
>