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

On Fri, Sep 9, 2022 at 2:52 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Because we are not talking about names but credentials (as in Verifiable
> Credential). If you wish to replace credential with name in the ABAC system
> then I would also like to replace capability with name in your capability
> system
>

If the user designates the resource with a credential that includes
authorization, you have combined designation with authorization, and there
is no confused deputy.  If the user designates the resource with something,
such as a credential that does not include authorization, then you've
separated designation from authorization, and there is the potential for a
confused deputy.

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


On Fri, Sep 9, 2022 at 2:52 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 08/09/2022 23:12, Alan Karp wrote:
>
> 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.
>
> Because we are not talking about names but credentials (as in Verifiable
> Credential). If you wish to replace credential with name in the ABAC system
> then I would also like to replace capability with name in your capability
> system
>
> Kind regards
>
> David
>
>
> --------------
> 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
>>>
>>