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

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.

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