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

On Thu, Sep 8, 2022 at 2:12 AM Steve Magennis <steve.e.magennis@gmail.com>
wrote:

> >> 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
>
>  I thought the confused deputy template implies that the invoker and
> deputy have the same permissions but those of the deputy exceed those of
> the invoker. In other words: the invoker is authorized to issue a check
> up to $X but the deputy has the ability to authorize a check for $X+ AND
> nothing is done to limit the deputy based on the limits of the invoker
>

As David said in his last note, his example is a poor one.  There is no
need for the invoker to have any permissions to the resource to have a
confused deputy.  The invoker only needs to be able to designate the
resource, e.g., specify the name of a file.

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


On Thu, Sep 8, 2022 at 2:12 AM Steve Magennis <steve.e.magennis@gmail.com>
wrote:

> >> 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
>
>  I thought the confused deputy template implies that the invoker and
> deputy have the same permissions but those of the deputy exceed those of
> the invoker. In other words: the invoker is authorized to issue a check
> up to $X but the deputy has the ability to authorize a check for $X+ AND
> nothing is done to limit the deputy based on the limits of the invoker
>
> On Thu, Sep 8, 2022, 12:10 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
>>
>