- From: Alan Karp <alanhkarp@gmail.com>
- Date: Sun, 6 Dec 2020 15:04:36 -0800
- To: Stephen Curran <swcurran@cloudcompass.ca>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANpA1Z1wPixA4mjgFDHgZEfahrnD5t1oCGy1xdMLy28NeUEJxA@mail.gmail.com>
Stephen Curran <swcurran@cloudcompass.ca> wrote: > > For OCAPS, is a simple assertion sufficient to convey the capability for a > functioning system, or does it matter to whom the capability was given? > > It does not matter to whom the capability was given. You can (and should) create a one-off key pair for every capability. You can include an identity for audit purposes, but it may not be meaningful to anyone else. For example, my company may include my employee id in the capability that I use for another company's service. The danger of including an identity in the capability is that it will be used as part of making the access decision, which can lead to a confused deputy vulnerability. There are also times when you don't know the identity of who is getting the capability. Perhaps it was given in exchange for money. > > I've always assumed that it is important that a capability being used is > done so by the party to whom the capability was given, or there is a chain > from a delegate to the initial receiving party. > > You can never know who used the capability, but you can know who to hold responsible for its use. The same applies to ACL systems. The reason is credential sharing. In an ACL system, the only way to delegate is to share your password. (As dangerous as it is, people do it if that's the only way they can get their jobs done.) In a certificate-based capability system, you can share capability and the private key needed to use it. That's why "do not delegate" as appears in SPKI is worse than useless. You gain no security, and you lose responsibility tracking. -------------- Alan Karp >
Received on Monday, 7 December 2020 16:37:42 UTC