This repository contains documents related to RWOT11, the eleventh Rebooting the Web of Trust design workshop, which will be held in the Hague, Netherlands, September, 2022
The goal of the workshop is to generate five technical white papers and/or proposals on topics decided by the group that would have the greatest impact on the future.
The Verifiable Credential (VC) ecosystem has encountered several use cases that require a third-party assertion, or a linked claim to an existing object (another VC, a PDF, a web page, etc). Whether it is product reviews, linked claims of self-created credentials, provenance of academic paper reviews, or some other general purpose third-party assertion, these use cases have several requirements in common. Each use case may also require a domain-specific set of fields.
We propose a minimal format for connecting (and optionally cryptographically binding) credentials that will allow each use of third-party assertions to be represented as a set of LinkedClaims. Such a data set will enable verifiers to evaluate the credibility of claims, including those sourced from outside the Verifiable Credential ecosystem.
Further, we propose to demonstrate the ability to compose several Verifiable Credentials into a single domain-specific credential using the LinkedClaim vocabulary that will satisfy the domain requirements of the likely users.
This approach will enable rich shared datasets to inform trust decisions while satisfying the requirements of domain-specific end users. One of the intentions of LinkedClaims Verifiable Credentials is to give individuals the agency to make such claims about themselves and others on their own terms.
by Paul Bastian, Rieks Joosten, Zaïda Rivai, Oliver Terbu, Snorre Lothar von Gohren Edwin, Antonio Antonino, Nikos Fotiou, Stephen Curran, and Ahamed Azeem
The W3C Verifiable Credentials Data Model(VCDM) specifies Verifiable Credentials (VCs)[^1] as a collection of claims that are issued by a single party, and Verifiable Presentations (VPs) as a collection of claims that a holder can construct from different VCs issued by different parties. Over the last year(s), various issues have been raised that revolve around what has been called 'holder binding'. The term 'holder binding' itself isn't clearly defined, and is in fact quite contentious. This paper seeks to come to grips with this discussion. Our first contribution is the specification of a terminology, which is intended to help readers understand what we mean to say without requiring them to make assumptions about such meanings (as is often the case in discussions about 'holder binding'). Our second contribution is an analysis of a (fictitious) use-case that suggests that verifiers typically do not need to know who the holder is (i.e. who has presented the claims to be verified). This analysis shows that verifiers need capabilities to (a) learn which entity is the subject of a particular claim, and (b) to know whether or not two subject identifiers refer to the same entity or to different entities. Also, they may need assurances regarding the party on whose behalf the component that has electronically presented the claims, has been using those capabilities. Our third contribution is a proposal for the syntax and semantics of a new property that can be used in (different parts of) VCs/VPs, that will provide verifiers with such capabilities.
by Lal Chandran, Lotta Lundin, Fredrik Lindén, Philippe Page, Paul Knowles, Víctor Martínez Jurado, Andrew Slack
On the need to link verifiable credentials with the right to use data in a secure, inclusive user interaction.
In this collaborative work from RWOT11, we revisit the issue of patient data exchange in a setting requiring cross-border, multi jurisdiction, and inclusive access to all participants. A fundamental problem in developing large-scale real-world solutions based on verifiable credentials is keeping the simplicity of usage for individuals in different contexts without sacrificing security.
We aim to highlight selected technical challenges and outline how the DEXA and OCA protocols contribute to scalable solutions.
Decentralized identity solutions, such as DID methods, tend to be designed to protect against certain attacks, but the purpose of that design usually is not explicitly stated in any architectural description or threat documentation. In particular, some DID methods have costly on-chain requirements that must have had a reasoning behind their requirement. We can today see that these DID methods were purposefully shaped, but it’s not clear why such decisions were made. The purpose of this paper is to describe a few colorful attacks on DID methods so that we can better understand what threats a system might be vulnerable to.
Although we derived the examples in this paper by examining current DID methods, we believe these attack vectors are more general, even for systems not using DIDs. The goal is to support engineers and developers who are developing decentralized identity solutions to safeguard their work and make it secure and compliant.
by Manu Sporny, Oskar van Deventer, Isaac Henderson Johnson Jeyakumar, Shigeya Suzuki, Konstantin Tsabolov, Line Kofoed, Rieks Joostena
Enabling anyone to share information about the Issuers and Verifiers for whom they assure trust
This work focuses on how a party or its agent can decide whether or not to engage with a counterparty in a transaction. The purpose of this work is to enable the sharing of a list of Verifiable Issuers and Verifiers in a way that is useful to a particular transaction. A set of use cases provide examples where verification of an Issuer ("Is that diploma from a recognized university?") or Verifier ("Should the wallet block an unauthorized Verifier?") is needed. The studied prior art highlights various solutions to verify Issuers and Verifiers and identifies a lack of standards. Important contributions from this paper include a unified set of requirements, a data model, and multiple serializations of the data model --- including but not limited to Verifiable Credentials, DNSSEC, and blockchain-based serializations --- that could then be incubated and sent onto the standards track at global standards setting organizations.
In advance of the design workshop, all participants are invited to contribute a one-or-two page topic paper to be shared with the other attendees on either:
- A specific problem that they wanted to solve with a web-of-trust solution, and why current solutions (PGP or CA-based PKI) can't address the problem?
- A specific solution related to the web-of-trust that you'd like others to use or contribute to?
Please see the Advance Readings directory for all the current papers (and how to upload yours). Advance readings from RWOT10 (cancelled due to COVID) are also included.
A different repository is available for each of the Rebooting the Web of Trust design workshops:
- Rebooting the Web of Trust XI: Netherlands (September 2022)
- Rebooting the Web of Trust X: Buenos Aires (March 2020)
- Rebooting the Web of Trust IX: Prague (September 2019)
- Rebooting the Web of Trust VIII: Barcelona (March 2019)
- Rebooting the Web of Trust VII: Toronto (September 2018)
- Rebooting the Web of Trust VI: Santa Barbara (March 2018)
- Rebooting the Web of Trust V: Boston (October 2017)
- Rebooting the Web of Trust IV: Paris (April 2017)
- Rebooting the Web of Trust III: San Francisco (October 2016)
- Rebooting the Web of Trust II: ID2020 (May 2016)
- Rebooting the Web of Trust I: San Francisco (November 2015)
All of the contents of this directory are licensed Creative Commons CC-BY their contributors.