- Hygiene for a computing pandemic From: fossandcrafts Type: Post Date: 2021-01-03 Tech: Object Capabilities
- Comparing VCs to ZCAP-LD By: Kyle Den Hartog Type: Post Date: 2021-09-25 Tech: Object Capabilities
- Re: VCs - zCaps / OCap a Discussion From: CCG Mailing List By: Dave Longley Type: Discussion Date: 2020-12-05 Tech: Object Capabilities
- Authorization Capabilities for Linked Data v0.3 From: CCG Type: Specification Date: 2023-01-22
- Awesome Object Capabilities and Capability-based Security By: Dan Connolly Type: List Date: 2023-03-03
- Object Capability Model From: Wikipedia Type: Entry Date: 2023-04-12
- Object Capabilities From: eRights By: Mark S. Miller Type: Page Date: 1998-10-03
This episode of FOSS and Crafts features Christopher Lemmer Webber discussing the object capability security approach. Its a generalization not specific to VCs, continuing from the conversation on the CCG mailinglist, Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps, we shared last month.
Why make the investment then to put the time and effort into ZCAPs when we’ve already got VCs? Simply put because security is hard and trying to push square pegs into round holes often times leads to bugs which are elevated to mission critical authentication/authorization bypass vulnerabilities. By designing around a fit for purpose data model with a well defined problem being solved it allows for us to be much more precise about where we believe extensibility is important versus where normative statements should be made to simplify the processing of the data models. By extension this leads to a simpler security model and likely a much more robust design with fewer vulnerabilities.
TL; DR: My current view is that the main confusion here may be over the difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a generalized container for attaching a cryptographic proof to a document. That’s what LD proofs (or JOSE style proofs) are for. VCs use LD proofs (or JOSE style proofs) to attach an assertion proof to a document that specifically models statements made by an issuer about some subject, which is therefore inherently about the identity of that subject
Authorization Capabilities for Linked Data (ZCAP-LD for short) provides a secure way for linked data systems to grant and express authority utilizing the object capability model. Capabilities are represented as linked data objects which are signed with Linked Data Proofs. ZCAP-LD supports delegating authority to other entities on the network by chaining together capability documents. “Caveats” may be attached to capability documents which may be used to restrict the scope of their use, for example to restrict the actions which may be used or providing a mechanism by which the capability may be later revoked.
[…] Relationship to Verifiable Credentials […]
We seem to be in a conundrum. Claims and credentials are forms of correlation that allow us to reason about an entity in our squishy human world, but are unsafe when used as mechanisms to authorize some event to occur within a system. Capabilities are a safe mechanism to model the flow of authority through a system, but there are times when capabilities have not been granted and we need to make a “judgement call” by correlating information about that entity. What should we do?
To pose the question is to see the answer: the right approach is to use each system for what it does best. Use correlation (Verifiable Credentials) in a reasoning system (most commonly human reasoning) as a path to make judgements about whether to hand an entity a specific set of initial capabilities. Use capabilities (ZCAP-LD) as the mechanism to grant and exercise authority through computing systems. To return to our system administrator example, when Alice applies for the job, she submits a series of credentials about her prior work history and degree, and Eva is able to verify that it is Alice’s former employers and university which have made these claims. Deciding that Alice is fit for the job, Eva hands Alice her initial capability which grants her authority to administrate the systems in question (with a caveat that allows Eva to revoke that authority at a future date, if appropriate). Alice uses that capability as the initial entry point into administrating the system.
Computer scientist E. Dean Tribble stated that in smart contracts, identity-based access control did not support well dynamically changing permissions, compared to the object-capability model. He analogized the ocap model with giving a valet the key to one’s car, without handing over the right to car ownership.
The structural properties of object capability systems favor modularity in code design and ensure reliable encapsulation in code implementation.
These structural properties facilitate the analysis of some security properties of an object-capability program or operating system. Some of these – in particular, information flow properties – can be analyzed at the level of object references and connectivity, independent of any knowledge or analysis of the code that determines the behavior of the objects. As a consequence, these security properties can be established and maintained in the presence of new objects that contain unknown and possibly malicious code.
The capability model is, in a sense, the object model taken to its logical extreme. Where object programmers seek modularity – a decrease in the dependencies between separately thought-out units – capability programmers seek security, recognizing that required trust is a form of dependency. Object programmers wish to guard against bugs: a bug in module A should not propagate to module B. Capability programmers wish to guard against malice. However, if B is designed to be invulnerable to A’s malice, it is likely also invulnerable to A’s bugs.
- DIDAuth + Obj. Cap. - IIW From: IDCommons Type: Session notes Date: 2018-10-31 Event: IIW
- Applying the Principle of Least Authority to User Interaction From: WebofTrustInfo By: Bill Tulloh Type: Paper Date: 2019-02-25 Event: rwot8-barcelona
- Introductory Capability DHT From: WebofTrustInfo By: James Foley Type: Paper Date: 2019-02-08 Event: rwot7-toronto
- Models of Identity From: WebofTrustInfo By: Joe Andrieu, Nathan George, Christophe Macintosh, Ouri Poupko, Antoine Rondelet, Andrew Hughes Type: Paper Date: 2020-05-17 Event: rwot7-toronto
- Cryptographic and Data Modeling Requirements from RWoT From: WebofTrustInfo By: Manu Sporny, Dave Longley, Christopher Lemmer Webber Type: Paper Date: 2018-08-23 Event: rwot7-toronto
- Recent happenings with Linked Data Capabilities From: WebofTrustInfo By: Christopher Lemmer Webber Type: Paper Date: 2018-03-02 Event: rwot6-santabarbera
- Smarm: Requirements for a smart-signatures Scheme From: WebofTrustInfo By: Christopher Lemmer Webber and Christopher Allen Type: Paper Date: 2017-10-05 Event: rwot5-boston
- Identity Hubs Capabilities Perspective From: WebofTrustInfo By: Adrian Gropper, Drummond Reed, Mark S. Miller Type: Paper Date: 2017-10-14 Event: rwot5-boston
- Linked Data Capabilities From: WebofTrustInfo By: Christopher Lemmer Webber, Mark S. Miller Type: Paper Date: 2022-11-28 Event: rwot5-boston
What is DIDAuth and how is it compatible with Object Capabilities?
We started by defining and describing object capabilities:
- A Capability is a Transferable Unforgeable Permission. It can be implemented with unguessable URLS or signed objects.
- A Java Program object reference is a capability, it allows for actions on the subject (the object instance).
- A stronger implementation of object capabilities involves a digital certificate issued by a public key, for a resource with a set of supported methods:
Object capabilities (ocaps) are increasingly recognized as an important tool for achieving the goals of self-sovereign identity. Many of the principles of self-sovereign identity, such as minimization and protection, can best be achieved through the disciplined pursuit of the principle of least authority that ocaps enable. This paper examines how POLA can be extended to better protect users when exercising their self-sovereign identity.
The Object Capability software design paradigm is a powerful philosophy for the programming of decentralized applications particularly in the realms of security and rights management.
Security • Liberty • Data • Relationship • Capability
Considering different models for handling identity information allows reconciliation, and creates opportunities to address primary use cases across paradigms, increasing overall strength and security of a solution.
In the Object Capabilities model, authorization is managed by creating, sharing, attenuating, and using “capabilities” instead of, for example, access control lists. If you have a valid “capability”, you have the authorization. Like a car key, Object Capabilities may be used no matter who you are. This model shifts the burden of identification from error-prone correlations to directly work with individuals’ actual capabilities.
This paper introduces the uninitiated to the requirements that have been identified over the years that are driving the community toward certain technological solutions.
Rebooting the Web of Trust is a community that is attempting to create a decentralized ecosystem that enables people to be in control of various aspects of their data and identity information. The group often talks about Decentralized Identifiers, Verifiable Credentials, Object Capabilities, ed25519 keys, cryptographic identifiers, and other technologies but rarely spends time documenting how we got here.
One of the outputs from Rebooting Web of Trust Fall 2017 was a writeup on Linked Data Capabilities based on discussions from the workshop (and particularly thanks to the guide of Mark S. Miller’s longstanding work on object capabilities). While the writeup speaks for itself, in short Linked Data Capabilities provide a way to encode object capability security to linked data systems. Much has happened since then.
After the workshop ideas from the paper were reified into specification form and the W3C Credentials Community Group has taken on the specification as an official work item of the group. Some changes have happened in the design of Linked Data Capabilities from the initial Rebooting Web of Trust paper
Smart signatures are desirable, but how to implement them? We need a language that is powerful and flexible enough to meet our needs while safe and bounded to run while remaining simple enough to feasibly implement.
Scheme is a turing-complete language with a (at least stated) fondness for minimalism. Unfortunately Scheme on its own is neither “safe” nor (necessarily) deterministic. Thankfully we can get the properties we want through:
- Making object capabilities a core part of the language. Specifically, Jonathan Rees’ “W7 security kernel” demonstrates that a pure lexically scoped environment is itself an appropritate substrate for object capabilities.
- Restricting space and time precisely in a way that is deterministic and reproducible.
- Removing sources of external side effects.
Identity Hubs as currently proposed in the Decentralized Identity Foundation (DIF) are a subset of a general Decentralized Identifier (DID) based user-controlled agent, based on ACLs rather than an object-capabilities (ocap) architecture. The current approach has both security and scalability issues. Transitioning the Hubs design to an ocap model can be achieved by introducing an UMA authorization server as the control endpoint. This avoids creating confused-deputy security issues and expands scale by enabling the hub to delegate access to resources not stored in the hub itself.
Linked Data Signatures enable a method of asserting the integrity of linked data documents that are passed throughout the web. The object capability model is a powerful system for ensuring the security of computing systems. In this paper, we explore layering an object capability model on top of Linked Data Signatures via chains of signed proclamations. fn:1 We call this system “Linked Data Capabilities”, or “ld-ocap” for short.