├── .gitignore ├── event-documents ├── blank.md ├── README.md └── plenaries │ ├── 1-intro.md │ ├── 8-finalnotes.md │ ├── 6-aboutusandforward.md │ ├── 3-topicvoting.md │ ├── 4-dayoneend-planneddeliverables.md │ ├── 7-projectupdate.md │ ├── 5-daytwoend-topics.md │ └── 2-lightning.md ├── final-documents ├── hubs.pdf ├── hubs.docx ├── reputation-toolkit.docx ├── reputation-toolkit.pdf ├── joram-engagement-model.pdf ├── smart-consent-protocol.pdf ├── did-implementer-draft-10.pdf ├── joram-engagement-model.docx ├── smart-consent-protocol.docx ├── ~$ram-engagement-model.docx ├── did-implementer-draft-10.docx ├── digital-verification-advancements.docx ├── digital-verification-advancements.pdf ├── WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf ├── WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.docx └── README.md ├── supporting-files ├── graphs-1.jpg ├── graphs-2.jpg ├── graphs-3.jpg ├── graphs-4.jpg ├── rtk │ ├── image_0.png │ ├── image_1.png │ ├── image_2.png │ ├── image_3.png │ └── readme.md └── README.md ├── topics-and-advance-readings ├── HDKeys-Ed25519.pdf ├── Slepaks-Triangle.pdf ├── opentimestamps-merkle-tree.png ├── Creating-a-Humanized-Internet.pdf ├── physician-patient-relationship.pdf ├── DIDsandPersonalDataStorageforChildren.pdf ├── Sovrin--digital-identities-in-the-blockchain-era.pdf ├── a-technology-free-definition-of-self-sovereign-identity.pdf ├── Distributed-Identity,-Distributed-Self ├── DistributedIdentityDistributedSelf.md ├── README.md ├── rgrant-user-interface-standards-rwot-fall2016.md ├── portable-reputation-toolkit.md ├── attestation-taxonomies.md ├── EU-General-Data-Protection-Regulation-Self-Sovereign-Identifiers.md ├── EU-General-Data-Protection-Regulation-&-Self-Sovereign-Identifier(s) ├── alternative-futures-framework.md ├── user-controlled-key-recovery.md ├── identity-as-linked-data-on-immutable-ledgers.md ├── identity-forking-and-federated-reputation.md ├── Proof-of-stake-without-native-coin.md ├── JXD-Examples.md ├── Sovereign-Identity-Model-for-Digital-Ecologies.md ├── fit-for-purpose-blockchains.md ├── privacy-preserving-identity-architectures.md ├── anonymous-credentials-in-sovrin.md └── blockchain-extensions-for-linked-data-signatures.md ├── draft-documents ├── DID-Spec-Implementers-Draft-01.pdf ├── DIDSpecificationWorkingDraft04.pdf ├── portable-reputation │ ├── README.md │ └── src │ │ ├── README.md │ │ └── claim │ │ └── README.md ├── final-documentsdid-context-v1-draft-01.txt ├── README.md ├── rwot3-digital-verification-outcomes.md ├── reputation-toolkit.md ├── hubs.md └── WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /event-documents/blank.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /final-documents/hubs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/hubs.pdf -------------------------------------------------------------------------------- /final-documents/hubs.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/hubs.docx -------------------------------------------------------------------------------- /supporting-files/graphs-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/graphs-1.jpg -------------------------------------------------------------------------------- /supporting-files/graphs-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/graphs-2.jpg -------------------------------------------------------------------------------- /supporting-files/graphs-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/graphs-3.jpg -------------------------------------------------------------------------------- /supporting-files/graphs-4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/graphs-4.jpg -------------------------------------------------------------------------------- /supporting-files/rtk/image_0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/rtk/image_0.png -------------------------------------------------------------------------------- /supporting-files/rtk/image_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/rtk/image_1.png -------------------------------------------------------------------------------- /supporting-files/rtk/image_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/rtk/image_2.png -------------------------------------------------------------------------------- /supporting-files/rtk/image_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/supporting-files/rtk/image_3.png -------------------------------------------------------------------------------- /final-documents/reputation-toolkit.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/reputation-toolkit.docx -------------------------------------------------------------------------------- /final-documents/reputation-toolkit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/reputation-toolkit.pdf -------------------------------------------------------------------------------- /final-documents/joram-engagement-model.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/joram-engagement-model.pdf -------------------------------------------------------------------------------- /final-documents/smart-consent-protocol.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/smart-consent-protocol.pdf -------------------------------------------------------------------------------- /final-documents/did-implementer-draft-10.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/did-implementer-draft-10.pdf -------------------------------------------------------------------------------- /final-documents/joram-engagement-model.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/joram-engagement-model.docx -------------------------------------------------------------------------------- /final-documents/smart-consent-protocol.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/smart-consent-protocol.docx -------------------------------------------------------------------------------- /final-documents/~$ram-engagement-model.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/~$ram-engagement-model.docx -------------------------------------------------------------------------------- /final-documents/did-implementer-draft-10.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/did-implementer-draft-10.docx -------------------------------------------------------------------------------- /topics-and-advance-readings/HDKeys-Ed25519.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/HDKeys-Ed25519.pdf -------------------------------------------------------------------------------- /topics-and-advance-readings/Slepaks-Triangle.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/Slepaks-Triangle.pdf -------------------------------------------------------------------------------- /draft-documents/DID-Spec-Implementers-Draft-01.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/draft-documents/DID-Spec-Implementers-Draft-01.pdf -------------------------------------------------------------------------------- /draft-documents/DIDSpecificationWorkingDraft04.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/draft-documents/DIDSpecificationWorkingDraft04.pdf -------------------------------------------------------------------------------- /final-documents/digital-verification-advancements.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/digital-verification-advancements.docx -------------------------------------------------------------------------------- /final-documents/digital-verification-advancements.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/digital-verification-advancements.pdf -------------------------------------------------------------------------------- /topics-and-advance-readings/opentimestamps-merkle-tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/opentimestamps-merkle-tree.png -------------------------------------------------------------------------------- /topics-and-advance-readings/Creating-a-Humanized-Internet.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/Creating-a-Humanized-Internet.pdf -------------------------------------------------------------------------------- /topics-and-advance-readings/physician-patient-relationship.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/physician-patient-relationship.pdf -------------------------------------------------------------------------------- /draft-documents/portable-reputation/README.md: -------------------------------------------------------------------------------- 1 | # Portable Reputation Toolkit 2 | 3 | This project has moved to its own repository: https://github.com/WebOfTrustInfo/portable-reputation-toolkit 4 | -------------------------------------------------------------------------------- /topics-and-advance-readings/DIDsandPersonalDataStorageforChildren.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/DIDsandPersonalDataStorageforChildren.pdf -------------------------------------------------------------------------------- /draft-documents/portable-reputation/src/README.md: -------------------------------------------------------------------------------- 1 | # Portable Reputation Toolkit 2 | 3 | This project has moved to its own repository: https://github.com/WebOfTrustInfo/portable-reputation-toolkit 4 | -------------------------------------------------------------------------------- /final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf -------------------------------------------------------------------------------- /draft-documents/portable-reputation/src/claim/README.md: -------------------------------------------------------------------------------- 1 | # Portable Reputation Toolkit 2 | 3 | This project has moved to its own repository: https://github.com/WebOfTrustInfo/portable-reputation-toolkit 4 | -------------------------------------------------------------------------------- /final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.docx -------------------------------------------------------------------------------- /supporting-files/rtk/readme.md: -------------------------------------------------------------------------------- 1 | # Reputation Toolkit Images 2 | 3 | These are images for the reputation toolkit paper. 4 | 5 | 6 | ![](image_0.png) 7 | ![](image_1.png) 8 | ![](image_2.png) 9 | ![](image_3.png) -------------------------------------------------------------------------------- /topics-and-advance-readings/Sovrin--digital-identities-in-the-blockchain-era.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/Sovrin--digital-identities-in-the-blockchain-era.pdf -------------------------------------------------------------------------------- /topics-and-advance-readings/a-technology-free-definition-of-self-sovereign-identity.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WebOfTrustInfo/rwot3-sf/HEAD/topics-and-advance-readings/a-technology-free-definition-of-self-sovereign-identity.pdf -------------------------------------------------------------------------------- /supporting-files/README.md: -------------------------------------------------------------------------------- 1 | # Supporting Files 2 | 3 | 4 | ![](graphs-1.jpg) 5 | ![](graphs-2.jpg) 6 | ![](graphs-3.jpg) 7 | ![](graphs-4.jpg) 8 | 9 | ## Reputation Toolkit Images 10 | 11 | These are images for the reputation toolkit paper. 12 | 13 | 14 | ![](rtk/image_0.png) 15 | ![](rtk/image_1.png) 16 | ![](rtk/image_2.png) 17 | ![](rtk/image_3.png) -------------------------------------------------------------------------------- /event-documents/README.md: -------------------------------------------------------------------------------- 1 | # RWOT3-SF Event Documents 2 | 3 | ## Plenaries 4 | 5 | 1. [Intro](plenaries/1-intro.md) 6 | 2. [Lightning](plenaries/2-lightning.md) 7 | 3. [Topic Voting](plenaries/3-topicvoting.md) 8 | 4. [Day One End - Planned Deliverables](plenaries/4-dayoneend-planneddeliverables.md) 9 | 5. [Day Two End - Topics](plenaries/5-daytwoend-topics.md) 10 | 6. [About Us and Forward](plenaries/6-aboutusandforward.md) 11 | 7. [Project Update](plenaries/7-projectupdate.md) 12 | 8. [Final Notes](plenaries/8-finalnotes.md) 13 | -------------------------------------------------------------------------------- /event-documents/plenaries/1-intro.md: -------------------------------------------------------------------------------- 1 | 2 | Welcome to Rebooting the Web of Trust (III): Fall 2016 3 | 4 | ## Origins 5 | 6 | Where did RWoT come from? 7 | Felt like peer-to-peer identity systems had never met promise of '90s 8 | And worse, some systems were being REcentralized 9 | 10 | But we were also tired of talking 11 | Wanted to get these ideas down into paper and ship them 12 | 13 | ## Mission 14 | 15 | The core mission is SHIP IT! 16 | Shipping it is more important than process! 17 | 18 | We want to make a difference in our communities & influence them. 19 | 20 | ## Agreements & Ground Rules 21 | 22 | On the site! 23 | 24 | 1. Treat people respectfully 25 | 2. Be civilized 26 | 3. Get permission to quote with attribution 27 | 4. We're here for ourselves, not companies 28 | 5. What we publish is in the commons 29 | 30 | -------------------------------------------------------------------------------- /draft-documents/final-documentsdid-context-v1-draft-01.txt: -------------------------------------------------------------------------------- 1 | { 2 | "@context": ["https://w3id.org/identity/v1", { 3 | "ctrl": "https://w3id.org/control#", 4 | "ddo": "https://w3id.org/ddo#", 5 | "control": { 6 | "@id": "ddo:control", 7 | "@type": "@id" 8 | }, 9 | "curve": "sec:curve", 10 | "guardian": "ddo:guardian", 11 | "minimumSignatures": { 12 | "@id": "ctrl:minimumSignatures", 13 | "@type": "xsd:integer" 14 | }, 15 | "openid": "ddo:openid", 16 | "publicKeyBase64": "sec:publicKeyBase64", 17 | "service": "ddo:service", 18 | "signer": "sec:signer", 19 | "updated": { 20 | "@id": "ddo:updated", 21 | "@type": "xsd:dateTime" 22 | }, 23 | "xdi": "ddo:xdi", 24 | "EdDsaPublicKey": "sec:EdDsaPublicKey", 25 | "RsaPublicKey": "sec:RsaPublicKey", 26 | "OrControl": "ctrl:OrControl", 27 | "AndControl": "ctrl:AndControl", 28 | "MofNControl": "ctrl:MofNControl" 29 | }] 30 | } 31 | -------------------------------------------------------------------------------- /event-documents/plenaries/8-finalnotes.md: -------------------------------------------------------------------------------- 1 | *Commitments* 2 | * Christopher A. has committed to working on a next Web of Trust, maybe in Paris, and possibility of another next year. 3 | * We'll be looking into creating a Kantera workgroup at IIW (Joe, Christopher, Drummond) 4 | * We'll also host a session on self-sovereign identity at IIW (Joe) 5 | * We'll have DID working draft for IIW (Drummond) 6 | * Drummond will be working on Trust Framework for Sovereign Foundation 7 | * Uport Team will be implementing Verifiable Claims and DID Specification in UPort 8 | 9 | There was some discussion of single-person papers that came out of these conferences, and we're proposing that we include them in our final papers if they get some casual peer review. 10 | 11 | Similarly, we have some great topic papers, and we'd like to bring those to better attention, so we ask people to highlight other peoples' papers if they're great. 12 | -------------------------------------------------------------------------------- /event-documents/plenaries/6-aboutusandforward.md: -------------------------------------------------------------------------------- 1 | 6-Day3morning-metaconversations 2 | 3 | _A short poll suggested some answers about who we are._ 4 | 5 | *WHO ARE WE?* 6 | * Primarily from US, but 25 others 7 | * Primarily software developers, but 31% others 8 | * A quarter of us are entirely developed to identity 9 | * We want to Collaborate, Do the Work, and Ship It! 10 | 11 | *WHAT DO WE BELIEVE?* 12 | * We believe these technologies will have a huge impact on the world 13 | * We believe that we'll succeed in interesting ways, but with compromises 14 | * We are very satisfied with our participation in Web of Trust! 15 | 16 | *MOVING FORWARD* 17 | * We need to better daylight papers 18 | * We need to work with standards 19 | * Equal interest in every 6 or 12 months 20 | * We're interested in a more GLOBAL community, but it's expensive(!) 21 | * We want to communicate with Slack and Email 22 | 23 | *TACTICS* 24 | 25 | Some discussion on how to finalize papers. 26 | 27 | But how do we publicize them better? 28 | 29 | *IP* 30 | 31 | Some question about patent rights and code IP, since our creative commons licenses have been focused on paper. 32 | 33 | *FRANCE* 34 | 35 | There was some discussion of getting space in France due to interest there 36 | -------------------------------------------------------------------------------- /event-documents/plenaries/3-topicvoting.md: -------------------------------------------------------------------------------- 1 | These were the most popular topics based on 5-round voting 2 | 3 | *Selected Topics:* 4 | 5 | 24: What Technology should we use to digitally sign verifiable claims 6 | * 23: Data Models for Verifiable Claims 7 | * 22: Issues of Attestation and Revocation on Blockchains 8 | * 19: API / Protocol Standard for Comms Re-Identity 9 | 10 | 24: User adoption & bootstrapping digital identity 11 | 12 | 23: Chainpoint Proof Protocol 13 | * 22: Time Stamps 14 | 15 | 23: Portable Reputation Software Toolkit 16 | 17 | 23: Privacy on a Blockchain with Anonymous Credentials and Anoynmous Revocations 18 | 19 | 22: How We Ensure/Enable a Context for Humanness on Blockchain 20 | * 21: Create an Identity Process that Improves Adaptive Ability of People and Communities 21 | * 20: Day in the Life Description of Sovereign Identity, 10 Years Out 22 | * 19: Draft Identity Engagement Module for Self-Sovereign Identity for UN 16.9 23 | 24 | 21.5: DID Spec 25 | * 19: Identity Container Spec v0 (day two?) 26 | 27 | *Table 9:* 28 | 29 | 22: Self-Sovereign Identity Principles 2.0 + Pledge [later?] 30 | * 19: Pledge or Manifesto for Self-sovereign identity 31 | 32 | 23: A Rough Outline of Standard Protocol for Blockchains 33 | 34 | 20: Work on Identity Graphs 35 | 36 | 19: Formal Verification for Trusted Data Types 37 | 38 | -------------------------------------------------------------------------------- /draft-documents/README.md: -------------------------------------------------------------------------------- 1 | Here are the completed papers from RWOT3: 2 | 3 | | **Paper** | **Lead** | **Status** | **Link** | 4 | |-----------|----------|------------|----------| 5 | | DID Spec v4 | Drummond R. | Published | [Implementers Draft](../final-documents/did-implementer-draft-10.pdf) | 6 | | Digital Verification Advancements at RWoT3 | Manu S. | Published | [Final](../final-documents/digital-verification-advancements.pdf) | 7 | | Humanness in Digital Identity | Kaliya Y. | Published | [Final](../final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf) | 8 | | Portable Reputation Kit | Noah T. | Published | [Final](../final-documents/reputation-toolkit.pdf) / [Code](portable-reputation) | 9 | | Smart Consent Protocol | Shaun C. | Published | [Final](../final-documents/smart-consent-protocol.pdf) | 10 | 11 | These other papers may still appear in the future, but aren't currentlypart of the RWOT3 bundle: 12 | 13 | | **Paper** | **Lead** | **Status** | **Link** | 14 | |-----------|----------|------------|----------| 15 | | Privacy on Distributed Ledgers | Jason L. | Last Call | | 16 | | Refugee Engagement Model | Joe A. | Last Call | | 17 | | Bootstrapping & User Adoption | Lohan S., Thessy M., Matt D. | Last Call | | 18 | | Identity Containers | Daniel B. | Last Call | | 19 | | "Shadows" | Kaliya Y. | | | 20 | | Identity Graphs | Markus S. | | | 21 | | Chainpoint Update Synopsis | Wayne V. | | | 22 | | Slepak's Triangle | Greg S. | | | 23 | -------------------------------------------------------------------------------- /event-documents/plenaries/4-dayoneend-planneddeliverables.md: -------------------------------------------------------------------------------- 1 | *DID Spec + Identity Containers.* (Drummond, Daniel) 2 | * Take DID Spec to version 4. (End of Thursday?) 3 | * Create sequence to get DID running as user. 4 | * Future: Define a method on Bitcoin? 5 | * Review identity containers to allow feedback. 6 | 7 | *Identity & Use Cases.* (Kaliyah, Joe) 8 | * Write strong outline on What's broken and not working in today's society & how we can avoid them in digital system? (End of Thursday) 9 | * Write identity engagement model, about given refugee through experiences (End of Thursday) 10 | * Maybe Write Day in the Life afterward (Friday or Elsewhere?) 11 | 12 | *Privacy with Identities in Blockchains & Selective Disclosures.* (Dmitry, Greg) 13 | * Write white paper on use cases that illustrate risks to privacy with distributed ledger, techniques to solve (Thursday+) 14 | 15 | *Proofs Format, Timestamps.* (Peter, Wayne) 16 | * Talking about similarities & differences, no promises on deliverables 17 | 18 | *Bootstrapping Identity and User Adoption* (Thessy) 19 | * Write a paper on user experience (Thursday, maybe Friday) 20 | 21 | *Portable Reputation Toolkit* (Noah) 22 | * Create UX mockups, brief description, use cases, prototypes (Friday) 23 | 24 | *Verifiable Claims* (Manu) 25 | * Where does privacy fall down? 26 | * Not including questions of signatures. 27 | * Do a privacy analysis & fold it into work 28 | -------------------------------------------------------------------------------- /topics-and-advance-readings/Distributed-Identity,-Distributed-Self: -------------------------------------------------------------------------------- 1 | Distributed Identity, Distributed Self 2 | 3 | Topic Paper for Web of Trust Working Group 4 | October 2016 5 | 6 | Proposed by Natalie Smolenski, Anthropologist 7 | 8 | 9 | Recent research in neuroscience has suggested that the human “self” has many neural correlates distributed across different 10 | processing centers of the brain. Accordingly, there is no area of the brain in which “self,” as a depth experience or as a 11 | category or object of experience, is centralized or can be said to “reside.” Rather, relationships between nodes in the neural 12 | network are activated differently on the basis of which “mode” of self is being operationalized: whether it is the explicit 13 | recognition of one’s image in a mirror, the ascription of adjectives to oneself, or the prereflective stream-of-consciousness 14 | self-experience characteristic of activity that does not depend on self-objectification. 15 | 16 | These scientific observations lead to three major questions proposed for consideration by the Web-of-Trust Working Group: 17 | 18 | 1. How can a distributed, network-based understanding of identity contribute to innovations in a decentralized web-of-trust? 19 | 20 | 2. Identity is operationalized tactically in different ways based on what the identity-bearing individual is doing, whether that 21 | is self-recognition, self-description, employing identity as a tool to achieve specific aims, or simply prereflectively “being a 22 | self.” Each modality of identity triggers network pathways differently. Could a Web-of-Trust facilitate the creation of multiple 23 | identity inflections on the basis of user intentions? 24 | 25 | 3. Unlike the human brain, the internet and blockchain are network infrastructures shared by countless users. How could 26 | these “shared minds” facilitate forms of individual network identity? 27 | -------------------------------------------------------------------------------- /topics-and-advance-readings/DistributedIdentityDistributedSelf.md: -------------------------------------------------------------------------------- 1 | # Distributed Identity, Distributed Self 2 | 3 | Topic Paper for Web of Trust Working Group 4 | October 2016 5 | 6 | Proposed by Natalie Smolenski, Anthropologist 7 | 8 | 9 | Recent research in neuroscience has suggested that the human “self” has many neural correlates distributed across different 10 | processing centers of the brain. Accordingly, there is no area of the brain in which “self,” as a depth experience or as a 11 | category or object of experience, is centralized or can be said to “reside.” Rather, relationships between nodes in the neural 12 | network are activated differently on the basis of which “mode” of self is being operationalized: whether it is the explicit 13 | recognition of one’s image in a mirror, the ascription of adjectives to oneself, or the prereflective stream-of-consciousness 14 | self-experience characteristic of activity that does not depend on self-objectification. 15 | 16 | These scientific observations lead to three major questions proposed for consideration by the Web-of-Trust Working Group: 17 | 18 | 1. How can a distributed, network-based understanding of identity contribute to innovations in a decentralized web-of-trust? 19 | 20 | 2. Identity is operationalized tactically in different ways based on what the identity-bearing individual is doing, whether that 21 | is self-recognition, self-description, employing identity as a tool to achieve specific aims, or simply prereflectively “being a 22 | self.” Each modality of identity triggers network pathways differently. Could a Web-of-Trust facilitate the creation of multiple 23 | identity inflections on the basis of user intentions? 24 | 25 | 3. Unlike the human brain, the internet and blockchain are network infrastructures shared by countless users. How could 26 | these “shared minds” facilitate forms of individual network identity? 27 | -------------------------------------------------------------------------------- /final-documents/README.md: -------------------------------------------------------------------------------- 1 | # Rebooting the Web of Trust III (Fall 2016) Final Papers 2 | 3 | ## [*DID (Decentralized Identifier) Data Model and Generic Syntax 1.0 Implementer’s Draft 01*](did-implementer-draft-10.pdf) 4 | #### by Drummond Reed, Les Chasen, Christopher Allen, and Ryan Grant 5 | 6 | > The complete draft of the Decentralized IDentifier (DID) model and syntac, a project that has run through the RWOT workshops to date. 7 | 8 | ## [*Digital Verification Advancements at RWoT III*](digital-verification-advancements.pdf) 9 | #### by Manu Sporny with Christopher Allen, Harlan Wood, and Jason Law 10 | 11 | > A short overview of enhancements to Digital Verification that came out of RWOT III. 12 | 13 | ## [*Embedding Human Wisdom in Our Digital Tomorrow*](WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf) 14 | #### by Daniel Hardman, Kaliya “Identity Woman” Young, and Matthew Schutte 15 | 16 | > A discussion of the dangers of transferring wisdom into the digital world, seen through the lenses of vulnerability, shadows, healing, tensions, complexity and gestalt, and organizational choices. 17 | 18 | ## [*Hubs*](hubs.pdf) 19 | #### by Daniel Buchner, Wayne Vaughan, and Ryan Shea 20 | 21 | > An overview of the hubs datastore system. 22 | 23 | ## [*Joram 1.0.0*](joram-engagement-model.pdf) 24 | #### by Joe Andrieu and Bob Clint 25 | 26 | > An Information Lifecycle Engagement Model that offers a use case for a Syrian refugee. 27 | 28 | ## [*Portable Reputation Toolkit Use Cases*](reputation-toolkit.pdf) 29 | #### by Christopher Allen, Tim Daubenschütz, Manu Sporny, Noah Thorp, Harlan Wood, Glenn Willen, and Alessandro Voto 30 | 31 | > A model and proof-of-concept implementation for decentralized verification. 32 | 33 | ## [*Smart Consent Protocol*](smart-consent-protocol.pdf) 34 | #### by Dr. Shaun Conway, Lohan Spies, Jonathan Endersby, and Tim Daubenschütz 35 | 36 | > Bringing together COALA IP and Consent to deal with digital intellectual property. 37 | -------------------------------------------------------------------------------- /event-documents/plenaries/7-projectupdate.md: -------------------------------------------------------------------------------- 1 | 2 | *Bootstrapping Models for Digital Identity.* Put together six models for bootstrapping a usable system. Next steps are trust models. 3 | 4 | * Deliverable: Paper, by end of November 5 | 6 | *Decentralized Identifier (DID).* Worked through current issues for Spec. 7 | 8 | * Deliverable: Results, on Monday, Spec v4 (Drummond) 9 | 10 | *Identity Engagement Model.* Reinvented customer engagement model and told story of Joram, a Syrian refugee. Came to understand model before we got to technology. 11 | 12 | * Deliverable: Engagement Model (Joe) 13 | 14 | *Specifications for Smart Consent.* Looked at COALA IP and Consent Receipts, created a specification for "smart consent" by mapping Consent Receipts onto COALA IP. 15 | 16 | * Deliverable: Spec, by end of November (Shaun, Tim) 17 | 18 | *Identity Containers.* Took ideas and figured out some best ways to do things and some agreements. 19 | 20 | * Deliverable: v0.1 Standard in next couple of months (Daniel) 21 | 22 | *Portable Reputation Toolkit.* Made visual use case and were able to demo code on the live internet. 23 | 24 | * Deliverable: Use Cases, Code (Noah) 25 | 26 | *Verifiable Claims, Privacy and Security Concerns.* Took privacy and security concerns. 27 | 28 | * Deliverable: Added privacy and security concerns to W3C Verifiable Claims spec, moving into IIW (Manu) 29 | 30 | *Technology that Can Improve Veriable Claims.* We can often create a false sense of security, particularly in ledgers. Creating a position paper to talk about how problems can arise in verifiable claims and how to avoid them. 31 | 32 | * Deliverable: Position Paper (Jason, Greg) 33 | 34 | *Greg's Triangle.* Working on paper. The object is to show how decentralized consensus systems just can't scale as well as a centralized system! 35 | 36 | * Deliverable: Paper (Greg) 37 | 38 | *Update to Chainpoint for Time Stamps.* 39 | 40 | * Deliverable: Update to Chainpoint Spec (Wayne T.) 41 | 42 | *Identity Graphs.* 43 | 44 | * Deliverable: Possible Paper (Marcus) 45 | 46 | *Revocation in Blockchain* 47 | 48 | * Deliverable: Paper (Marta) 49 | -------------------------------------------------------------------------------- /draft-documents/rwot3-digital-verification-outcomes.md: -------------------------------------------------------------------------------- 1 | # Digital Verification Advancements at RWoT III 2 | 3 | ***by Manu Sporny, Christopher Allen, Harlan Wood, Jason Law, and ...(add other participants)*** 4 | 5 | There were a number of enhancements made to Digital Verification at the 6 | 3rd Rebooting Web of Trust event. The following document summarises the 7 | advancements made as a direct result of participation from the workshop 8 | attendees. 9 | 10 | ## Founding of the W3C Digital Verification Community Group 11 | 12 | Based on various hallway and lunch discussions, it became evident that 13 | the community wanted a more permanent location to store artifacts and 14 | work on them. As a result of these discussions, the W3C Digital Verification 15 | Community Group was proposed, supported, and formed. Anyone may join the 16 | group by going to the following URL and clicking the "Join" button: 17 | 18 | https://w3.org/community/digital-verification/ 19 | 20 | The following specifications were migrated from the Web Payments Community 21 | Group to the Digital Verification Community Group: 22 | 23 | * Linked Data Signatures 24 | * RSA 2016 Linked Data Signature Suite 25 | * Koblitz 2016 Linked Data Signature Suite 26 | * Pseudonymous 2016 Linked Data Signature Suite 27 | 28 | ## Authoring the Verifiable Claims Specification Privacy and Security Section 29 | 30 | A group was convened to discuss the privacy and security considerations 31 | for the Verifiable Claims Data Model and Representations specification. 32 | The considerations were documented and integrated into the Verifiable Claims 33 | specification, which can be found at the following link: 34 | 35 | http://opencreds.org/specs/source/claims-data-model/#privacy-considerations 36 | 37 | ## Creation of Koblitz 2016 Signature Suite Specification 38 | 39 | The Koblitz 2016 Signature Suite was discussed, implemented, and formalized 40 | in a Signature Suite specification designed as an extension to the 41 | Linked Data Signatures specification: 42 | 43 | http://w3c-dvcg.github.com/lds-koblitz2016/ 44 | 45 | ## Creation of Pseudonymous 2016 Signature Suite Specification 46 | 47 | A pseudonymous signature suite based on the Camenish-Lysyanskaya signature 48 | mechanism was discussed and formalized in a Signature Suite specification 49 | designed as an extension to the Linked Data Signatures specification: 50 | 51 | http://w3c-dvcg.github.com/lds-pseudonymous2016/ 52 | 53 | ## Addition of Multi Signature and Chained Signature Support 54 | 55 | A number of hallway discussions led to the general requirements and 56 | finalization of the design for multi-signature and chained signature 57 | support in the Linked Data Signatures specification: 58 | 59 | http://w3c-dvcg.github.com/ld-signatures/#multiple-signatures 60 | 61 | -------------------------------------------------------------------------------- /event-documents/plenaries/5-daytwoend-topics.md: -------------------------------------------------------------------------------- 1 | A summary of the status of all the projects to date. 2 | 3 | ## DID: Decentralized Identifiers (Ryan G.) 4 | 5 | v4 Spec should be arriving tomorrow. 6 | 7 | Consensus on what DIDs look like and what they mean. 8 | 9 | Ideas about DiDs on BtC, Uport, Ethereum, and self-sovereign; different methods can be defined for DIDs on different blockchains (or even multiple DIDs on the same blockchain) 10 | 11 | Big issues 12 | * Format for proof of control 13 | * Revocation 14 | * Cross-platform proofs of equivalence 15 | 16 | ## Identity Containers (Daniel B.) 17 | 18 | Top level function areas: 19 | * /profile 20 | * /data/:context 21 | * /permissions 22 | * /stores 23 | 24 | Containers live on edge devices, so stays fresh 25 | 26 | Open Issues: 27 | * Permissions 28 | * Permissioning Rules 29 | * Recovery 30 | 31 | ## Joram (Joe A., Bob) 32 | 33 | UN SDG 16.9 compatible identity engagement model (and extended use case). 34 | 35 | This is one through-line of a sample experience. 36 | 37 | Joram is a Syrian refugee who is washed up on shores of Greece. 38 | 39 | He's then brought in refugee system and identified using a Self-sovereign identity data store. 40 | 41 | ## Bootstrapping Identity & User Adoption (Matt, 42 | 43 | * Looked at traditional and bitworld records and found problems with each. 44 | * Looked at benefits and value proposition of decentralized identity. 45 | * Looked at challenges of decentralized services 46 | 47 | How can we actually create _initial_ moment of trust? 48 | 49 | Created a few bootrapping models 50 | * Direct, in-person KYC to SSID 51 | * Centralized KYC Holder Distributing Existing Attestations to SSID 52 | * SSID + Social Media Link 53 | * P2P + Entity Attestation 54 | 55 | ## Digital Licensing of Intellectual Properties (Shawn, Tim) 56 | 57 | Consent Receipts & [COALA IP](https://github.com/coalaip/specs) 58 | * Looking at their similarities and differences 59 | 60 | About consent mechanism of self-sovereign data 61 | 62 | What happens to data after its been shed? 63 | 64 | **Spec Out Tomorrow.** 65 | 66 | ## Portable Reputation Toolkit 67 | 68 | Creating schema for: reputation + DID + timestamp + signature 69 | 70 | Breaking apart assertion and evaluation and evidence 71 | 72 | Working on proof of concepts: 73 | 74 | 1. Get DID 75 | 2. Make Signed claims with timestamps 76 | 3. Query claims 77 | 4. Evaluate claims with evidence 78 | 79 | ## Humanness in Digital Identity (Kaliyah, Matthew, Daniel) 80 | 81 | Listing what isn't working in current society 82 | and thinking about how to avoid them (or include them) in the digital world 83 | 84 | * Shadows 85 | * Healing 86 | * Tensions 87 | * Complexity 88 | * Vulnerability 89 | * Guardianships 90 | * Mistakes 91 | * Orgs 92 | 93 | There are real-world consequences with many of the other things being described, because the human factors in an identity ecosystem have real consequences. 94 | 95 | **Possibly another paper on shadows (Kaliyah).** 96 | -------------------------------------------------------------------------------- /topics-and-advance-readings/README.md: -------------------------------------------------------------------------------- 1 | ### Topics & Advance Readings 2 | 3 | In advance of the October DesignShop, all participants were requested to post in the [Topics and Advanced Readings](topics-and-advance-readings) folder a 1 or 2 page topics paper to be shared with other attendees on either: 4 | * A specific problem that you'd like to solve with a web-of-trust solution, and why current solutions (pgp or ca-based pki) can't address the problem? 5 | * A specific solution related to the web-of-trust that you'd like others to use or contribute to? 6 | 7 | The topic papers submitted were: 8 | 9 | * [Identity as Linked Data on Immutable Ledgers](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/identity-as-linked-data-on-immutable-ledgers.md) by Tim Daubenschuetz and Trent McConaghy 10 | * [EU General Data Protection Regulation & Self-Sovereign Identifier(s)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/EU-General-Data-Protection-Regulation-%26-Self-Sovereign-Identifier(s)) by David Robert 11 | * [Identity Forking and Federated Reputation](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/identity-forking-and-federated-reputation.md) by Christopher Malon 12 | * [OpenTimestamps: Scalable, Trustless, Distributed Timestamping with Bitcoin](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/opentimestamps.md) by Peter Todd 13 | * [Distributed Identity, Distributed Self](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/DistributedIdentityDistributedSelf.md) by Natalie Smolenski 14 | * [Blockchain Extensions for Linked Data Signatures](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md) by the Signature Super Friends (Manu Sporny, Harlan Wood, Noah Thorp, Wayne Vaughn, Christopher Allen, Jason Bukowski, and Dave Longley) 15 | * [Fit for Purpose Blockchains](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/fit-for-purpose-blockchains.md) by Digital Bazaar (Manu Sporny, Dave Longley, Dave Lehn, and Adam Lake) 16 | * [Taxonomy of Identity Interaction Types](https://github.com/Identitywoman/Writing/blob/master/Taxonomy-of-Identity-Interaction-Types.md) by Kaliya Young 17 | * [Privacy Preserving Identity Architectures](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/privacy-preserving-identity-architectures.md) by Anonymous (no, not that Anonymous, the other one) 18 | * [A Technlogy-Free Definition of Self-Sovereign Identity] (https://github.com/jandrieu/rebooting-the-web-of-trust-fall2016/raw/master/topics-and-advance-readings/a-technology-free-definition-of-self-sovereign-identity.pdf) by Joe Andrieu 19 | * [Architecture of Proof-of-Stake Blockchain that Doesn’t Have Native Coin and its Applicability to Decentralized Trading] (https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/Proof-of-stake-without-native-coin.md) by Pavel Kravchenko 20 | * [JXD Examples] (https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/JXD-Examples.md) by Markus Sabadello 21 | * [Anonymous Credentials in Sovrin] (https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/anonymous-credentials-in-sovrin.md) by Jason Law and Daniel Hardman 22 | * [Portable Reputation Toolkit](/topics-and-advance-readings/portable-reputation-toolkit.md) by Noah Thorp and Harlan Wood 23 | * [Blockchain Attestation Taxonomies] (https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/attestation-taxonomies.md) by Christian Lundkvist 24 | * [Slepak's Triangle: The fundamental user limit of decentralized consensus systems](topics-and-advance-readings/Slepaks-Triangle.pdf) by Greg Slepak (@taoeffect) 25 | * [Sovereign Identity Model for Digital Ecologies](topics-and-advance-readings/Sovereign-Identity-Model-for-Digital-Ecologies.md) by Patrick Deegan 26 | * [Alternative Futures: Framework for Identity Scenarios](topics-and-advance-readings/alternative-futures-frameworks.md) by Alessandro Voto 27 | * [Powering the Physician-Patient Relationship with HIW of One Blockchain Health IT](physician-patient-relationship.pdf) by Adrian Gropper 28 | * [Creating a Humanized Internet] (https://github.com/vshen2010/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/Creating-a-Humanized-Internet.pdf) by Monique Morrow, et al 29 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Rebooting the Web of Trust III: San Francisco (October 2016) 2 | 3 | This repository contains documents related to RWOT3, the third Rebooting the Web of Trust design workshop, which ran in San Francisco, CA, on October 19th-21st, 2016. The goal of the workshop was to generate five technical white papers and/or proposals on topics decided by the group that would have the greatest impact on the future. 4 | 5 | _Please see the [Web of Trust Info website](http://www.weboftrust.info/) for more information about our community, including upcoming events._ 6 | 7 | ## Topics & Advance Readings 8 | 9 | In advance of the design workshop, all participants produced a one-or-two page topic paper to be shared with the other attendees on either: 10 | 11 | * 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? 12 | * A specific solution related to the web-of-trust that you'd like others to use or contribute to? 13 | 14 | Please see the [Advance Readings README](topics-and-advance-readings/README.md) for a listing of all of the papers. 15 | 16 | ## Completed Papers 17 | 18 | The design workshop exceeded its mandate by producing seven papers, which are now all available online: 19 | 20 | ## [*DID (Decentralized Identifier) Data Model and Generic Syntax 1.0 Implementer’s Draft 01*](final-documents/did-implementer-draft-10.pdf) 21 | #### by Drummond Reed, Les Chasen, Christopher Allen, and Ryan Grant 22 | 23 | > The complete draft of the Decentralized IDentifier (DID) model and syntac, a project that has run through the RWOT workshops to date. 24 | 25 | ## [*Digital Verification Advancements at RWoT III*](final-documents/digital-verification-advancements.pdf) 26 | #### by Manu Sporny with Christopher Allen, Harlan Wood, and Jason Law 27 | 28 | > A short overview of enhancements to Digital Verification that came out of RWOT III. 29 | 30 | ## [*Embedding Human Wisdom in Our Digital Tomorrow*](final-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.pdf) 31 | #### by Daniel Hardman, Kaliya “Identity Woman” Young, and Matthew Schutte 32 | 33 | > A discussion of the dangers of transferring wisdom into the digital world, seen through the lenses of vulnerability, shadows, healing, tensions, complexity and gestalt, and organizational choices. 34 | 35 | ## [*Hubs*](final-documents/hubs.pdf) 36 | #### by Daniel Buchner, Wayne Vaughan, and Ryan Shea 37 | 38 | > An overview of the hubs datastore system. 39 | 40 | ## [*Joram 1.0.0*](final-documents/joram-engagement-model.pdf) 41 | #### by Joe Andrieu and Bob Clint 42 | 43 | > An Information Lifecycle Engagement Model that offers a use case for a Syrian refugee. 44 | 45 | ## [*Portable Reputation Toolkit Use Cases*](final-documents/reputation-toolkit.pdf) 46 | #### by Christopher Allen, Tim Daubenschütz, Manu Sporny, Noah Thorp, Harlan Wood, Glenn Willen, and Alessandro Voto 47 | 48 | > A model and proof-of-concept implementation for decentralized verification. 49 | 50 | ## [*Smart Consent Protocol*](final-documents/smart-consent-protocol.pdf) 51 | #### by Dr. Shaun Conway, Lohan Spies, Jonathan Endersby, and Tim Daubenschütz 52 | 53 | > Bringing together COALA IP and Consent to deal with digital intellectual property. 54 | 55 | ## Complete Rebooting the Web of Trust Listing 56 | 57 | A different repository is available for each of the Rebooting the Web of Trust design workshops: 58 | 59 | * [Rebooting the Web of Trust I: San Francisco (November 2015)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust) 60 | * [Rebooting the Web of Trust II: ID2020 (May 2016)](https://github.com/WebOfTrustInfo/ID2020DesignWorkshop) 61 | * [Rebooting the Web of Trust III: San Francisco (October 2016)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016) 62 | * [Rebooting the Web of Trust IV: Paris (April 2017)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017) 63 | * [Rebooting the Web of Trust V: Boston (October 2017)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017) 64 | * [Rebooting the Web of Trust VI: Santa Barbara (March 2018)](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018) 65 | * [Rebooting the Web of Trust VII: Toronto (September 2018)](https://github.com/WebOfTrustInfo/rwot7-fall2018) 66 | * [Rebooting the Web of Trust VIII: Barcelona (March 2019)](https://github.com/WebOfTrustInfo/rwot8-barcelona) 67 | * [Rebooting the Web of Trust IX: Prague (September 2019)](https://github.com/WebOfTrustInfo/rwot9-prague) 68 | * [Rebooting the Web of Trust X: Buenos Aires (March 2020)](https://github.com/WebOfTrustInfo/rwot10-buenosaires) 69 | * [Rebooting the Web of Trust XI: Netherlands (September 2022)](https://github.com/WebOfTrustInfo/rwot11-netherlands) 70 | 71 | ## License 72 | 73 | All of the contents of this directory are licensed [Creative Commons CC-BY](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/LICENSE-CC-BY-4.0.md) their contributors. 74 | -------------------------------------------------------------------------------- /topics-and-advance-readings/rgrant-user-interface-standards-rwot-fall2016.md: -------------------------------------------------------------------------------- 1 | # Towards a User Interface for Selectively Revealing Fine-Grained Personal Information to Transaction Counterparties 2 | 3 | ### by Ryan Grant <rgrant@contract.design>, for Web-of-Trust Design Workshop (fall2016) 4 | 5 | In a world where identity is carried with dignity by the participants 6 | themselves, built through a stored history of social interactions, 7 | revealed (or proven) with the fine granularity necessary to respect 8 | privacy and the security only it can afford, choices multiply. In 9 | this rich sea of choices, we can now ask how to interface a human with 10 | the marketplace, engaged to find the best deal for the least security 11 | risk. 12 | 13 | Domains to Consider 14 | =================== 15 | 16 | The user-interface questions involved may lead us through domains as 17 | diverse as product logistics, medical assistance, the ongoing 18 | governance of human movement, education and caretaking, financial 19 | deals, billing for infrastructure, insurance, peripheral device key 20 | management, task and sharing contracts, the seemingly simple 21 | transmission of messages, and more. 22 | 23 | The Three Standards 24 | =================== 25 | 26 | Along the way to enabling fine-grained identity capabilities in client 27 | software, standardization will be required in three key areas: 28 | 29 | - feature negotiation; 30 | - domain-specific namespaces; and 31 | - transaction dependencies (including templates). 32 | 33 | This is in addition to architectural components less central to the 34 | concern of user interface, such as issuers, repositories, inspectors, 35 | holders, public ledgers, and root storage (terms mostly borrowed from 36 | the list in "Self-Sovereign Identity Architecture" by Manu Sporny and 37 | David Longley). 38 | 39 | To successfully deliver products enabling this vision, 40 | implementations must also develop: 41 | 42 | - a protocol of questions, usually asked by a computer to an authorizing human; and 43 | - clear test scenarios. 44 | 45 | Two Test Scenarios in fully collateralized lending 46 | ================================================== 47 | 48 | Of the many domains listed above, here are two financial contracts 49 | with a slight difference, intended to expose some user interface 50 | issues and spark discussion. 51 | 52 | Collateralized Zero Coupon Bond #1 53 | ---------------------------------- 54 | 55 | Description of terms: 56 | 57 | > A zero coupon bond, with values measured in USD but transacted in 58 | > BTC. Final payment in-kind (as BTC). borrower will lock up 59 | > collateral of 3x BTC into multisig contract. Price oracle required 60 | > as one signing party, along with at least one of the other parties. 61 | > Borrower receives BTC worth "discounted price" at bond initiation, 62 | > and pays about 9% interest. Deal initiates as an atomic 63 | > transaction. 64 | 65 | Face Value : $10,000 66 | Discounted Price : $8,000 67 | Term in Months : 24 68 | Value of Collateral : $24,000 69 | 70 | Wallet user interface requirements (borrower and lender): 71 | 72 | - generate address for multisig payout 73 | - hold complete transaction until bond matures 74 | - alert user when bond matures 75 | - review price oracle's reputation 76 | - request counterparty help revoke price oracle authorization if it fails 77 | - sign complete transaction, with price oracle 78 | 79 | Collateralized Zero Coupon Bond #2 80 | ---------------------------------- 81 | 82 | Description of terms: 83 | 84 | > Exact same numbers and terms as above, except borrower will receive 85 | > USD at bond initiation, and lender will send fiat money through a 86 | > standard escrow house. Once the bond is initiated, the work of the 87 | > escrow house is completed. The bond's collateral is held on the 88 | > Bitcoin blockchain as in the prior example. 89 | 90 | Additional wallet user interface requirements (borrower and lender): 91 | 92 | - store terms of contract with escrow house 93 | - sign escrow contract 94 | - review escrow house AML/KYC requests 95 | - send AML/KYC information to escrow house 96 | - track bond's bitcoin collateral through escrow stages 97 | - review escrow house determination that USD has transferred 98 | - pay invoice to escrow house 99 | 100 | Notes on Direction 101 | ================== 102 | 103 | Comparing the two scenarios above, we observe one consequence of 104 | building out Self-Sovereign Identity tools is increased awareness 105 | about the price of security. 106 | Participants will be able to quickly reject deals containing too 107 | much risk of harm from misused identity, for too little reward. 108 | 109 | The examples we develop further can help guide discussion about how to 110 | solve the three standardization challenges: 111 | 112 | - feature negotiation; 113 | - domain-specific namespaces; and 114 | - transaction dependencies. 115 | 116 | -------------------------------------------------------------------------------- /topics-and-advance-readings/portable-reputation-toolkit.md: -------------------------------------------------------------------------------- 1 | # Portable Reputation Toolkit 2 | 3 | ### By Noah Thorp and Harlan T Wood 4 | 5 | ## Abstract 6 | 7 | Symbolically represented reputation can be regarded as a meta-currency. Like money, reputation gives us access to opportunities, relationships, and resources. 8 | 9 | Reputation information about people's skills is primarily siloed into centralized systems like Linkedin and Upwork. Because of this the value of reputation on these platforms is limited, for both commerce and accreditation. This value may also disappear unexpectedly when centralized services shut down. Both users and platforms can increase the value of reputation "currency" by adopting portable reputation protocols. 10 | 11 | ## The Role of Blockchains 12 | 13 | Cryptocurrencies, blockchains, and smart contracts are designed to be "trustless". This means that once programmed, algorithmic intent cannot be tampered with or corrupted by coercive force. Trustless blockchains are enabled through properties of cryptography in the digital domain. 14 | 15 | Smart contract scripts can be initiated to affect assets stored in blockchain accounts. But any asset or interaction that is not data on a secure blockchain represents counterparty risk. For example, if you wish to pay me Bitcoin in exchange for apples, how do you know that the apples are not rotten? How do you know from blockchain data that the apples are delicious enough to initiate an escrow smart contract to purchase it? Why buy my apples instead of someone else's apples? 16 | 17 | The leap from the domain of the blockchain to outside of it (e.g. the world of apples) implicitly relies upon reputation. Unless every atom in the universe is digitized and controlled by a cryptographically secure reputation system, trust will be necessary to reduce various forms of counterparty risk. Reputation is also essential to decision making amongst possible actions. 18 | 19 | Although blockchains don't fully remove the need for reputational trust, they can play a key role in improving reputation systems. 20 | 21 | ## Desirable Properties for Portable Reputation 22 | 23 | From Aristotle to central banks, currencies have been designed with functional characteristics in mind. Like reputation currencies discussed below, a useful currency is: 24 | * Portable 25 | * Non-forgeable 26 | * Uniform 27 | * Durable 28 | 29 | _Unlike_ reputation currencies, a useful currency is also: 30 | * Scarce 31 | * Divisible 32 | * Transferable 33 | * Fungible 34 | 35 | When all these characteristics are satisfied, money can be an effective store of value, unit of account, and medium of exchange. 36 | 37 | Reputation requires a different but overlapping set of properties. A desirable reputation currency is: 38 | * Verifiable - Reputation is issued by an identity to another identity. Public and private keys are well suited to this. 39 | * Portable - Reputation can be moved from system to system with minimal friction. Portability increases the value of reputation. 40 | * Non-forgeable - Like currency, the account of the reputation issuer and receiver must be securely controlled. 41 | * Uniform - A uniform format is necessary for consistent assessment, discovery and aggregation. 42 | * Timestamped - Reputation claims may be correlated with other events. The order of multiple reputation claims from entity A to B matters. 43 | * Summable - To make decisions one must be able to aggregate and assess multiple claims about the same identity. 44 | * Unique - This summing should not double count copies of the same reputation claim. Reputation increases in usefulness with copying, but copies of the same reputation should not be mistaken for multiple endorsements. 45 | * Durable - Reputation should outlast individual enterprises and technological changes. 46 | 47 | It's worth noting that reputation is frequently assessed recursively. The reputation of the issuer affects the reputation claims they issue. This approach to reputation has been used by Google page rank and described in the Trust Exchange protocol mentioned below. 48 | 49 | ## Towards a Portable Reputation Toolkit 50 | 51 | We propose a portable reputation toolkit. The components of this toolkit are: 52 | * A protocol for storing reputation data in JSON-LD format 53 | * A blockchain anchored timestamp (e.g. OpenTimestamps, Chainpoint) 54 | * Distributed identifier implementation 55 | * API reference implementation for core reputation methods 56 | 57 | ## Related Work To Draw from 58 | 59 | There is significant work by Rebooting The Web of Trust participants and others to build on including: 60 | * [Blockchain Extensions for Linked Data Signatures](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md) 61 | * [Trust Exchange: An Architecture for a Permanent Open Trust Network](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/Trust-Exchange-An-Architecture-for-a-Permanent-Open-Trust-Network.md) 62 | * [Open Timestamps](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/opentimestamps.md) 63 | * [JSON-LD](http://json-ld.org/) 64 | * [Mozilla OpenBadges](http://openbadges.org/) 65 | 66 | ## Attribution 67 | 68 | Many thanks to those who informed this paper, including Christopher Allen and Manu Sporny. 69 | -------------------------------------------------------------------------------- /topics-and-advance-readings/attestation-taxonomies.md: -------------------------------------------------------------------------------- 1 | # Blockchain Attestation Taxonomies 2 | 3 | By Christian Lundkvist, ConsenSys 4 | 5 | ## Introduction 6 | 7 | An *attestation* represents a cryptographic proof of a claim made by 8 | an identity, usually about another identity. Attestations provide a 9 | way for an identity to make a claim that can then be verified at a 10 | later point in time. We will attempt to categorize attestations in 11 | terms of their relationship to blockchain systems and give some use 12 | cases for the different categories of attestations. 13 | 14 | We assume that there is a system of decentralized identifiers and a 15 | reliable mapping from an identifier to its corresponding signing 16 | key. This mapping would most likely be done using a blockchain, but 17 | one could potentially use a Certificate Authority for the mapping. 18 | 19 | ## Pure Offchain (manual sharing/issuing, Verifiable Claims) 20 | 21 | These attestations are held by the user locally off-chain without a 22 | hash on chain and is shared manually with others when directly 23 | initiated by the user. They can consist of JSON Web Tokens and/or 24 | [Verifiable Claims](http://w3c.github.io/webpayments-ig/VCTF/), 25 | i.e. they consist of data (normally JSON data) with an associated 26 | digital signature. 27 | 28 | A user can send an attestation to a service by including it in a 29 | simple HTTP request. 30 | 31 | The receiver of an attestation would validate it by getting the 32 | identifier in the claim data, mapping it to the corresponding public 33 | key (using blockchain or CA) and finally verifying that this public 34 | key signed the attestation. 35 | 36 | The simplest way of dealing with revocation is to have the attestation 37 | be time-limited. If the expiry timestamp in the validation is in the 38 | past the attestation is considered invalid. Also revocation of keys is 39 | then automatic: when looking up the public signing key corresponding 40 | to the identifier, the attestation is only considered valid if the key 41 | is the current one. 42 | 43 | This is quite a strict requirement though, one could imagine accepting 44 | an attestation by an old key as long as the timestamp is 45 | consistent. However this can be hard to verify since an attacker who 46 | steals an old key can also modify the timestamp. It might also be a 47 | pain to have all the attestations made by the user be invalidated when 48 | they lose or update their device (and hence their key). However if 49 | most attestations are issued by corporations the key loss may be less 50 | of an issue. 51 | 52 | For examples of use cases, see 53 | 54 | 55 | 56 | 57 | ## Offchain with hash on-chain (persistent access) 58 | 59 | In this model the attestations are stored in JSON format (normally in 60 | a decentralized system like IPFS, but can also be a traditional 61 | storage service like Dropbox) and a hash of the JSON structure is 62 | stored on the blockchain associated to the identifier (e.g. through an 63 | on-chain registry). This allows persistent access to the data by 64 | anyone, and cryptographically ties it to the identifier of the 65 | identity associated with the attestation (mainly the subject of the 66 | attestation but could also be the issuer potentially). This kind of 67 | attestation is good for profile data of an identity that has been 68 | attested to in a web-of-trust fashion. 69 | 70 | If the data is meant to be public then this is a good way of 71 | distributing it, and cryptographically tie it to an identifier. If the 72 | data is meant to be private then it needs to be encrypted. The data 73 | can be encrypted in a way that only selected identities can decrypt 74 | it, this is sometimes referred to as "selective disclosure". 75 | 76 | We can have these attestations stored in a data structure in IPFS so 77 | that a single hash encompasses all attestations and their history. It 78 | may then be possible to go back in time to check the blockchain 79 | timestamp on each specific attestation, even though at any point in 80 | time only one hash is on chain. 81 | 82 | Examples: [uPort](https://uport.me), [Blockstack](https://blockstack.org) 83 | 84 | ## On-chain (smart contract based) attestations 85 | 86 | This type of attestation exists in a smart contract on a 87 | blockchain. This could be for instance in an access-controlled 88 | registry which maps a key or identifier to the attestation data. The 89 | downside of this approach is that there is a large cost in storing 90 | data on a blockchain and it also requires a blockchain node to 91 | validate the attestation, instead of just checking a digital 92 | signature. 93 | 94 | The upside is that these attestations can be used by other smart 95 | contracts. An example of this is a smart contract issuing and selling 96 | shares in a company. The company may require that buyers of shares 97 | have performed a KYC check. A KYC provider can issue an on-chain 98 | attestation stating that a particular identifier has gone through this 99 | KYC check, without necessarily revealing any more personal information 100 | on the blockchain. The smart contract issuing the shares can then 101 | automatically verify that the users of the smart contract fulfill the 102 | requirements and hence are able to buy shares. 103 | 104 | Example: [Proof Of Physical Address](https://proofofphysicaladdress.com) 105 | -------------------------------------------------------------------------------- /topics-and-advance-readings/EU-General-Data-Protection-Regulation-Self-Sovereign-Identifiers.md: -------------------------------------------------------------------------------- 1 | The New European General Data Protection Regulation (EC Regulation 2016/679) which aims to give citizens back control of their 2 | personal data and create a high, uniform level of data protection across the EU fit for the digital era 3 | was given its final approval by European Parliament on the 14th April 2016. 4 | The reform also sets minimum standards on use of data for policing and judicial purposes. 5 | 6 | The new rules include provisions on: 7 | * a right to be forgotten, 8 | * the right to object and the right to erasure; 9 | * "clear and affirmative consent" to the processing of private data by the person concerned, 10 | * the right to inhibit additional processing of data 11 | * a right to transfer your data to another service provider, 12 | * the right to know when your data has been hacked, 13 | * ensuring that privacy policies are explained in clear and understandable language, and 14 | * stronger enforcement and fines up to 4% of firms' total worldwide annual turnover, as a deterrent to breaking the rules 15 | 16 | But how to actually implement the rights set forth in the GDPR and subsequent legislations and regulations? 17 | More generally, how to operationalise the growing international, supranational and national standards aiming 18 | at reinforcing individual rights and empowering individuals? 19 | To date, individuals have very little means of adjusting to the challenges of big data. 20 | In the meantime, their concerns over the use and control of their personal data are likely to be growing 21 | while their fundamental rights can be endangered. 22 | 23 | Awareness of where and how individuals' data are used is essential. The self-sovereign identifier that is at the core 24 | of the project presented in this paper has the potential to implement the requirements set forth in recent legislation, 25 | regulations and policies that aim to regulate big data, in particular the GDPR. 26 | 27 | This identifier would enable companies, agencies, and other entities collecting individuals' data to comply 28 | with the requirements from the GDPR, in particular in relation to the right to portability of data 29 | or right to be forgotten. In return, this identifier would help consumers track their data, facilitate 30 | their portability, know where their data is used, how it is used and control this use while retaining possession 31 | of their data and choosing where to transfer it and under which conditions. With towards the empowerment 32 | and protection of individuals, this identifier system would enable individuals to retain control over their linkability 33 | and /or correlation across different contexts. 34 | 35 | The self-sovereign identifier offers individuals, also known as data subjects, the possibility e.g. by hashing 36 | and data watermarking technologies to sign and mark their stream of data. 37 | Such identifier system is proposed to be called the ISÆN: Individual perSonal data Auditable addrEss Number. I 38 | ndividuals could generate themselves an ISÆN allowing them to retrieve information about the exact localisation and use of their data. 39 | This smart navigation can be compared with a GPS for the data. 40 | 41 | This innovative and technical proposition for the ISÆN as a new self-sovereign identifier will be accompanied by 42 | an innovative mode of governance to build up the legitimacy of the ISÆN amongst all stakeholders, both public 43 | and private including companies, governments, civil society advocates and individuals. 44 | The proposed CEN Standardisation Workshop will focus on a self-sovereign identifier suitable for personal data ownership 45 | and usage control. 46 | 47 | Benefits to all stakeholders 48 | 49 | * For Institutions and Academics: 50 | ISÆN is a framework that will ease Data 'A Posteriori' compliance audits as recommended by the European General Data Protection Regulation (GDPR) 51 | with an application as early as May 2018. 52 | ISÆN acts as a data provider framework towards the National and European Digital ID provider, facilitating the 'Know Your Customer' 53 | governance (KYC). 54 | 55 | * For the Private sector: 56 | ISÆN will help businesses to add a new 'Private Data Accountability' dimension in their Sustainability report: 57 | economic, environmental, social and private data governance. 58 | ISÆN will help businesses leverage Privacy by Design (PbD) as a unique differentiator 59 | ISÆN will reduce ambiguity for secondary usage of personal data. 60 | 61 | * For Citizens: 62 | ISÆN provides an answer to Digital Citizens’ main concern 'Where are my Data? Who is Using them?' 63 | ISÆN will help them to self-administer their online consents, authorizations, revocation (OptIn/OptOut) 64 | and set the roadmap for a Public Smart Contract/Consent on data privacy. 65 | ISÆN will help them to minimize the disclosure of their persona’s attributes while complying with most “KYC” 66 | requirements. 67 | 68 | * For All stakeholders: 69 | ISAEN will promote the creation of innovative data services and businesses where all the stakeholders 70 | transparently monitor the common public governance and share the benefits of the new personal data economy. 71 | 72 | This standardisation is open to all stakeholders, an we would like to invite the Web Of Trust Community 73 | to join this initiative: http://www.cen.eu/work/areas/ICT/Pages/WS-IS%C3%86N.aspx 74 | 75 | The complete Business Plan of this standardisation is available under: https://standards.cen.eu/BP/2136045.pdf 76 | 77 | Looking forward to discuss this extensively during the rebooting-the-web-of-trust-fall2016 78 | 79 | david.robert@aeternam.eu 80 | -------------------------------------------------------------------------------- /topics-and-advance-readings/EU-General-Data-Protection-Regulation-&-Self-Sovereign-Identifier(s): -------------------------------------------------------------------------------- 1 | The New European General Data Protection Regulation (EC Regulation 2016/679) which aims to give citizens back control of their 2 | personal data and create a high, uniform level of data protection across the EU fit for the digital era 3 | was given its final approval by European Parliament on the 14th April 2016. 4 | The reform also sets minimum standards on use of data for policing and judicial purposes. 5 | 6 | The new rules include provisions on: 7 | • a right to be forgotten, 8 | • the right to object and the right to erasure; 9 | • "clear and affirmative consent" to the processing of private data by the person concerned, 10 | • the right to inhibit additional processing of data 11 | • a right to transfer your data to another service provider, 12 | • the right to know when your data has been hacked, 13 | • ensuring that privacy policies are explained in clear and understandable language, and 14 | • stronger enforcement and fines up to 4% of firms' total worldwide annual turnover, as a deterrent to breaking the rules 15 | 16 | But how to actually implement the rights set forth in the GDPR and subsequent legislations and regulations? 17 | More generally, how to operationalise the growing international, supranational and national standards aiming 18 | at reinforcing individual rights and empowering individuals? 19 | To date, individuals have very little means of adjusting to the challenges of big data. 20 | In the meantime, their concerns over the use and control of their personal data are likely to be growing 21 | while their fundamental rights can be endangered. 22 | 23 | Awareness of where and how individuals' data are used is essential. The self-sovereign identifier that is at the core 24 | of the project presented in this paper has the potential to implement the requirements set forth in recent legislation, 25 | regulations and policies that aim to regulate big data, in particular the GDPR. 26 | This identifier would enable companies, agencies, and other entities collecting individuals' data to comply 27 | with the requirements from the GDPR, in particular in relation to the right to portability of data 28 | or right to be forgotten. In return, this identifier would help consumers track their data, facilitate 29 | their portability, know where their data is used, how it is used and control this use while retaining possession 30 | of their data and choosing where to transfer it and under which conditions. With towards the empowerment 31 | and protection of individuals, this identifier system would enable individuals to retain control over their linkability 32 | and /or correlation across different contexts. 33 | The self-sovereign identifier offers individuals, also known as data subjects, the possibility e.g. by hashing 34 | and data watermarking technologies to sign and mark their stream of data. 35 | Such identifier system is proposed to be called the ISÆN: Individual perSonal data Auditable addrEss Number. I 36 | ndividuals could generate themselves an ISÆN allowing them to retrieve information about the exact localisation and use of their data. 37 | This smart navigation can be compared with a GPS for the data. 38 | This innovative and technical proposition for the ISÆN as a new self-sovereign identifier will be accompanied by 39 | an innovative mode of governance to build up the legitimacy of the ISÆN amongst all stakeholders, both public 40 | and private including companies, governments, civil society advocates and individuals. 41 | The proposed CEN Standardisation Workshop will focus on a self-sovereign identifier suitable for personal data ownership 42 | and usage control. 43 | 44 | Benefits to all stakeholders 45 | 46 | • For Institutions and Academics: 47 | ISÆN is a framework that will ease Data 'A Posteriori' compliance audits as recommended by the European General Data Protection Regulation (GDPR) 48 | with an application as early as May 2018. 49 | ISÆN acts as a data provider framework towards the National and European Digital ID provider, facilitating the 'Know Your Customer' 50 | governance (KYC). 51 | 52 | • For the Private sector: 53 | ISÆN will help businesses to add a new 'Private Data Accountability' dimension in their Sustainability report: 54 | economic, environmental, social and private data governance. 55 | ISÆN will help businesses leverage Privacy by Design (PbD) as a unique differentiator 56 | ISÆN will reduce ambiguity for secondary usage of personal data. 57 | 58 | • For Citizens: 59 | ISÆN provides an answer to Digital Citizens’ main concern 'Where are my Data? Who is Using them?' 60 | ISÆN will help them to self-administer their online consents, authorizations, revocation (OptIn/OptOut) 61 | and set the roadmap for a Public Smart Contract/Consent on data privacy. 62 | ISÆN will help them to minimize the disclosure of their persona’s attributes while complying with most “KYC” 63 | requirements. 64 | 65 | • For All stakeholders: 66 | ISAEN will promote the creation of innovative data services and businesses where all the stakeholders 67 | transparently monitor the common public governance and share the benefits of the new personal data economy. 68 | 69 | This standardisation is open to all stakeholders, an we would like to invite the Web Of Trust Community 70 | to join this initiative: http://www.cen.eu/work/areas/ICT/Pages/WS-IS%C3%86N.aspx 71 | 72 | The complete Business Plan of this standardisation is available under : https://standards.cen.eu/BP/2136045.pdf 73 | 74 | Looking forward to discuss this extensively during the rebooting-the-web-of-trust-fall2016 75 | 76 | david.robert@aeternam.eu 77 | -------------------------------------------------------------------------------- /topics-and-advance-readings/alternative-futures-framework.md: -------------------------------------------------------------------------------- 1 | # Alternative Futures: Framework for Identity Scenarios 2 | 3 | #### Submitted for the Web of Trust Design Workshop 4 | 5 | #### By Alessandro Voto, Co-Lead, Blockchain Futures Lab at the Institute for the Future 6 | 7 | #### 10/19/16 8 | 9 | There is no single future to be forecasted when it comes to identity. Instead, there are many different futures, each of which carries its own weight and relies upon a different set of assumptions. 10 | 11 | The assumptions that shift which world we actually come to inhabit are many. They include the progression of various combinatorial technologies. They include political and institutional decisions. Perhaps most consequentially, they include human intention as individuals strive to achieve their own preferred futures. 12 | 13 | To this end, when considering the future of identity that may come of the projects we undertake in the present, it’s useful to think about how these projects will evolve across a number of potential future environments. 14 | 15 | Jim Dator, a professor at the University of Hawaii at Manoa, developed a framework that is well suited to this task. Known as the Alternative Futures framework, it was constructed by observing archetypal commonalities across future visions he had collected from art, culture, academic thought, business planning, etc. The framework boils down to four such archetypes, which the Institute for the Future has revised to its own needs as part of our ongoing practice, and which I will illustrate within the context of identity and blockchain-based applications specifically. 16 | 17 | The first archetype is growth, or continuation of the current paradigm. As with all archetypes, this isn’t “growth” of something like identity. Rather, it means a growth of the systems and practices we’ve relied upon for structuring identity. A growth scenario for blockchain-based identity might mean large institutions and corporations that have traditionally managed identity continue to do so, but armed with immutable identity data and cross-organizational shared records. It would be a continuation of data mining (with or without consent), but from advanced sensors like implants and gaze trackers, plus the sense-making capacity of AI, and with international reach to those who have been yet unserved by these institutions. It would mean faster and more trustworthy services, but a growing disadvantage to those who wish to hide or nuance their own representations of identity. Growth isn’t always a “preferred future”, as it carries with it the strains of unchecked resource collection, and data is no exception. That said, there is tremendous potential in standardized, interoperable records with (perhaps begrudgingly) trusted institutions. 18 | 19 | The second archetype is constraint. This is a situation in which the normal paradigm for operating is held down in some way, usually by political actors, environmental/resource limitations, or user pushback. In the identiy space, this might be kicked off through regulations like the “Right to be Forgotten” or through intentional obfuscation of identity by users. Traditional players would need to bargain for scarce information resources, perhaps even purchasing data directly from users on a per-trait basis. This could encourage a suite of applications that let people selectively discolose information in exchange for information. Constraint archetypes lend themselves to creativity and experimentation as people work around gradually dwindling resources and uncertainty. 20 | 21 | Collapse is the third archetype. It is a situation in which the very foundations of our systems and norms fall apart from under us, necessitating adaptation and decentralized structures. Within the context of identity, this could be brought about by relentless identity breaches, shaking confidence in centrally-manged systems. Or, this may be brought about by a grassroots movement against indentity data exploitation. Collapse is not always negative; it can be the societal catalyst for a Cambrian explosion of new approaches, in this case for local identity services. In this world, identity might be highly relationship based, bringing interpersonal information onto a slew of small community-run blockchain systems. The challenge in this world, though, is organizing through the chaos to create interoperable systems with network effects sufficient to maximize security and collective value. We may see agents that act as oracles, pulling fragments of information from multiple disjointed architectures to construct a solid view of a person. We may also see exciting new personal identity portfolios from which a person can share information on their own terms from a variety of local interactions. 22 | 23 | The final archetype, and perhaps the most difficult to construct, is transformation. This is a re-writing of rules and practices due to some unforeseen shift in the operating environment. In a transformation world, many of our past assumptions or metrics become invalid or insufficient. In the case of identity, we may see the shift toward identity-less platforms that enable meaningful interaction without personal data or persistant accounts, as Bitcoin has done for payments with pseudonymous addresses and HD wallets. This will be a world in which we are not judged based on reputation or credentials, but upon our ability to abide by protocols and generate value within the immediate context of interaction. It is a world of proofs without underlying data. It is a world in which the work and information presented by an artificial intelligence is indistinguishable from that of a human, and in which this difference is largely inconsequential to the transaction partner. 24 | 25 | Of course, the singular future we actually face will likely be some combination of all of these archetypes, and so many more that we can construct and pre-experience as a simulation. The role of scenario planning within futures is to learn from engaging with these theoretical possibilities, and come back to the present to design more robust and human-centered projects that enable our preferred futures. -------------------------------------------------------------------------------- /topics-and-advance-readings/user-controlled-key-recovery.md: -------------------------------------------------------------------------------- 1 | # Recovery strategy for user-controlled keys for self-sovereign identity 2 | 3 | ### By Glenn Willen 4 | 5 | Self-sovereign identity requires that users retain ultimate control of their own authenticators -- in a cryptography-based system, this means cryptographic keys. This is problematic, because even highly-skilled end users have trouble maintaining the security posture required for safe key storage, as demonstrated by Bitcoin hacks -- now that stolen keys are worth money, we’re suddenly seeing a lot more keys get stolen, even from large companies with IT and security departments. Obviously this is not tenable for an individual user. 6 | 7 | I think a two-pronged strategy is appropriate here: (1) help the user store and use their own keys safely and securely, and (2) help the user recover their keys in case of loss or theft. I separate these because I am convinced that the best solution to the second is going to be a slow offline recovery procedure, which is incompatible with day-to-day use of key material. In any system for storing cryptographic material, there is always a balance between availability -- ensuring that keys can always be used by authorized users -- and confidentiality -- ensuring that they cannot be used by unauthorized users. If the recovery procedure is allowed to be slow, with plenty of time for notification to the key owner, then we can bias the recovery procedure towards availability (and the day-to-day storage towards confidentiality). 8 | 9 | I will focus here on part (2), key recovery. In my view the most fundamental way of identifying an individual is not via something we know, which can be forgotten, or something we have, which can be lost; or even the traditional “something we are”, biometrics, which can be compromised. Instead, I claim the most fundamental way of identifying an individual is via their connections to other people. Facebook has already introduced friend-based account recovery to a huge audience with “Trusted Contacts” -- see https://www.facebook.com/notes/facebook-security/introducing-trusted-contacts/10151362774980766/. Although I’ve liked this idea for a long time, the introduction of Trusted Contacts shows promise that people would accept the idea of their contacts collectively having ultimate control of their digital identity. 10 | 11 | To implement friend-based key recovery, an obvious choice is to use some K-of-N secret sharing scheme. With arbitrary data, we can use SSSS (https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing). Depending on the specific secrets involved, we may have better options -- with Bitcoin script-based keys, we can use the built-in multisignature system, while also having flexibility to require a time- or block-based notice period before recovery, for example. 12 | 13 | In such a system, we must ensure the probability is negligible that too many people lose their keys all at once and prevent reasonable recovery. A key aspect of ensuring that recovery is possible is ensuring that failures are detected promptly. Imagine a simple 1-of-N system wherein failure of a ‘friend shard’ is a poisson process -- fixed probability per unit time. The probability of losing enough shards to prevent recovery is highly dependent on the time to notice a failure. If a shard has a 90% probability of failure per year (17.5% per month), then the probability of losing three shards over a year is 72.9% -- a dismal figure. But if we reliably detect and repair failure of a shard within a month, then the probability of total failure each month is about half a percent, and the total yearly chance of failure is only about 6.2% -- hugely better! 14 | 15 | From this back of the envelope computation, I take away two lessons: 16 | 17 | 1. On the meta level: A system like this MUST be analyzed quantitatively to determine whether its properties are reasonable. You can’t easily eyeball the system description above, and correctly conclude that monthly checks are safe even though yearly checks are disastrous. Arguing about what is a sufficiently safe way to store keys can only be done with math. 18 | 19 | 2. On the object level: It’s hugely important for key backups to be stored in a way that allows fast verification that they’re still alive. This makes a HUGE difference to durability; that in turn means that keys can be sharded with significantly higher thresholds for reassembly, which improves confidentiality (protection from compromise). 20 | 21 | To maximize the aggregate probability of success in maintaining both availability and confidentiality, beyond carefully selecting the parameters of the system -- number of shards, reassembly threshold, frequency of verification -- we also want to maximize the availability and confidentiality properties of the individual shards. We do not need, and in fact do not desire immediate online access to the shards, and we DO require other properties such as rapid discovery of loss or compromise. The best way to ensure these things would seem to be a hardware device to store key shards and enforce the properties we want.1 It needs to frequently broadcast to the outside world, to provide positive confirmation that the secret data remains intact, but should not be able to transmit the secret data itself under any circumstances. If the secret data is a key, this could be done by signing a timestamp with it; stronger proof of availability could be enforced by signing nonces, but this would require two-way communication with the outside world, which is less safe against compromise than a one-way broadcast. When commanded to perform a recovery the device must stop broadcasting the all-clear, and instead broadcast the fact that the key shard has been released (and the key owner must presume that the absence of any broadcast at all might also mean that the key shard is compromised.) 22 | 23 | A huge number of open questions remain, but I see this as a productive way forward in answering the question of how self-sovereign identity might be maintained safely and securely with cryptographic keys, despite the inability of typical users to maintain any reasonable level of computer security. 24 | 25 | ## Footnotes 26 | 27 | [1] I am indebted to Greg Maxwell for quite a bit of discussion about how such a device might be designed, but all errors and poor design choices herein are my own. 28 | -------------------------------------------------------------------------------- /topics-and-advance-readings/identity-as-linked-data-on-immutable-ledgers.md: -------------------------------------------------------------------------------- 1 | # Identity as Linked Data on Immutable Ledgers 2 | 3 | By 4 | 5 | - Tim Daubenschuetz, @timdaub, \ 6 | - Trent McConaghy, @trentmc0, \ 7 | 8 | 9 | ## Update 10 | 11 | We just released a first draft of the [COALA Intellectual Property Specification](https://github.com/COALAIP/specs/blob/master/README.md). 12 | Additionally, we released a document outlining the [models' schema definitions](https://github.com/COALAIP/specs/blob/master/data-structure/README.md). 13 | Feedback, comments and questions are welcome! 14 | 15 | 16 | ## Motivation 17 | 18 | Content creators on the Web are getting a raw deal. They get a fraction of a cent for an ad played on YouTube, and nothing 19 | on Facebook, for filling these sites with traffic-driving content. It’s hard to make a living when you’re a creative. 20 | Licensing is hard; the user experience is bad, so lawyers and middlemen extract the most value. In the music industry, more money 21 | flows into the pockets of distributors than creatives. Consumers are often happy to pay for their content. Instead, they're 22 | forced to sit through ads. 23 | 24 | 25 | ## The COALA IP Working Group 26 | 27 | To address these problems, COALA IP (Coalition Of Automated Legal Applications, Intellectual Property) was 28 | formed to design and implement a free and open specification for handling digital licensing of intellectual property. Its 29 | goals are to establish open, free, and easy ways to claim attribution, add metadata, license works, mediate IP disputes, 30 | and authenticate claims of others. Furthermore, the group believes that there should be global agreement at the data 31 | level without the need for centralized control. 32 | 33 | A recent, more concrete, endeavor of the group has been to write a specification for handling digital licensing of 34 | intellectual property on immutable ledgers. It's an effort to transform the implementation-agnostic [Rights Reference Model](http://doi.org/10.1000/284) 35 | of the [Linked Content Coalition](http://www.linkedcontentcoalition.org/index.php) into a free and open guideline. It 36 | outlines technologies that could be leveraged for implementation and structure of a specification for all involved parties: 37 | creators, rights holders, consumers, developers, etc. The protocol is to be technology-opinionated, but ledger-agnostic. 38 | 39 | 40 | ## The COALA IP Protocol 41 | 42 | The COALA IP protocol is essentially two parallel technical efforts: 43 | 44 | 1. It's a community-driven effort to find and define a minimally-viable set of data for licensing intellectual property 45 | (using RDF schema definitions) 46 | 2. It's a free and open messaging/communication protocol for license-transactions 47 | 48 | 49 | At its core, the RDF schema defines ontology over seven main entities and their interconnections. The ontology as well as 50 | all entities have been derived from the LCC's RRM: 51 | 52 | - **Place:** A localizable, physical place (e.g. an address, a city, a country, ...) 53 | - **Manifestation (digital or physical):** A perceivable creation (e.g. a print of a photograph of a certain scene) 54 | - **Creation:** A distinct, abstract creation whose existence is revealed through one or more manifestations (e.g. The idea 55 | to photograph a certain scene) 56 | - **Right:** A transferable entity connected to a manifestation that entitles the owner to do something in relation 57 | to a Creation (e.g. a permission to display a Manifestation publicly) 58 | - **RightsAssignment:** A transfer of a Right (e.g. Transferring the permission to display a Manifestation publicly) 59 | - **Assertion:** A claim made about the truth or falsehood of assertions made in the ontology (e.g. A statement vouching 60 | for the validity that a certain Party is the original author of a Creation) 61 | - **Party:** An individual or a group of individuals representing right holders, licensors, users and so on...(e.g. a human being 62 | or a group of human beings) 63 | 64 | 65 | Since finding a minimally-viable set of properties that describe each of the entities' features is difficult without having 66 | domain-specific industry knowledge, COALA IP's plan is to open this process up to the community, thereby letting the 67 | community define and derive domain-specific RDF schema. As soon as saturation for changes in schema emerge, further 68 | formalization is planned to take them to an appropriate international standards organization. 69 | 70 | Key technologies used to achieve this endeavor are: 71 | 72 | - **[JSON-LD](https://www.w3.org/TR/json-ld/):** A recently emerged RDF serialization format, that brings Linked Data to the 73 | JSON data structure 74 | - **[IPLD](https://github.com/ipfs/specs/tree/master/ipld):** A data structure to merkle-link JSON objects in order to 75 | retrieve them with merkle-paths, providing cryptographic integrity-checking of the data as well as content-addressable 76 | storage 77 | - **[ILP](https://github.com/interledger/rfcs):** A set of specifications for sending (at this point only: fungible) digital 78 | assets across different ledgers 79 | 80 | 81 | ## The Missing Link: Identity 82 | 83 | As of the writing of this position paper, all pieces of the specification are in place except one: **Identity** (the so 84 | called "Party" entity mentioned in the previous section). 85 | 86 | Members of the COALA IP working group would like to actively participate in design-workshops of the Web of Trust working 87 | group to discuss identity solutions that fulfill the following systematic requirements: 88 | 89 | - An Identity's identifier must be resolvable within the Internet 90 | - An Identity's properties must enable other Identities to validate the cryptographic integrity of an Identity's signed data 91 | - An Identity must have at least one persistent unique public identifier that is both human- and machine-readable 92 | - An Identity participates in a global trust network, having it's trustworthiness continuously evaluated by other 93 | participating Identities 94 | 95 | 96 | In order to be compliant with the current state of the COALA IP protocol, the following requirements should be fulfilled: 97 | 98 | - If an Identity can be resolved within the Internet, then its data can be integrity-checked cryptographically (compare: 99 | content-addressed storage provided by IPFS and IPLD is favored) 100 | - Preferred serialization formats of an Identity object are JSON, JSON-LD or IPLD 101 | - A resulting specification regarding Identity management respects the immutability of data 102 | 103 | 104 | Additionally, some philosophical requirements the COALA IP group would like to address: 105 | 106 | - A digital Identity solution must not be based on any proprietary technology 107 | 108 | 109 | ## Attribution 110 | 111 | This paper couldn't not have been written without the tremendous efforts from collaborators and employees of the following 112 | projects: 113 | 114 | - The Linked Content Coalition 115 | - IPFS 116 | - The Interledger Protocol 117 | - RDF, JSON-LD and all related Semantic Web and Linked Data standards and implementations 118 | - The COALA IP working group 119 | - BigchainDB (special thanks go to Ryan Henderson, Alberto Granzotto, Dimitri De Jonghe) 120 | -------------------------------------------------------------------------------- /topics-and-advance-readings/identity-forking-and-federated-reputation.md: -------------------------------------------------------------------------------- 1 | # Identity Forking and Federated Reputation 2 | 3 | By Christopher Malon, Group Ring, Inc. (https://groupring.net) 4 | 5 | Motivation 6 | ========== 7 | 8 | Privacy requires an individual to perform transactions under many 9 | different identity tokens, which are not linked in any outside database. 10 | A principal may wish to establish his possession of a attestation, 11 | without revealing his complete identity. However, attestations should 12 | not be bearer instruments. An attestation must be issued in a way so 13 | that it is useless to anyone but the person to whom it was originally 14 | issued. 15 | 16 | This proposal provides a "forking" mechanism to issue attestations and spawn new 17 | identities from parent identities, in a way that attestations can be 18 | attributed to the spawned identity individually. 19 | 20 | The last section provides a federated mechanism for identities to 21 | establish their reputation data, both positive and negative, using a 22 | public blockchain. Forking is essential for this proposal, because this 23 | proposal gives a method to establish a complete history of a single 24 | identity’s actions, which could easily become public knowledge. A 25 | principal retains control only by spawning subidentities up to the 26 | finest level of activities that she wishes to be evaluated as a unit. 27 | 28 | Composite keys 29 | ============== 30 | 31 | As implemented in Bitcoin's P2SH protocol, an M-of-N multisig address 32 | is implemented by a script address. When payment using the script address 33 | is verified, the script is revealed, including the addresses of the 34 | participating public keys. 35 | 36 | However, some public key cryptosystems have a property that enables a 37 | composite signature scheme in which the participating keys can remain private. 38 | For example, in an elliptic curve digital signature algorithm (ECDSA) [1], 39 | a finite field F, an elliptic curve E with points taking cordinates in F, 40 | and a base point G on the curve E are fixed. In Bitcoin, E, F, and G 41 | are defined by the standard secp256k1 [2]. 42 | Private keys are integers x from 1 to n-1, where n is the order of the point G, 43 | and the corresponding public key is the scalar multiple Q = xG. 44 | Thus, if Q = xG and R = yG are two public keys, Q+R is a public key 45 | with private key x+y. 46 | 47 | Identity forking 48 | ================ 49 | 50 | Attestation with identity forking 51 | --------------------------------- 52 | 53 | For Bob to confer an attestation upon Alice that she can present separately from her other attestations, 54 | 55 | 1. Alice generates an additional keypair, called Carol. 56 | 57 | 2. Alice sends her own public key and Carol's to Bob. She signs the message twice, once with Alice's private key, and once with Carol's private key. 58 | 59 | 3. Bob decides that he wants to confer the attestation upon Alice, usually based on some prior knowledge of Alice. 60 | 61 | 4. Bob computes the public key Diana = Alice + Carol. 62 | 63 | 5. Bob signs a message conferring the attestation upon Diana, and sends it to Alice. 64 | 65 | Note that Bob cannot simply issue the attestation to one of Alice's derived keypairs, per BIP 32 [3], in lieu of this procedure, because derived keys are recognizable based on knowledge of an ancestor public key. 66 | 67 | The point of requiring Alice's private key for every use of Diana's key is to prevent Alice from giving or selling use of her attestation to some party Eve who could use it without her further participation. If Alice did not have to sign a message once using Carol's key, Alice could give her credential to Eve without knowing Eve's private key and without Eve knowing Alice's private key, simply by defining Carol = Eve - Alice. 68 | 69 | Verification 70 | ------------ 71 | 72 | To verify that Elizabeth has the attestation addressed to Diana, Frank 73 | may require Elizabeth to sign her messages using the composite key 74 | Diana + Elizabeth = (Alice + Carol) + Elizabeth. 75 | 76 | Completeness of a reputation chain 77 | ================================== 78 | 79 | Reputation is a concept that mixes positive and negative attestations, 80 | or successes and failures. 81 | An example of a positive attestation is a diploma, which certifies that someone 82 | graduated from a certain college with a certain degree. 83 | Typically, people are happy to present positive attestations on demand, 84 | but they do not have an incentive to report all the 85 | times they failed. 86 | 87 | Publication to a blockchain allows an identity to establish the 88 | completeness of a series of actions whose ratings are being reported. 89 | 90 | Each identity in our framework is identified by a globally unique string 91 | and possesses a public/private keypair. An *identity* 92 | refers simply to this set of attributes. A principal may utilize many 93 | different identities, with or without links or attestations among them. 94 | The principals generate at least one identity for participating in each 95 | group of activities whose reputation they may want to reveal separately. 96 | 97 | Our system involves interactions between three kinds of roles, some of 98 | which may be shared by a single identity: *raters*, who 99 | assign ratings; *ratees*, who receive ratings; and 100 | *bazaars*, which operate services in which raters rate 101 | ratees. 102 | 103 | A *reputation claim* consists of: a *rater*; a 104 | *ratee*; a *bazaar*; a 105 | *timestamp*; (optionally) a *subject identifier*; 106 | (optionally) *comments* from the rater; a unique *action 107 | identifier*; the rater’s *rating* (a real number); 108 | the ratee’s desired *weighting* of the action; and a 109 | *signature* from the bazaar. The bazaar simply asserts that 110 | the rater rated the ratee as indicated. Typically, the bazaar would be 111 | an online service mediating a transaction, but it could be the same as 112 | the rater. 113 | 114 | In order to receive ratings for an action X, Elizabeth: 115 | 116 | 1. Publishes an *authorization* to be rated on X to a 117 | blockchain. The authorization establishes that the ratee identity 118 | took the action being rated, and designates where the ratings should 119 | come from. The authorization specifies: the *action 120 | identifier* (X); the *ratee* (Elizabeth); the 121 | *bazaar* to collect the rating from the rater(s); 122 | whether only a *single* rating is expected, or many; 123 | the *rating delivery frequency*, if many ratings are 124 | expected; the ratee’s desired *weighting* for the 125 | action; (optionally) a *subject identifier* string; and 126 | a *multisig* of the above data by the ratee and the 127 | bazaar. 128 | 129 | 2. Receives deliveries of reputation claims from the bazaar, which it 130 | also publishes on the blockchain. 131 | 132 | Bitcoin’s transaction capacity would not provide enough space for every 133 | authorization and reputation event to be published directly to its 134 | blockchain. Additionally, transaction fees would be prohibitive. We 135 | suggest that a bazaar that deals with large volumes of reputation events 136 | consolidate its posts, by posting a tiny URL of the complete event list 137 | along with a hash of the list’s contents. Interested verification 138 | services may follow all these links and expand them into a database of 139 | identities and their authorizations and ratings. 140 | 141 | Bibliography 142 | ============ 143 | [1] https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm 144 | 145 | [2] http://www.secg.org/sec2-v2.pdf 146 | 147 | [3] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki 148 | 149 | -------------------------------------------------------------------------------- /topics-and-advance-readings/Proof-of-stake-without-native-coin.md: -------------------------------------------------------------------------------- 1 | **Architecture of proof-of-stake blockchain that doesn’t have native coin and its applicability to decentralized trading** 2 | 3 | Dr. Pavel Kravchenko, Distributed Lab 4 | 5 | _Abstract_ 6 | 7 | This paper outlines challenges and architecture of decentralized trading system that by design should be connected to existing financial infrastructure. It allows any trading platform to participate in consensus while effectively preventing Sybil attack by using proof of trust. We will review the solution on example of auctions that government helds to sell its property. We will show how decentralized trading network unifies relationships between all involved parties. 8 | 9 | **1 Introduction** 10 | 11 | Decentralized trading is a very important feature of systems that should be used in public sector. Government is bad in managing centralized systems where corruption is very easy. Centralization contradicts with transparency and immutability of information. Potential solution could be usage of decentralized system where government _participates_ in the decision making process. Other participants are market players - trading platforms that sell their services to buyers. Every trading platform has internal goal to maximize own profits and therefore has to watch others. Idea is to allow free access of trading platforms to participate. 12 | 13 | Decentralize auction system that is based on described idea was launched in Ukraine in July, 2016, two cities held trades on it. On Sep, the 2nd, it was publicly used by Land Registry of Ukraine and soon by law will be official platform to rent all land in Ukraine. 14 | 15 | **2 Inherent challenges of a decentralized trading system** 16 | 17 | 1. Risk of a Sybil attack in a case why anybody can become a trading platform. Attack happens when somebody obtains control over many nodes. 18 | 19 | 2. Complicated definition of truth for an existing user or third-party observer (something similar to longest chain rule in Bitcoin). It should be clear which nodes are honest and which are not in such cases: 20 | 21 | - when some group of nodes starts rejecting transactions from other nodes 22 | 23 | - when there is a fork of the blockchain 24 | 25 | 3. Complexity of guaranteeing the fact that all require nodes agree with each other 26 | 27 | 4. Not clear plan of actions for the user in case of misbehavior of some nodes. 28 | 29 | Other challenges to create decentralized auction to that could be used in a public sector were: 30 | 31 | - how to connect it to the existing payment infrastructure 32 | 33 | - how to prevent censorship from government side and from existing trading platforms 34 | 35 | - how to make consensus fair (i.e. proof-of-what to use?) if everybody can join 36 | 37 | - who is the final source of truth 38 | 39 | **3 Ecosystem** 40 | 41 | Ecosystem consists of such players: 42 | 43 | - --Buyer - user that wants to buy certain item on the auction 44 | - --Seller - user that wants to sell certain item on the auction (government in case of privatization. Actual sale happens after auction is completed) 45 | - --Trading platform - private company that lists items on some web-site and attracts users to it. Business model for it is taking registration fees from the buyers 46 | - --Bank - holds accounts of trading platforms and provides a proof that payments happened 47 | - --Observer - independent entity that does verification of the trading process. Could be auditor, journalist or any of above mentioned player 48 | 49 | All these players maintain blockchain, but only trading platforms are validators. 50 | 51 | **4 Proof of trust as a way to achieve consensus in a real world** 52 | 53 | Since such systemcannot have a proof of work and even native coin the hardest challenge was how to de or decision was to design consensus algorithm that allows anybody join, but is resistant to a Sybil attack. For that we had to define source of truth that everybody recognizes (for example in Bitcoin it is hash rate and in NXT it is stake size). Decision was to make the observer (i.e. anybody) the source of truth. But it was hard to define what is "truth". That's why it was decided that money (or trust) is ultimate truth meaning that users will chose those trading platforms that behave correctly. Using trading platform means paying for registration and bids through this platform. Then sort of proof-of-stake consensus algorithm can be used where stake size of the platform equals percentage of money that was sent through it. This leads to a conclusion that if some trading platform is corrupted (for example sells item cheaper to specific users while rejecting higher bids from regular users) then users will move to another trading platform and therefore increase its stake size. To connect blockchain and regular banking infrastructure it was decided to use signed receipts from banks - when somebody makes a bid, payment goes to a particular account (seller of the item) and bank can produce such a receipt which being added to the blockchain proves that money actually was sent through particular trading platform. I.e. we introduce proof-of-trust (combination of proof of stake and proof of identity). Additionally such a solution solves KYC issue - bank always identifies payee and this information is stated in the receipt. 54 | 55 | **5 Assumptions and limitations** 56 | 57 | User should be able to watch any node using standard open-source software in order to analyze copy of blockchain that it maintains. It will allow to notice fraud attempts. 58 | 59 | Trading process is separated for different items. Different trading platforms are able to participate in different auctions. 60 | 61 | We assume that because of transparency and scale effect majority of users will be interested in honest auction process and therefore will not tolerate misbehavior. As a result users will try to join only trading platforms that behaved correctly in the past. However we system can't be protected from instant fraud where previously honest platforms decided to convince fraud. 62 | 63 | In case of fork everybody is able to make decision themselves based on set of consensus rules. In our case it is "higher trust" rule that says that as main is considered fork which is supported by trading platforms that collected majority of registration fees from the users (70% or so). This rule is applied item by item, i.e. proof of trust has no history. 64 | 65 | Obviously, proof of trust could be calculated based on any payment scheme that users trust and can verify and could be even Bitcoin. For now we use signed banking receipts because everybody is able to verify digital signature on them and banks are highly unlikely to forge them. 66 | 67 | **6 Flow of the trading** 68 | 69 | 1. Network set-up 70 | 71 | Trading platforms set-up nodes and join the network 72 | 73 | Trading platforms pay registration fee to some account, mentioning public key and identity of the trading platform 74 | 75 | Proof of payment is signed by the bank and is submitted to the network, contains public key of the trading platform 76 | 77 | 2. Placing item to the action 78 | 79 | Seller places item to be sold to the network via API of a particular trading platform 80 | 81 | Item gets distributed over the network among trading platforms that want to participate in the trade 82 | 83 | 3. User registration 84 | 85 | Users select trading platform to place bids for particular item being sold 86 | 87 | Users pay registration fee to the bank account of the particular trading platform, mentioning their public key, public key of the trading platform and item ID. 88 | 89 | Proof of payment is signed by the bank and is submitted to the network 90 | 91 | Trading platforms reach consensus about who is eligible to validate bidding process 92 | 93 | 4. Bidding 94 | 95 | Users who are registered for the auction place their bids 96 | 97 | As time passes eligible trading platforms reach consensus about the rank of participants in the auction 98 | 99 | All processes are independent for different items being sold. 100 | 101 | There is no cryptocurrency in the network, but proof of payment signed by the bank is playing its role. When payment happens everybody sees that certain amount of money has been spent. 102 | 103 | **Potential attacks** 104 | 105 | If malicious user controls 70% (or whatever is the limit) of registration fees for the item, the consensus process can be corrupted (for example bids from honest users could be rejected). 106 | 107 | **Future improvements** 108 | 109 | The future task is to make semi-anonymous auctions, when bidders are able to prove that they paid deposits without revealing their own identity. 110 | -------------------------------------------------------------------------------- /event-documents/plenaries/2-lightning.md: -------------------------------------------------------------------------------- 1 | ## Good Use Cases (Joe Andrieu) 2 | 3 | Fluid Development supports requirements modeling, centered on use cases. 4 | 5 | A use case should define how a system is used with a value-creating transaction (creating value for the human user). 6 | 7 | A good use case: 8 | * Is a single transaction 9 | * Has a clear, memorable name 10 | * Distinguishes unique capabilities 11 | * Is describable, empathizable, actionable. 12 | 13 | There are two ways to think about use cases, as a problem or a solution. Either is incomplete, need them together as action/reaction pair. 14 | 15 | [[link to Joe's powerpoint]] 16 | 17 | ## Identity Lifecycle (Greg Slepak) 18 | 19 | Decentralized identity lifecycle management. 20 | 21 | There are a lot of related elements: 22 | * Attestations (and revocations) 23 | * Namespaces and how to deal with them 24 | * Thwarting man-in-the-middle atacks 25 | * Recovering identity 26 | 27 | The lifecycle goes from Registering an identity (in a namespace) to Use of identity and Use of attestations to Recovery of identity to Expiration of identity. 28 | 29 | ## Conflicts in Privacy Preserving Architure (Manu Sporny) 30 | 31 | There are two camps of thought: 32 | * Self-sovereign identity 33 | * Same-origin identity 34 | 35 | ### Same-Origin Identity 36 | 37 | This camp says: _You should never have an identifier that crosses domains because it allows correlation._ 38 | 39 | ### Self-Sovereign (Cross-Origin) Identity 40 | 41 | This camp says: _It's OK to have identifier that crosses domains as long as you have anonymizer._ 42 | 43 | _These communities are not talking to each other, and this has led to conflicts and will lead to more in the next couple of years. The goal here is simply to note that there's a conflict and we need to talk!_ 44 | 45 | ## How Do We Get Institutions to Accept Self-Sovereign Identity (Michael) 46 | 47 | It's an interesting question, but not something that we have answers for. 48 | 49 | An identity is the sum of its verifiable claims or other attestations. So, can we trust the signatures on these attestations to be valid? 50 | 51 | There's probably a middle step between enterprise and peer-to-peer attestations where oracles help to bootstrap this. 52 | 53 | ## What Does Self-Sovereign Identity Really Mean? (Christopher Allen) 54 | 55 | Earlier this year, Christopher put together a paper on Self-Sovereign Identity. It has been well attempted, including at UN, where a number of ambassadors used it as a term. Now it's time to turn that into a conversation. 56 | 57 | Are there missing principles? Should the principles be categorized? 58 | 59 | We'd like to create a _pledge_ that lets people agree that they're creating their self-sovereign identity system according to their principles. 60 | 61 | **Link:** [Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html) 62 | [link: Path to Self Sovereign Identity article] 63 | 64 | ## When Does Self-Sovereign Identity Start and End? (Jonathan Endersby) 65 | 66 | How do you create identity for children who can't decide for themselves? On the opposite side of the spectrum, what about adults who can no longer control their self-sovereign identity due to accident, etc.? 67 | 68 | The question is essentially _when do you step in as a guardian?_ And _what rules do you need to follow?_ This requires _digital guardians_ who look after other peoples' identities. (There are technical ways to do this, such as Shamir secret sharing, but we need something that the rest of the world can use.) 69 | 70 | Another question is, _are current models of guardians and godparents and such translateable into the digital world?_ 71 | 72 | ## Song of Ashok (Christopher Allen) 73 | 74 | This is a story. 75 | 76 | A child gets separated from his parents during some natural disaster. To prove his identity, the child can go to a bank and enter a private room and sing a certain song. Then he gets access to certain funds and hire people to find his parents. 77 | 78 | How do we do this? 79 | 80 | BIP38 + BIP39 encode information in words, but we've expanded this a bit with some other proofs of concept. 81 | 82 | One proof of concept: Christopher and Chris V. came up with a new set of words that _are in iambic pentameter_, so are easier to remember. 83 | 84 | Another proof of concept: They encoded identity proof into poem instead, but not (yet) a rhyming one. 85 | 86 | ## Social Authentication (Glenn Willen) 87 | 88 | The basic idea is: authentication based on who you know, or better who knows you. 89 | 90 | This is already done at Facebook through Trusted Contacts. 91 | 92 | Technically, Shamir secret-sharing scheming allows this type of key recovery. 93 | 94 | You want these social authentication to be stronger than your personal key, in case your personal key is compromised. 95 | 96 | You need to be able to detect loss of recovery key shards very quickly, else they decay over time. 97 | 98 | May need to tie this to a trust system, so that you can penalize people if they verify a false identity. 99 | 100 | ## Will Smart Contracts Drive Civilization Over a Cliff (Kaliya Young) 101 | 102 | The deeper question is, _what checks and balances are needed in these sorts of systems?_ 103 | 104 | What do you do when natural disasters _should_ cause delays in smart contracts, or when a stock market crash _should_ cause the stock market to pause? How do smart contract account for this? 105 | 106 | How do we _upgrade_ contracts 107 | 108 | It's how _Courts of Equity_ emerged for legal system. 109 | 110 | This is a conversation. 111 | 112 | ## Identity in the Eye of Beholder (Joe Andrieu) 113 | 114 | Identity is _correlation_. It's fluid, it evolves. Data can change. What's right today can be wrong tomorrow. It's a process, not an object. So identity shouldn't be defined by data. 115 | 116 | We need to talk about identity beyond the bits, and this allows it. 117 | 118 | **Link:** [Clearer Identity through Correlation](https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/final-documents/identity-crisis.pdf) 119 | 120 | ## Time Stamps (Peter Todd, Wayne Vaughan) 121 | 122 | Open Timestamps, Chainpoint. 123 | 124 | Wayne's Chainpoint verifies the content and timestamp of data. It's a proof protocol. 125 | 126 | Peter's Open Timestamps makes proof of data creation easy. 127 | 128 | Part of the problem is that you need to know when signatures were created; you need to be able to prove that data was created at a certain time. So then you can know if something was created before or after a compromise, for example. 129 | 130 | Timestamps are _additive_ security. 131 | 132 | _One-minute round._ 133 | 134 | ## Slepaks' Triangle (Greg Slepak) 135 | 136 | Attempts to solve long-running debate of what the blocksize should be. 137 | 138 | At its base, it says a system can only have two of three attributes: decentralized, consensus, mainstream. 139 | 140 | ## Anonymous Credential for Blockchain-Based Identities (Dmitry KHOVRATOVICH) 141 | 142 | Legders are useful, but the question of privacy is missing. 143 | 144 | Anonymous Credentials can solve this problem. 145 | 146 | ## Standard Protocols for Accessing Blockchains (Manu Sporny) 147 | 148 | It would be neat to recreate HTTP for blockchains. We just need to figure out what they're speaking. 149 | 150 | ## Identity-Standard Data Models (Manu Sporny) 151 | 152 | This is verifiable claims. 153 | 154 | ## How Do We Ensure an ID is Unique? (Jonathan Endersby) 155 | 156 | This will eventually happen, and the question is if it's solvable. 157 | 158 | ## Self-Sovereign Value Chain (Robert) 159 | 160 | Self-sovereign identity has no value until you add endorsements and have usage. We need a taxonomy for a value-chain to allow all of this. 161 | 162 | ## Portable Reputation Toolkit (Noah) 163 | 164 | Want to put together a proof of concept in code for a portable reputation toolkit. 165 | 166 | ## Decentralized Trust Management Network (Pavel) 167 | ## Financial Trust without Centralized Parties or Ledgers (Pavel) 168 | 169 | Ideal money is trust, because you can't steal it. 170 | 171 | Your balance could be total number of trust lines that all of your friends or creditors give to you, and then you can use that to pay others, transfering through a network of friends (or nodes). 172 | 173 | So how do you build this? You _could_ use a centralized entity. Otherwise, you can use blockchain, but you can't scale that. So what do you do instead? 174 | 175 | You create a web of connected nodes, a consensus system. You issue IOUs and reach a consensus with a group of friends. 176 | 177 | ## Identity Containers (Daniel Buchner) 178 | 179 | Have container signed with your DID. Going to build a reference implementation out in the next few months. And possibly roll it out to a billion people! 180 | -------------------------------------------------------------------------------- /draft-documents/reputation-toolkit.md: -------------------------------------------------------------------------------- 1 | # Portable Reputation Toolkit Use Cases 2 | 3 | **By Christopher Allen, Tim Daubenschütz, Manu Sporny, Noah Thorp, Harlan Wood, Glenn Willen, Alessandro Voto** 4 | 5 | *This paper was created as part of a collaborative working group at the Rebooting The Web of Trust DesignShop. The proof of concept technical implementation is **[here](https://github.com/WebOfTrustInfo/portable-reputation-toolkit)**.* 6 | 7 | ## The Goal: Decentralized Verification 8 | 9 | In social networks and markets and on value chains we have a hard time determining what is true and who to trust. Verified information is critical for the functioning of a networked democratic society. The portable reputation toolkit is intended to address these issues by using cryptographic signatures and decentralized technology such as decentralized identifiers, blockchain, and distributed data storage. 10 | 11 | This white paper outlines several concrete use cases. These include decentralized fact checking for political journalism, decentralized Fair Trade supply chain certification, and decentralized skill certification without a centralized institution. 12 | 13 | The process for each of these use cases is to: 14 | 15 | 1. Create assertions that can be traced back to individual user identities through signed claims 16 | 17 | 2. Refute or support assertions by referencing separate evidence 18 | 19 | 3. Run a search for verifiable information about an assertion and filter based on the trust of the sources 20 | 21 | 4. Determine if an assertion is likely to be true based on evidence, evaluations, and trust in those making the claims 22 | 23 | Although perfect knowledge is fictional, we can decrease the costs of verification and increase the costs of lying. 24 | 25 | ## Use Case: Decentralized Social Media Fact Checking For Political Campaign Journalism 26 | 27 | **Goal:** Bob wants to know if Alice’s assertion about politician Charles is backed up by reliable evidence. 28 | 29 | **Roles:** Assertion Maker, Evidence Provider, Reader, Journalist 30 | 31 | **Claim Types:** Assertion, Evidence, Evaluation 32 | 33 | Alice the **Assertion Maker** posts the _assertion_ in her social media timeline that the politician Charles is responsible for violently intimidating journalists that are writing unfavorable articles. As _evidence_ to support her _evaluation_ she includes links to **Evidence Provider** Juan’s videos of police officers physically harassing journalists at several political rallies and to leaked emails that are relevant. 34 | 35 | Juan is a trusted news source who is has been certified for his skills using a Decentralized Certification (see below). The videos are signed by Juan’s private key associated with a distributed identifier (DID). **Reader** Bob can now more accurately _evaluate_ if the _assertion_ is true based on Juan’s _evidence_. 36 | 37 | **Journalist** Elon searches for many _assertions_, _evaluations_, and signed _evidence_ sources about politician Charles. Elon writes an article detailing the abuse of power by politician Charles. The article carefully references the _assertions_ that have been verified through decentralized methods. 38 | 39 | ## Use Case: Decentralized Skill Certification For A Security Reviewer 40 | 41 | **Goal:** Bob wants to evaluate if he should hire Alice for a cryptographic security code review. 42 | 43 | **Roles:** Employer, Worker, Skill Evaluator 44 | 45 | **Claim Types:** Assertion, Evaluation, Evidence 46 | 47 | **Worker** Alice is a security reviewer in the crypto community. **Employer** Bob wants to know if he should hire Alice for a code review of cryptography related code. Alice makes the _assertion_ that she is "competent at crypto code reviews". She signs the _assertion_ with her DID at a specific time. **Skill Evaluator** Charlie _evaluates_ code and pen test reports by Alice as well as a video review of a former collaborator. He records his _evaluation_ with references to the _evidence_ affirming Alice’s proposition that she is “competent at crypto reviews”. Bob reviews Charlie’s _evaluation_ and hires Alice for a crypto review. 48 | 49 | ## Use Case: Decentralized Fair Trade Supply Chain Certification 50 | 51 | **Goal:** A Shopper wants to know if her coffee is Fair Trade based on Evidence provided by a supply chain of multiple companies and individuals 52 | 53 | **Roles:** Product Owner, Supplier, Worker, Retailer, Shopper 54 | 55 | **Claim Types:** Assertion, Evaluation, Evidence 56 | 57 | The **Product Owner** for a coffee company creates a distributed identifier (DID) and a corresponding private key. The **Product Owner** publishes an _assertion_ that their Fair Blend coffee product is Fair Trade and signs it with their DID private key. The _assertion_ is timestamped and made available to **Suppliers** and **Workers**. Initially there is no _evidence_ to evaluate if the _assertion_ is true or false, so it is considered "Not Verified". 58 | 59 | The **Product Owner** purchases coffee from a **Supplier**. The **Supplier** posts _evidence_ of their transaction and signs it with their DID. This _evidence_ is initially independent of any _assertion_. The **Supplier** then posts an _evaluation_ that supports the **Product Owner's** _Fair Trade assertion_. 60 | 61 | The **Product Owner** places a physical tag on all products from this batch of coffee, linking the physical good to the _Fair Trade assertion_. This could be a smart tag, as Chronicled has done for counterfeit sneaker checking on a blockchain. 62 | 63 | The **Retailer** buys the Fair Blend Coffee from the **Product Owner**. The **Retailer** has a standard filter for _Fair Trade assertions_. A list of trusted keys is maintained, with weightings for each source. An algorithm crunches through the relevant _evaluations_ and _evidence_ to determine a Rating for the _assertion_ that the Fair Blend product is Fair Trade. The _assertion_ Rating can evaluate to "Verified", “Not Verified”, or “Contested”. At the time the **Retailer** purchase the coffee for their store the _Fair Trade assertion_ evaluates to “Verified”. 64 | 65 | Several **Workers** challenge the **Fair Trade Assertion**. They post _evidence_ on their employment and wages and documentation of a market price snapshot from a trusted ticker oracle. They post an _evaluation_ that compares their personal information to the _Fair Trade assertion’s_ timestamp to show the price was under market rates. They use their DID to sign their _evaluation_ of the _evidence_ that challenges the _Fair Trade assertion_. 66 | 67 | In the retail store, a **Shopper** waves their phone over the NFC tag, which brings up their Fair Trade Association filter app. A filter in their app determines a challenge to the _Fair Trade assertion_ came from the DIDs of workers who participated in producing Fair Blend coffee. The app presents a "Contested" claim message, noting both the **Supplier's** supporting _evaluation_, the **Worker's** challenge and the associated _evidence_. The shopper chooses another filter to get a second opinion. They decide to buy a different coffee that has a “Verified” _Fair Trade assertion_ from a different **Product Owner**. 68 | 69 | At the register the **Shopper** complains to the **Retailer** that the Fair Blend coffee is no longer Fair Trade. The **Shopper** contacts the **Product Owner** and puts pressure to remediate the payment issue with the **Workers**. Once remediated the **Product Owner** and **Workers** provide new _evidence_ and _evaluations_ of the _Fair Trade assertion_. 70 | 71 | The **Shopper** returns to the **Retailer** and waves their phone over the NFC tag, which brings up their Fair Trade Association filter app. The app presents a "Verifed" rating for the _Fair Trade assertion_. The **Shopper** purchases the Fair Blend coffee, confident that it has been produced ethically. 72 | 73 | ## General Use Case 74 | 75 | A user creates a **Distributed Identifier** (DID). They get an accompanying private key that they use to sign assertions. 76 | 77 | A user makes an **Assertion** using a JSON-LD claim format. It is signed with their DID and timestamped with a decentralized timestamping service like Open Timestamps. The assertion includes the submitter’s DID and a target identifier that the the assertion is about. Later claims can evaluate or invalidate the statements by pointing to the assertion. 78 | 79 | Users publish **Evidence** JSON-LD claims. Evidence is signed by a user’s DID. Evidence JSON-LD claims link to media, with a unique identifier. The evidence doesn’t have to be related to any assertion initially. Evidence can be related to any assertion at any time using an evaluation. 80 | 81 | Any user can challenge or support an earlier assertion with an **Evaluation**. An evaluation references an assertion and evidence. It supports or refutes the assertion. This evaluation will always point to an assertion, and have a true/false or 0-1 float value judging its "truthfulness". Evaluations are signed by the creators DID and timestamped. 82 | 83 | The end user validates the truthfulness of an assertion by querying evaluations and evidence associated with it using an algorithm called a **Filter**. Users can develop a list of trusted evaluators for themselves, import a list from others, or use a filter template that includes evaluator trust parameters and weightings. The filter factors in the evidence, the evaluations, and the trust in the reputation of each of these to determine the truth or falsehood of the assertion. The user can apply multiple filters and audit the Filter to gain multiple perspectives. 84 | 85 | ## Appendix: Example Workflow For Decentralized Certification 86 | 87 | ![First Image](/supporting-files/rtk/image_0.png?raw=true) 88 | ![Second Image](/supporting-files/rtk/image_1.png?raw=true) 89 | ![Third Image](/supporting-files/rtk/image_2.png?raw=true) 90 | ![Fourth Image](/supporting-files/rtk/image_3.png?raw=true) 91 | 92 | 93 | -------------------------------------------------------------------------------- /topics-and-advance-readings/JXD-Examples.md: -------------------------------------------------------------------------------- 1 | # JXD Examples 2 | 3 | By Markus Sabadello, Danube Tech (https://danubetech.com) 4 | 5 | INTRODUCTION 6 | ============ 7 | 8 | JXD is a JSON-based serialization format for the XDI graph model, designed to combine the simplicity of JSON with the semantic richness of XDI. 9 | 10 | An XDI graph can sometimes be serialized to JXD in different ways (some more verbose, some more compact), but deserializing a JXD back to XDI always results in the same original XDI graph. Every XDI graph can be serialized to JXD, and every JXD document can be deserialized to a valid XDI graph. 11 | 12 | An XDI graph is built from XDI context nodes, which form a semantic tree. In JXD, an XDI context node is represented as a JSON object, with an **@id** JSON object key set to the XDI context node’s address. 13 | 14 | A single XDI context node is described as a single JSON object: 15 | 16 | //=markus 17 | 18 | { 19 | "@id": "=markus" 20 | } 21 | 22 | Multiple XDI context nodes are described as a single top-level JSON array, consisting of multiple JSON objects: 23 | 24 | //=markus 25 | //=drummond 26 | 27 | [ 28 | { "@id": "=markus" }, 29 | { "@id": "=drummond" } 30 | ] 31 | 32 | The next few pages explain how to describe the contents of XDI context nodes in more detail, including XDI literals, XDI relations, nested XDI context nodes, and XDI inner roots. For describing them, we can use a JXD mapping block (using an **@xdi** JSON object key) that maps simple JSON object keys to XDI concepts. The JXD mapping block may be part of the JXD document, or it may be referenced at an external location. The part of the JXD document that is not the JXD mapping block is called the JXD body. 33 | 34 | ATTRIBUTES AND LITERALS 35 | ======================= 36 | 37 | An XDI attribute and XDI literal are described using a JSON object key with a value that is the value of the XDI literal. In the JXD mapping block, a simple JSON object key may be defined that maps the JSON object key to a description of the XDI attribute and literal. 38 | 39 | **EXAMPLE** 40 | 41 | =markus<#name>/&/"Markus Sabadello" 42 | =markus<#email>/&/"markus@danubetech.com" 43 | 44 | { 45 | "@id": "=markus", 46 | "<#name>": "Markus Sabadello", 47 | "<#email>": "markus@danubetech.com" 48 | } 49 | 50 | **OR:** (describing the XDI attributes in the JXD mapping block) 51 | 52 | { 53 | "@xdi": { 54 | "name": "<#name>", 55 | "email": "<#email>" 56 | }, 57 | "@id": "=markus", 58 | "name": "Markus Sabadello", 59 | "email": "markus@danubetech.com" 60 | } 61 | 62 | **OR:** (describing the XDI attributes in the JXD mapping block in a more verbose way) 63 | 64 | { 65 | "@xdi": { 66 | "name": { "@id": "<#name>" }, 67 | "email": { "@id": "<#email>" } 68 | }, 69 | "@id": "=markus", 70 | "name": "Markus Sabadello", 71 | "email": "markus@danubetech.com" 72 | } 73 | 74 | RELATIONS 75 | ========= 76 | 77 | One or more XDI relations are described using a JSON object key with a value that is a JSON array containing the target address(es) of the XDI relation(s). In the JXD mapping block, a simple JSON object key may be defined that maps the JSON object key to a description of the XDI relation. The target address(es) of the XDI relation(s) must have a **@type** declaration set to **@id**. This declaration may be done either in the JXD body or in the JXD mapping block. 78 | 79 | **EXAMPLE** 80 | 81 | =markus/#friend/=drummond 82 | 83 | { 84 | "@id": "=markus", 85 | "#friend": [ { "@id": "=drummond", "@type": "@id" } ] 86 | } 87 | 88 | **OR:** (describing the XDI relation in the JXD mapping block) 89 | 90 | { 91 | "@xdi": { 92 | "friend": { "@id": "#friend", "@type": "@id" } 93 | }, 94 | "@id": "=markus", 95 | "friend": [ "=drummond" ] 96 | } 97 | 98 | **OR:** (also describing the target address of the XDI relation in the JXD mapping block) 99 | 100 | { 101 | "@xdi": { 102 | "friend": { "@id": "#friend", "@type": "@id" }, 103 | "drummond": { "@id": "=drummond", "@type": "@id" } 104 | }, 105 | "@id": "=markus", 106 | "friend": [ "drummond" ] 107 | } 108 | 109 | NESTED CONTEXT NODES 110 | ==================== 111 | 112 | A nested XDI context node is described using a JSON object key with a value that is a JSON object containing the contents of the nested XDI context node, following the rules in this document recursively. In the JXD mapping block, a simple JSON object key may be defined that maps the JSON object key to a description of the nested XDI context node. The nested XDI context node must have a **@type** declaration set to **@id**. This declaration may be done either in the JXD body or in the JXD mapping block. If an XDI context node’s only purpose is to contain nested XDI context nodes, then multiple XDI context nodes can be “collapsed” and therefore some JSON objects can be “omitted”. This “collapse” may be done either in the JXD body or in the JXD mapping block. 113 | 114 | **EXAMPLE** 115 | 116 | +danubetech=markus<#work><#email>/&/"markus@danubetech.com" 117 | 118 | { 119 | "@xdi": { 120 | "email": "<#email>" 121 | }, 122 | "@id": "+danubetech", 123 | "=markus": { 124 | "@type": "@id", 125 | "<#work>": { 126 | "@type": "@id", 127 | "email": "markus@danubetech.com" 128 | } 129 | } 130 | } 131 | 132 | **OR:** (describing a nested XDI context node in the JXD mapping block) 133 | 134 | { 135 | "@xdi": { 136 | "work": { "@id": "<#work>", "@type": "@id" }, 137 | "email": "<#email>" 138 | }, 139 | "@id": "+danubetech", 140 | "=markus": { 141 | "@type": "@id", 142 | "work": { 143 | "email": "markus@danubetech.com" 144 | } 145 | } 146 | } 147 | 148 | **OR:** (describing an additional nested XDI context node in the JXD mapping block) 149 | 150 | { 151 | "@xdi": { 152 | "=markus": { "@type": "@id" }, 153 | "work": { "@id": "<#work>", "@type": "@id" }, 154 | "email": "<#email>" 155 | }, 156 | "@id": "+danubetech", 157 | "=markus": { 158 | "work": { 159 | "email": "markus@danubetech.com" 160 | } 161 | } 162 | } 163 | 164 | **OR:** (collapsing two XDI context nodes in the JXD body) 165 | 166 | { 167 | "@xdi": { 168 | "work": { "@id": "<#work>", "@type": "@id" }, 169 | "email": "<#email>" 170 | }, 171 | "@id": "+danubetech=markus", 172 | "work": { 173 | "email": "markus@danubetech.com" 174 | } 175 | } 176 | 177 | **OR:** (collapsing two XDI context nodes in the JXD mapping block) 178 | 179 | { 180 | "@xdi": { 181 | "=markus": { "@type": "@id" }, 182 | "workemail": "<#work><#email>" 183 | }, 184 | "@id": "+danubetech", 185 | "=markus": { 186 | "workemail": "markus@danubetech.com" 187 | } 188 | } 189 | 190 | **OR:** (collapsing XDI context nodes both in the JXD body and in the JXD mapping block) 191 | 192 | { 193 | "@xdi": { 194 | "workemail": "<#work><#email>" 195 | }, 196 | "@id": "+danubetech=markus", 197 | "workemail": "markus@danubetech.com" 198 | } 199 | 200 | INNER ROOTS 201 | =========== 202 | 203 | An XDI inner root is described using a JSON object key with a value that is a JSON object containing the contents of the XDI inner root, following the rules in this document recursively. In the JXD mapping block, a simple JSON object key may be defined that maps the JSON object key to a description of the XDI inner root. The XDI inner root must have a **@type** declaration set to **@graph**. This declaration may be done either in the JXD body or in the JXD mapping block. 204 | 205 | **EXAMPLE 1 (MESSAGE)** 206 | 207 | (=markus[$msg]*!:uuid:1234$do/$set)=markus<#name>/&/"Markus Sabadello" 208 | (=markus[$msg]*!:uuid:1234$do/$set)=markus<#email>/&/"markus@danubetech.com" 209 | (=markus[$msg]*!:uuid:1234$do/$set)=markus/#friend/=drummond 210 | 211 | { 212 | "@xdi": { 213 | "name": "<#name>", 214 | "email": "<#email>", 215 | "friend": { "@id": "#friend", "@type": "@id" }, 216 | "set": { "@id": "$set", "@type": "@graph" } 217 | }, 218 | "@id": "=markus[$msg]!:uuid:1234$do", 219 | "set": { 220 | "=markus": { 221 | "@type": "@id", 222 | "name": "Markus Sabadello", 223 | "email": "markus@danubetech.com", 224 | "friend": [ "=drummond" ] 225 | } 226 | } 227 | } 228 | 229 | **EXAMPLE 2 (LINK CONTRACT)** 230 | 231 | (=markus/=drummond)$do/$get/=markus<#email> 232 | (=markus/=drummond)($do$if$and/$true){$from}/$is/=drummond 233 | (=markus/=drummond)($do$if$and/$true){$msg}<$sig><$valid>/&/true 234 | 235 | { 236 | "@xdi": { 237 | "do": { "@id": "$do", "@type": "@id" }, 238 | "if": { "@id": "$if", "@type": "@id" }, 239 | "and": { "@id": "$and", "@type": "@id" }, 240 | "or": { "@id": "$or", "@type": "@id" }, 241 | "true": { "@id": "$true", "@type": "@graph" }, 242 | "false": { "@id": "$false", "@type": "@graph" }, 243 | "get": { "@id": "$get", "@type": "@id" }, 244 | "from": { "@id": "{$from}", "@type": "@id" }, 245 | "msg": { "@id": "{$msg}", "@type": "@id" }, 246 | "is": { "@id": "$is", "@type": "@id" }, 247 | "sigvalid": { "@id": "<$sig><$valid>" } 248 | }, 249 | "@id": "=markus", 250 | "=drummond": { 251 | "@type": "@graph", 252 | "do": { 253 | "get": [ "=markus<#email>" ], 254 | "if": { 255 | "and": { 256 | "true": { 257 | "from": { 258 | "is": [ "=drummond" ] 259 | }, 260 | "msg": { 261 | "sigvalid": true 262 | } 263 | } 264 | } 265 | } 266 | } 267 | } 268 | } 269 | 270 | ACKNOWLEDGEMENTS 271 | ================ 272 | 273 | Thank you to the JSON-LD spec editors and contributors for their impressive work on a simple JSON-based serialization of RDF graphs. Thank you to the OASIS XDI Technical Committee for leadership and valuable feedback on the JXD (formerly JSON-XD) format. Thank you to Evernym for supporting JXD development work. 274 | -------------------------------------------------------------------------------- /topics-and-advance-readings/Sovereign-Identity-Model-for-Digital-Ecologies.md: -------------------------------------------------------------------------------- 1 | ## Sovereign Identity Model for Digital Ecologies 2 | 3 | By Patrick Deegan, PhD 4 | DAC Technologies 5 | 6 | *Submitted to the 3rd Rebooting the Web of Trust Technical Workshop as a discussion paper.* 7 | 8 | October 2016 9 | 10 | ### OUTLINE 11 | 12 | Self-Sovereign Identity 13 | * Definition of a next-generation digital identity stack 14 | * Most pressing issue: Standardization of each interface between layers (e.g., emulate OSI model) 15 | * Proposal for some of those layers: RootID, CoreID, and Personas 16 | 17 | ### BACKGROUND STATEMENT 18 | 19 | The world is becoming increasingly interdependent and digital for the individual, the corporation and the nation state. Autonomous robots and Internet of Things devices may soon be as commonplace as PCs and smartphones are today. Robots are machines that can take measurements, plan, and take actions in order to bring about desired outcomes. These systems are widely used for the automation of a manufacturing and supply chain, where physical goods and virtual assets are controlled via computational and algorithmic governance mechanisms. However, there is significant risk when these systems are deployed in real-world, internet connected use cases. In particular, an autonomous robot with many "users" must address many of the same interactive flows that humans experience when transacting internet based entities: authentication, authorization, claim verification, etc. In both cases, these systems may have to exhibit transparency, consistent offline behavior, high assurance, high availability, self-deployment, and self-healing, for example. 20 | 21 | This transition to a ubiquity of devices that can sense, think, and act on their own will enable many new opportunities for peer-to-peer transactions. This is especially the case for collaborative, mobile, dexterous and social robots that are situated in human-centric environments and that are serving to bridge interactions between real and virtual worlds. Across the spectrum, the ownership, control and security of one’s personal and legal identity and digital information are becoming aspects of paramount importance. The challenge ahead is to design and implement technological systems that can support an empowered individual and their digital equivalent. In doing so, we may take an ecological approach while implementing global scale permissioned ledger and private network deployments. The following is meant to be a proposal for a schema that may fulfill some of these criteria. 22 | 23 | In order to meet the needs of economies of the future that strive for inclusivity, accountability, and long-term sustainability, we may view the individual and the group as one and the same (e.g., system’s engineering model of ‘holon’ and ‘holarchy’). According to Wikipedia, a holon is an “autonomous, self-reliant units that possess a degree of independence and handle contingencies without asking higher authorities for instructions” [https://en.wikipedia.org/wiki/Holon_(philosophy)]. This may be an appropriate model, since in many cases groups of digital actors will form “organically” and bootstrap a localized form of governance, while still being situated and embodied within a larger social, legal, or business context. Moreover, this model calls for online groups to be self-governed and consent to share their information, collaborate and take collective action in order to safeguard the welfare of their e-citizens. The idea is that each node is responsible for setting consensus and enforcing containment so that order and value can emerge without introducing systemic risk or resulting in unintentional or collateral damage. With so much at stake, it is essential that we ensure an appropriate level of trust in order for these new distributed markets and platforms to function efficiently and ultimately deliver value to consumers. It is proposed that Self-Sovereign Identity combined with the notion of a holonic network topology (i.e., identity-centric) may lead us to a scalable and trustworthy digital asset exchange system capable of powering a global scale information economy revolution. 24 | 25 | While this future has much promise to improve quality of life, care must be taken when computational/cognitive Artificial Intelligence (AI) and digital services are connected through new virtual and augmented interfaces. This is especially the case when systems such as autonomous vehicles are allowed to impart forces on the real world (i.e., connect to feedback control systems that rely on a network of distributed sensors for truth and express their will through powerful actuators that reside in human environments). Even cybersecurity experts are encouraging a more device and identity centric network topology to mitigate ongoing threats. Therefore, it appears that a next-generation Identity Layer for the internet will be just as central for machines (on their continual evolution to sentience, IMO) as it will be for humans. In particular, Self-Sovereign Identity Systems (SIS) research seems to hold the most promise to mediate the risk of entrusting these devices with critical infrastructure such as transportation or caring for the elderly. 26 | 27 | ### TOPICS OF INTEREST 28 | 29 | A foundation for solving the problem of trust on the internet should include these pillars: 30 | 31 | **Self-Sovereign Identity** 32 | 33 | (Definition) A secure and distributed form of digital legal identity that is portable and provides the means for independently verifiable claims (including: remote attestation, proof of ownership/attribution, and continuous authentication) 34 | (Perspective) I control my identity and consent to what information is shared, with whom, and for what purpose. I trust that I’m interacting with the correct entities and we are all who we say we are 35 | 36 | **Digital Assets with Autonomy** 37 | 38 | (Definition) The protocols and standards that define a container for the principled management and exchange of information and physical assets. 39 | (Perspective) I control my data – its provenance is known and its existence and integrity is cryptographically secured. I control my information and digital assets, even after they have left my personal network (e.g., beyond the perimeter of my private cloud and devices). I am ensured that I control the definitive copy, empowering me to maximize my data’s value and ensuring that I am safe when interacting with powerful machines. 40 | 41 | **Trust Frameworks and Algorithmic Governance** 42 | 43 | (Definition) A system for deploying and maintaining independently enforceable computational policies for the management (i.e., govern the state transitions) of immutable records, digital supply chain services, and robust, available, and trustworthy data stores. 44 | (Perspective) I know that an independent mechanism ensures the system cannot be exploited for self-interest. I rely on transparent and automatically enforced rules to ensure counterparty rights and obligations are met. 45 | 46 | ### A MODEL FOR AN IDENTITY STACK 47 | 48 | In the real world we have seen rapid shifts in nearly every domain from face-to-face interactions to network mediated transactions that may occur over vast distances, often obfuscating the stakeholders from each other. This introduces governance issues around trust, truth and accountability. Arguably, the technology now exists to create systems that impart effective governance through every layer of the system (i.e., the stack of hardware and software technologies). It turns out that myriad social or personal phenomena are readily measured via the "smart phones" that most of us in the developed nations now carry - inseparably throughout our day. Moreover, vast amounts of data have already been collected and yet much of the potential is still unmet: managed in disparate silos or is just not readily accessible or computable due to any number of reasons or forms that it may take. We are deploying sensors that can record nearly every nuance of any real-world situation at a very rapid pace. Closing the loop on these systems will present the opportunity to automate the coordination of vast resources and bring about desired outcomes. Many use cases will benefit from these advances, however when these systems are able to physically manipulate the real-world, we need to be absolutely certain these advances cannot be abused. Fortunately, recent work is proving that we can enable anonymous transactions while ensuring that counterparties are held accountable for their agreed-to rights and obligations. 49 | 50 | Seemingly innocuous, are countless instances where marketing and advertising has been aimed to manipulate our preferences and effect our purchasing behavior. So it brings us to ask the questions around trust and risk: 51 | * Why should we trust technology when we already know it is being used to fundamentally limit our free will and autonomy? 52 | * Who guards the guardians themselves? Who watches the watchmen? 53 | 54 | Thus, when designing next generation identity systems, at the core of meeting the rights and obligations required of such systems, is the ability to engender the necessary trust to ensure that all counter-parties are fairly served and risk is sufficiently mitigated. Standards and protocols are needed that can provide the counter-parties with certain assurances that information will be used only in the manner and with the effect that is lawfully appropriate in each context. 55 | 56 | In consideration of the following diagram, some use case examples are presented: 57 | 58 | * AAUIW to prove that my identifier is valid and I consent to share or be known as any of my chosen digital Identities (Personas with attributes) in a particular context. The Persona (with a one-way binding to the CoreID) can serve to provide a publicly verifiable record of compliance with numerous governance frameworks, processes, etc. The data associated with these Personas should be governed in a similar manner. 59 | * AAUIW to state that I am the only entity that has been associated with and has been in control of a persistent, unique, global identifier (RootID) 60 | * AAUIW to use my mobile device to collect GPS points and execute an algorithmic process to determine my home and work addresses to a verifiable performance metric (e.g., truthiness). I will then use them to generate attributes for my Personas, that can be securely escrowed in order to self-attest compliance with legal identity requirements. 61 | * AAUIW to provide my own re-identifying information to meet standards that will allow nation states and corporations to attest to various attributes of my CoreID, such as citizenship. 62 | * AAUIW to control my RootID and be protected when I need a replacement (e.g, due to temporary loss of control). This RootID must not leak any information about me (re-identifying information) when an attestation of its validity and veracity is expressed (an independently verifiable claim) 63 | -------------------------------------------------------------------------------- /draft-documents/hubs.md: -------------------------------------------------------------------------------- 1 | # Hubs 2 | 3 | ## by Daniel Buchner, Wayne Vaughan, and Ryan Shea 4 | 5 | Hubs let you securely store and share data. A Hub is a datastore containing semantic data objects at well-known locations. Each object in a Hub is signed by an identity and accessible via a globally recognized API format that explicitly maps to semantic data objects. Hubs are addressable via unique identifiers maintained in a global namespace. 6 | 7 | ## Single Address for Multiple Hub Instances 8 | 9 | A single entity may have one or more instances of a Hub, all of which are addressable via a URI-routing mechanism linked to the entity’s identifier. Hub instances sync state changes, ensuring the owner can access data and attestations from anywhere, even when offline. 10 | 11 | ## Syncing Data to Multiple Hubs 12 | 13 | Hub instances must sync data without requiring master-slave relationships or forcing a single implementation for storage or application logic. This requires a shared replication protocol for broadcasting and resolving changes. [CouchDB](http://docs.couchdb.org/en/2.0.0/replication/protocol.html), an open source Apache project, will be the data-syncing protocol Hubs must implement. It features an eventually consistent, master-master replication protocol that can be decoupled from the default storage layer provided by CouchDB. 14 | 15 | ## Well-Known URIs 16 | 17 | Existing web servers need to interact with Hubs. We are using the IETF convention for globally defined resources that predictably reside at well-known locations as detailed in [RFC 5785 well-known URIs][13f07ee0] and the [well-known URI directory][6cc282d2]. Hubs are accessible via the path: /.well-known/identity/:id, wherein the last segment of the path is the target ID for the identity you wish to interact with. 18 | 19 | ## API Routes 20 | 21 | Each Hub has a set of top-level API routes: 22 | 23 | `/.well-known/identity/:id/`*`profile`* ➜ The owning entity's primary descriptor object (schema agnostic). 24 | 25 | `/.well-known/identity/:id/`*`permissions`* ➜ The access control JSON document 26 | 27 | `/.well-known/identity/:id/`*`messages`* ➜ A known endpoint for the relay of messages/actions to the identity owner 28 | 29 | `/.well-known/identity/:id/`*`stores`* ➜ Scoped storage space for user-permitted external entities 30 | 31 | `/.well-known/identity/:id/`*`collections/:context`* ➜ The owning entity's identity collections (access limited) 32 | 33 | #### Hub Profile Objects 34 | 35 | Each Hub has a `profile` object that describes the owning entity. The profile object should use the format of the schema object that best represents the entity. Here is an example of using the Schema.org `Person` schema to express that a hub belongs to a person: 36 | 37 | ```json 38 | { 39 | "@context": "http://schema.org", 40 | "@type": "Person", 41 | "name": "Daniel Buchner", 42 | "description": "Working on decentralized identity at Microsoft", 43 | "website": [ 44 | { 45 | "@type": "WebSite", 46 | "url": "http://www.backalleycoder.com/" 47 | } 48 | ], 49 | "address": { 50 | "@type": "PostalAddress", 51 | "addressLocality": "Los Gatos, CA" 52 | } 53 | } 54 | ``` 55 | 56 | #### Permissions 57 | 58 | Agents are external parties that can access and modify Hub data. Hub owners can set permissions in a ACL JSON document, which you can learn more about via the ACL documentation and [examples](https://github.com/decentralized-identity/acl/blob/master/examples/basic.json). This access control document designates: 59 | 60 | - What factors can be used for authentication and modification of Hub data 61 | - What data Agents have access to 62 | - Which Agents are provided with a `store` 63 | 64 | #### Messages 65 | 66 | The `messages` open endpoint receives objects signed by other identities. Messages are not constrained to the simple exchange of human-to-human communications. Rather, they are intended to be a singular, known endpoint where identities can transact all manner of messaging, notifications, and prompts for action. 67 | 68 | Here is a list of examples to better understand the range of use-cases this endpoint is intended to support: 69 | 70 | - Human user contacts another with a textual messages 71 | - Service prompts a human to sign a document 72 | - IoT device sends a notification to a human user about its state 73 | 74 | The endpoint location for message objects shall be: 75 | 76 | `/.well-known/identity/:id/messages/` 77 | 78 | The encapsulating format for message payloads shall be: 79 | 80 | [http://schema.org/Message](http://schema.org/Message) 81 | 82 | If the intent of your message is to prompt the receiving Hub to perform a certain semantic activity, you can pass an [Action](http://schema.org/Action) object via the Message's `potentialAction` property. 83 | 84 | #### Stores 85 | 86 | Stores are collections of identity-scoped data storage. Stores are addressable via the `/stores` top-level path, and keyed on the entity's decentralized identifier. Here's an example of the path format: 87 | 88 | `/.well-known/identity/:id/stores/`*`ENTITY_ID`* 89 | 90 | The data shall be a JSON object and should be limited in size, with the option to expand the storage limit based on user or provider discretion. Stores are not unlike a user-sovereign entity-scoped version of the W3C DOM's origin-scoped `window.localStorage` API. 91 | 92 | #### Collections 93 | 94 | Collections provide a known path for accessing standardized, semantic objects across all hubs, in way that asserts as little opinion as possible. The full scope of an identity's data is accessible via the following path 95 | 96 | `/.well-known/identity/:id/collections/:context`, wherein the path structure is a 1:1 mirror of the schema context declared in the previous path segment. The names of object types may be cased in various schema ontologies, but hub implementations should always treat these paths as case insensitive. Here are a few examples of actual paths and the type of Schema.org objects they will respond with: 97 | 98 | `/.well-known/identity/:id/collections/schema.org:Event` ➜ http://schema.org/Event 99 | 100 | `/.well-known/identity/:id/collections/hl7.org:Device` ➜ https://www.hl7.org/fhir/device.html 101 | 102 | `/.well-known/identity/:id/collections/schema.org:Photograph` ➜ http://schema.org/Photograph 103 | 104 | #### Data Portability 105 | 106 | All Hub data associated with the identity must be portable. Transfer of a hub’s contents and settings between environments should be seamless, without loss of data or operational state, including the permissions that govern access to identity data. 107 | 108 | ## Request/Response Format 109 | 110 | The REST API uses [JSON API's specification][2773b365 for request, response, and query formats, and leverages standard schemas for encoding stored data and response objects. Given the nature of the responses, only the Top-Level properties are in scope for this utilization. Requests should be formatted in accordance with the JSON API documentation: http://jsonapi.org/format/#fetching. The `Content-Type` and `Accept` header parameters must be set to `application/vnd.api+json`. This approach maximizes the use of existing standards and open source projects. 111 | 112 | #### Authentication 113 | 114 | The process of authenticating requests from the primary user or an agent shall follow the FIDO and Web Authentication specifications. These specifications may require modifications in order to support challenging globally known IDs with provably linked keys. 115 | 116 | #### GET Requests 117 | 118 | The REST routes for fetching and manipulating identity data should follow a common path format that maps 1:1 to the schema of data objects being transacted. Here is an example of how to send a `GET` request for an identity's Schema.org formatted music playlists: 119 | 120 | `/.well-known/identity/jane.id/collections/schema.org:`*`MusicPlaylist`* 121 | 122 | Requests will always return an array of all objects - *the user has given you access to* - of the related Schema.org type, via the response object's `collections` property, as shown here: 123 | 124 | ```json 125 | { 126 | "links": { 127 | "self": "/.well-known/identity/jane.id/collections/schema.org:MusicPlaylist" 128 | }, 129 | "data": { 130 | "controls": { 131 | "4n93v7a4xd67": { 132 | "key": "...", 133 | "cache-intent": "full" 134 | }, 135 | "23fge3fwg34f": { 136 | "key": "...", 137 | "cache-intent": "full" 138 | }, 139 | "7e2fg36y3c31": { 140 | "key": "...", 141 | "cache-intent": "full" 142 | } 143 | }, 144 | "payload": [{ 145 | "@context": "http://schema.org", 146 | "@type": "MusicPlaylist", 147 | "@id": "4n93v7a4xd67", 148 | "name": "Classic Rock Playlist", 149 | "numTracks": 2, 150 | "track": [{ 151 | "@type": "MusicRecording", 152 | "@id": "23fge3fwg34f", 153 | "byArtist": "Lynard Skynyrd", 154 | "duration": "PT4M45S", 155 | "inAlbum": "Second Helping", 156 | "name": "Sweet Home Alabama", 157 | "permit": "/.well-known/identity/jane.id/collections/schema.org:Permit/ced043360b99" 158 | }, 159 | { 160 | "@type": "MusicRecording", 161 | "@id": "7e2fg36y3c31", 162 | "byArtist": "Bob Seger", 163 | "duration": "PT3M12S", 164 | "inAlbum": "Stranger In Town", 165 | "name": "Old Time Rock and Roll", 166 | "permit": "/.well-known/identity/jane.id/collections/schema.org:Permit/aa9f3ac9eb7a" 167 | }] 168 | }] 169 | } 170 | } 171 | ``` 172 | 173 | #### POST Requests 174 | 175 | POSTs are verified to ensure two things about the requesting party: 1) They are the decentralized identity they claim to be; and 2) They are authorized (as specified in the ACL JSON document) to write data to a specified route. 176 | 177 | Addition of new data objects into a collection must follow a process for handling and insertion into storage: 178 | 179 | 1. The new objects must be assigned with an `@id` property 180 | 2. The Hub instance must keep an associated record that maps object IDs to the controls set for each. These control properties include: 181 | - `key`: the symmetrical public key used to encrypt the object, which Hubs and entities use to reencrypt 182 | - `cache-intent`: `full` | `light` | `min` 183 | 3. The object must be encrypted with the symmetrical key of the entities that have read privileges, as specified in the ACL JSON document. 184 | 4. The object shall be inserted into the Hub instance that is handling the request. 185 | 5. Upon completing the above steps, the change must be synced to the other Hub instances. 186 | 187 | #### Query Filter Syntax 188 | 189 | The Hub spec does not mandate specific storage and search implementations. For the purposes of interoperability and developer ergonomics hubs must accept a common search and filtering syntax regardless of the underlying implementation choice. 190 | 191 | To avoid the introduction of a new syntax, we feel [Apache Lucene's query filtering syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) balances the desire to select an option with broad, existing support, and the flexibility and expressiveness developers demand. 192 | 193 | Filters can be applied via the `filter` parameter of your queries. Additionally, filters are used to enable more granular permissioning - see the ACL spec document for more info. 194 | 195 | [13f07ee0]: https://tools.ietf.org/html/rfc5785 "IETF well-know URIs" 196 | [6cc282d2]: https://www.ietf.org/assignments/well-known-uris/well-known-uris.xml "well-known URI Directory" 197 | [2773b365]: http://jsonapi.org/format/ "JSON API Spec" 198 | -------------------------------------------------------------------------------- /topics-and-advance-readings/fit-for-purpose-blockchains.md: -------------------------------------------------------------------------------- 1 | # Fit for Purpose Blockchains 2 | 3 | ***by Manu Sporny, Dave Longley, Dave Lehn, and Adam Lake*** 4 | 5 | *A White Paper from Rebooting the Web of Trust III* 6 | 7 | ## Abstract 8 | 9 | At some point in the next 5-10 years there will be tens to hundreds of 10 | thousands of blockchains. Like databases today, each blockchain will be 11 | specifically tuned to its problem domain. There will also be a need for 12 | standards related to how these systems interoperate. Successful standards 13 | (e.g. TCP, IP, JSON, HTML) tend to be layered, modular, and solve a 14 | fairly small problem domain. This paper explores the types of modular 15 | standards that may be useful in a predicted future blockchain ecosystem 16 | containing tens to hundreds of thousands of interoperable blockchains. 17 | 18 | ## Introduction 19 | 20 | We have performed a 21 | [feature analysis of existing blockchain technologies](https://lists.w3.org/Archives/Public/public-blockchain/2016Oct/att-0004/BlockchainTechnologiesFeatureAnalysis.html) 22 | with a particular focus on well defined security, privacy, and performance 23 | principles. This analysis has led us to discover a number of modular components 24 | related to blockchain technologies that may eventually be good candidates for 25 | standardization. 26 | 27 | ## The Technologies 28 | 29 | For our study, we picked the following blockchain technologies with a 30 | particular focus on their ability to be used for "identity management" related 31 | activities: 32 | 33 | - Bitcoin 34 | - Ethereum 35 | - Stellar 36 | - IPFS 37 | - Blockstack, and 38 | - Hashgraph 39 | 40 | ## Security, Privacy, and Performance Principles 41 | 42 | We studied each Blockchain technology with a particular focus on the following 43 | security, privacy, and performance principles: 44 | 45 | - **Confidentiality** - Asserts that information is not made available or 46 | disclosed to unauthorized individuals, entities, or processes. 47 | - **Integrity** - Asserts that information accuracy and completeness of data 48 | over its entire life-cycle is maintained and assured. 49 | - **Non-repudiation** - Asserts that one party of a transaction cannot deny 50 | having received a transaction nor can the other party deny having sent a 51 | transaction. 52 | - **Information Availability** - Asserts that all information to perform a 53 | particular action must be available when it is needed. 54 | - **Provenance** - Asserts that the the chronology of ownership, custody, or 55 | location of a piece of information can be traced throughout time. 56 | - **Pseudonymity** - Asserts that interactions do not expose an entity’s true 57 | name or legal identity. 58 | - **Selective Disclosure** - A situation where an entity may disclose 59 | information to one or more selected entities without disclosing that 60 | information outside of the selected set. 61 | - **Consistency** - Asserts that all nodes in a decentralized system see the 62 | same data at the same time. 63 | - **System Availability** - Asserts that every request receives a response 64 | about whether it succeeded or failed. 65 | - **Failure Tolerance** - Asserts that the a decentralized system continues 66 | to operate despite arbitrary partitioning due to network failures. 67 | - **Scalability** - A characteristic of a system that states how performance 68 | characteristics change as the system grows or shrinks in size. 69 | - **Latency** - A characteristic of a system that states how much time it 70 | takes to complete certain operations. 71 | - **Auditability** - A characteristic of a system that ensures that the 72 | complete system state can be verified at any given time to be correct. 73 | - **Liveliness** - A characteristic of a system that states that all data 74 | requested may be retrieved from the system at any point. 75 | - **Denial of Service Resistance** - A measure of a system’s ability to 76 | respond to requests when under extreme load. Typically, a mechanism is 77 | utilized that is capable of determining a valid request from an invalid 78 | one or that makes the price the attacker must pay far greater than the 79 | price the receiver must pay to execute the request. 80 | - **System Complexity** - The level of complexity in the system that exists 81 | to achieve a set of tasks. 82 | 83 | ## Summary of Research Findings 84 | 85 | The analysis of these results led to the following two tables that summarize 86 | the research findings: 87 | 88 | - [Security Principles Summary Chart](https://lists.w3.org/Archives/Public/public-blockchain/2016Oct/att-0004/BlockchainTechnologiesFeatureAnalysis.html#h.x3fnf46se7c8) 89 | - [Performance Principles Summary Chart](https://lists.w3.org/Archives/Public/public-blockchain/2016Oct/att-0004/BlockchainTechnologiesFeatureAnalysis.html#h.sihbr510y2eq) 90 | 91 | ## Identified Features 92 | 93 | The analysis also produced the following list of features that are either 94 | common to a subset of 95 | blockchain systems or are unique to systems related to the solution domain. 96 | The list is not meant to 97 | be exhaustive, but rather suggestive of potential areas for future 98 | standardization: 99 | 100 | - **Mirroring** - A common feature of ledgers and distributed databases 101 | whereby copies of the same data is stored on multiple nodes, providing 102 | resilience and high-availability. 103 | - **Content-based Addressing** - A feature of IPFS whereby content is 104 | addressed by a cryptographic hash of the content itself, providing an 105 | implicit check on data integrity. 106 | - **Proof-of-Work** - A message ordering mechanism for a decentralized system 107 | that achieves consensus and deters bad actors by requiring participants 108 | to expend considerable resources. 109 | - **Gossip Protocol** - An efficient communication method used by peers in 110 | Hashgraph to transmit their view of events that have occurred in order to 111 | achieve consensus. 112 | - **Digital Signatures** - A cryptographic scheme for demonstrating the 113 | authenticity and integrity of digital documents. 114 | - **Public Keys** - A cryptographic key that can be obtained by anyone and 115 | used to verify digital signatures. Public keys can also function as 116 | pseudonyms. 117 | - **Permissioned Ledger** - A ledger where participants must be 118 | pre-authorized and authenticate themselves in order to write to the ledger. 119 | - **Hash Chaining** - A mechanism for cryptographically linking sets of 120 | information together. A blockchain utilizes hash chaining, where a current 121 | block includes the hash of the previous block, to express the order in 122 | which events occurred in the system. 123 | - **Merkle Proof Receipts** - A mechanism for storing the root of a Merkle 124 | tree in a blockchain and then externally providing a receipt containing a 125 | path from the hash of some private data in the Merkle tree to the root in 126 | order to establish Proof-of-Publication.. 127 | - **Cross-chain Linking** - The ability to natively reference one ledger 128 | from another; bi-directional links may also be possible. 129 | - **Linked Data Identifiers** - In Linked Data, identifiers are URLs that 130 | can be dereferenced, typically via the Web, to find machine-readable 131 | data, usually containing more Linked Data. 132 | - **HTTP API** - An application interface used to build software on the 133 | Hypertext transfer protocol, the foundation of data communication for 134 | the World Wide Web. 135 | - **Ledger Query Format** - A placeholder for a future standardized query 136 | format for ledgers. 137 | - **Linked Data** - A method of publishing structured, machine-readable 138 | data so that it can be interlinked, typically using URLs that can be 139 | dereferenced via the Web, and become more useful through semantic queries. 140 | - **JSON Storage** - A mechanism for storing data as JSON documents. 141 | - **IPLD** - InterPlanetary Linked Data, a data model representation format 142 | that enables a content addressable system to also contain named paths. 143 | - **Zero Knowledge Proofs** - Is a method by which one party (the prover) 144 | can prove to another party (the verifier) that a given statement is true, 145 | without conveying any information apart from the fact that the statement 146 | is indeed true. 147 | - **Proof-of-Signature** - A cryptographic method of consensus that is 148 | capable of determining if a particular piece of data was signed by a known 149 | entity. 150 | - **Proof-of-Stake** - A cryptographic method of consensus where an 151 | individual vote is adjusted by a particular factor based on how much 152 | “ownership” that individual has over a particular system. 153 | - **On-ledger Key Management** - Management and identification of 154 | cryptographic keys is performed directly on a ledger. 155 | - **Web-based Key Management** - Management, identification, and 156 | representation of cryptographic keys via the Web and Linked Data semantics. 157 | - **Out of Band Key Management** - Cryptographic key management is 158 | unspecified within the public key infrastructure. Applications must 159 | design and implement their own key management. 160 | - **Certificate Revocation Lists** - A CRL can be checked by a verifier 161 | of a credential to determine if the credential is still deemed to be 162 | valid by the issuer. 163 | - **OCSP** - An alternative to Certificate Revocation Lists, the Online 164 | Certificate Status Protocol (OCSP) is an Internet protocol used for 165 | obtaining the revocation status of an X.509 digital certificate over HTTP. 166 | - **Off-chain Lightning Protocols** - A method of communication that 167 | bypasses the blockchain to directly communicate a series of high 168 | frequency transactions that are then hashed and placed into a blockchain. 169 | - **Sharding** - The ability to create horizontal partitions of data in a 170 | database. Each individual partition is referred to as a shard and is held 171 | on a separate database server instance to spread load. 172 | - **Longest Chain Wins** - The chain of blocks that required the greatest 173 | amount of cumulative “work”, a measure defined by the system in which 174 | this feature is used, is selected as the consensus chain. 175 | 176 | ## Potential Areas for Standarization 177 | 178 | The list of features above provide hints at potential areas of standardization: 179 | 180 | - Communication Protocols 181 | - Ledger Create/Write/Read HTTP API 182 | - Consensus Algorithms 183 | - Proof of Work 184 | - Proof of Stake 185 | - Stellar 186 | - Hashgraph 187 | - Key Management 188 | - Rotation 189 | - On/Off Chain 190 | - Delegation and Recovery 191 | - Blockchain Anchoring and Linking 192 | - Chainpoint 193 | - Cross-chain Linking and Blockchain URLs 194 | - Data Structures 195 | - Merkle Tree expression format 196 | - Hashchain expression format 197 | - Digital Signatures 198 | - Smart Signatures 199 | - Base58 Encoding 200 | - Linked Data Signature Extensions 201 | - secp256k1 support 202 | - Multi-signature support 203 | - Endorsement signature support 204 | - JSON Normalization 205 | 206 | ## Fit for Purpose Blockchains 207 | 208 | The outcome of this work could result in modular standards that could be 209 | combined into fit for purpose blockchains. A proof of concept has been 210 | created called 211 | [Flex Ledger](http://web-payments.github.io/flex-ledger/) 212 | and has been deployed as a 213 | [public demonstration](http://dhs2016ledger.digitalbazaar.com/) 214 | of what this sort of standardization could achieve. 215 | 216 | ## Next Steps 217 | 218 | We would like to spend some time at Rebooting Web of Trust to try and flesh 219 | out more potential areas of standardization based on the research that we 220 | and others have done since Rebooting Web of Trust II. Specifically, we'd 221 | like to understand any gaps that others see in the analysis or areas of 222 | standardization that are not in the list in the previous section. 223 | -------------------------------------------------------------------------------- /topics-and-advance-readings/privacy-preserving-identity-architectures.md: -------------------------------------------------------------------------------- 1 | # Privacy Preserving Web Identity Architectures 2 | 3 | ***by Anonymous (no, not that Anonymous, the other one)*** 4 | _-- Dave Longley, Manu Sporny, Christopher Allen, Drummond Reed, and Marta Piekarska_ 5 | 6 | *A White Paper from Rebooting the Web of Trust III* 7 | 8 | ## Abstract 9 | 10 | It is important to be wary of the privacy implications and trade-offs of 11 | verifiable attribute, claim, and attestation systems. As with other ecosystems, 12 | different design decisions lead to different trade-offs. There is rarely one 13 | solution to a particular problem. Rather there tend to be a handful of 14 | solutions that make different trade-offs. This paper focuses on how privacy 15 | may be preserved using two different designs: same-origin identity and 16 | self-sovereign identity. We briefly analyze the trade-offs that come with each 17 | design approach in an attempt to progress a conversation in the community 18 | related to the appropriate path forward for a particular set of use cases. 19 | 20 | ## Problem 21 | 22 | There is no widely used, privacy-preserving, standard protocol for sharing 23 | verifiable claims that cuts across industries and market verticals. 24 | 25 | ## Terminology 26 | 27 | A **claim** is the expression of one or more attributes about an entity. 28 | 29 | A **verifiable claim** is a claim whose authorship can be cryptographically 30 | asserted. 31 | 32 | ## Introduction 33 | 34 | The general use case for sharing verifiable claims on the Web is as follows: 35 | 36 | You visit domain A and you need a verifiable claim from domain B in order to 37 | access some service. 38 | 39 | In this use case, you’re trying to prove to one party that another party 40 | (that they trust) believes something is true about you -- or that you have a 41 | certain "identity". In order to talk about a particular identity, computers 42 | typically assign an identifier (like an email address or UUID) to it. In order 43 | to give the identity meaning, entities may associate a variety of attributes 44 | with the identifier (such as name, place of residence, etc.). 45 | 46 | You may decide to make this identifier public or keep some aspects of it 47 | private. Designers of identity systems are often concerned with making sure 48 | you’re aware of which aspects are public and which are private -- and this can 49 | be very difficult to do. Depending on how identifiers are handled between 50 | computer systems, unintentional correlations may become possible, potentially 51 | revealing more information about your identities than you intended. 52 | 53 | There are two emerging schools of thought on how to address the use case. 54 | Both schools take a layered approach to solving the problem and both are 55 | interested in protecting privacy. The foundational layer in each school 56 | sets out core principles for identity that result in effects in how 57 | identity interactions may occur and constraints upon the software that 58 | must exist to enable them. 59 | 60 | As each school relies upon different core principles, we must be careful to 61 | not assume that a school has no concern for certain values, such as protecting 62 | privacy. Rather, each approach has different advantages and disadvantages by 63 | pushing complexity in different directions. 64 | 65 | ## Approach One: Same Origin Identity 66 | 67 | This school of thought is employed primarily in the Web browser and FIDO 68 | security model. 69 | 70 | ### Core Principles 71 | 72 | * Never create long lived, cross domain identifiers. 73 | * Identifiers must always be uniquely tied to a particular domain, 74 | never shared across domains, thus prohibiting any possibility 75 | for undue privacy-harming correlation. 76 | * Assume that many users lack the knowledge or experience to adequately 77 | protect their own privacy. Note that this assumption does not address 78 | collusion across domains (e.g. correlating based on email address). 79 | * All layers in this approach must adhere to and build on top of this 80 | foundational principle. 81 | 82 | ### Addressing the Use Case 83 | 84 | When you visit domain A, it will generate a random identifier that you take 85 | to domain B. Then, domain B will associate attributes with the random 86 | identifier and digitally sign this information, handing it back to you. 87 | You present this verifiable claim to domain A and get access to your 88 | desired service. 89 | 90 | The benefits of this approach include: 91 | 92 | * There is no way for domain A or domain B to correlate the identifier 93 | with anything other than the information it already knows. 94 | * Domain B does not directly learn about the user’s decision to share 95 | information with domain A. 96 | * Users that do not understand the complexities of correlating identifiers 97 | cannot harm themselves. 98 | * Revocation is privacy preserving and can be implemented via short timeouts. 99 | 100 | The drawbacks of this approach include: 101 | * Domain B must have highly available infrastructure in order to ensure 102 | that you can get access to domain A. 103 | * Domain A is dependent upon domain B implementing highly available 104 | infrastructure in order to authenticate and service its users. 105 | * The user does not get to use the claims made about them by domain B 106 | independently of (without interaction with) domain B. In other words, 107 | claims made about a user are not easily aggregated and made available 108 | for independent reuse; rather a user’s identity information is fractured 109 | across main domains or “identity providers”. 110 | * For public identities, there exists no common correlatable identifier 111 | for claims from different domains. User interaction or published 112 | correlation maps are required to share public claims. 113 | 114 | ## Approach Two: Self-sovereign Identity 115 | 116 | ### Core Principles 117 | 118 | * Identifiers must have independent existence from any particular domain; 119 | users must have control over their identity, without fear of losing it. 120 | * Management of identities should be simple and not spread across many 121 | websites. Identifiers can therefore be long lived and travel across domains. 122 | * If publicly accessible infrastructure is required to ensure people 123 | have and control independent identifiers, that’s fine, so long as layers 124 | can be added to blind identifiers for greater privacy. 125 | * Start simple, rely on shared infrastructure, and add layers to support 126 | private/anonymized identity. 127 | * Trusted third parties may provide additional infrastructure to blind 128 | identifiers as needed. 129 | * Rely on software solutions in higher layers to help users make safe choices. 130 | 131 | ### Addressing the Use Case 132 | 133 | As users have more choice (at a cost of having to understand the choices), 134 | there are two options. 135 | 136 | Option #1: When you visit domain A you directly hand over a digitally signed 137 | verifiable claim from domain B. 138 | 139 | The benefits of this approach include: 140 | * No interaction with domain B is necessary. 141 | * Domain B does not learn about the user’s decision to share information 142 | with domain A. 143 | * Domain B does not need highly available infrastructure. 144 | * Domain A is not dependent on domain B implementing highly available 145 | infrastructure. 146 | * Revocation can be privacy preserving through the use of a highly 147 | available ledger running on shared infrastructure. 148 | 149 | The drawbacks of this approach include: 150 | * Privacy-harming correlation is possible with the identifier in the 151 | verifiable claim. This isn’t a problem for a publicly used identifier, 152 | but it is for a private one. 153 | * Users may not understand that correlations can be made and need some 154 | level of assistance to avoid potentially harming themselves. 155 | 156 | Option #2: When you visit domain A, you give your pre-digitally signed 157 | verifiable claim from domain B to a trusted third party. That third party 158 | verifies the signature, anonymizes your identifier, and places their own 159 | signature on the claim before passing it back to you to hand to domain A. 160 | 161 | The benefits of this approach include: 162 | * There is no way for domain A or domain B to correlate the identifier 163 | with anything other than the information it already knows. 164 | * No interaction with domain B is necessary. 165 | * Domain B does not directly learn about the user’s decision to share 166 | information with domain A. 167 | * Domain B does not need highly available infrastructure. 168 | * Domain A is not dependent on domain B implementing highly available 169 | infrastructure. 170 | * Users that do not understand the complexities of correlating identifiers 171 | cannot harm themselves. 172 | * Revocation can be privacy preserving through the use of a highly 173 | available ledger running on shared infrastructure. 174 | * Third party verifiers can add value to the ecosystem, providing highly 175 | available infrastructure, privacy protection, and trustworthiness. 176 | 177 | The drawbacks of this approach include: 178 | 179 | * Third party verifiable learns of your information and can correlate 180 | identifiers. However, their viability as a service depends on their 181 | trustworthiness and providing a good quality, privacy-preserving 182 | service is a requirement for people to be interested in using them. 183 | 184 | ## Implications of Each Approach 185 | 186 | The Same Origin Identity approach leans on some assumptions about 187 | highly available infrastructure. Namely, that everyone has it or can 188 | provide it as needed. If this assumption is not true, then this approach 189 | has the potential to result in more centralized systems and blocking 190 | certain low budget or temporal parties from participating. Even if 191 | designers try really hard to make the core layer prevent the correlation 192 | of identifiers that the software framework introduces, that does not 193 | prevent the correlation of other strongly-personally-identifying 194 | identifiers that may be associated with identifiers from the framework. 195 | 196 | In other words, attributes such as email address, IP address, browser 197 | fingerprint, and first and last name may be associated with randomized 198 | identifiers. At this point, it does not matter that a lot of care is 199 | taken to randomize the identifier and that a lot of highly available 200 | infrastructure was put in place to prevent the correlation of that 201 | identifier with other information -- as an email address or any of the 202 | previously mentioned information is sufficiently correlatable already 203 | as strong personally identifiable information. It may be better to only 204 | pay the higher infrastructure costs when necessary -- instead of at 205 | the core layer (and, thus, for every problem in the whole ecosystem). 206 | 207 | The Self-Sovereign Identity supports privacy at a higher level instead 208 | of as a core assumption of its foundational layer. This approach 209 | actually enables privacy in a number of additional ways for example: 210 | 211 | * Claims Issuers don’t have to be notified each time a credential is used. 212 | * Identity Providers can be prevented from knowing where credentials are 213 | being used. 214 | * Anonymizer services may add value by providing stronger verification 215 | of Subjects while not leaking information that otherwise would have 216 | been leaked to Claims Inspectors. 217 | 218 | ## Next Steps 219 | 220 | We would like to explore these two approaches at Rebooting Web of Trust 221 | and see if there is agreement on the implications of each approach. We 222 | would then like to continue the conversation at the Internet Identity 223 | Workshop and see if we could bring people from these two schools of 224 | thought together to increase understanding among both groups. There 225 | seems to be a gulf of understanding between the two schools of 226 | thought that we’d like to fill with knowledge, discussion, and 227 | understanding. 228 | -------------------------------------------------------------------------------- /topics-and-advance-readings/anonymous-credentials-in-sovrin.md: -------------------------------------------------------------------------------- 1 | # Anonymous Credentials in Sovrin 2 | 3 | Jason Law and Daniel Hardman 4 | 5 | Sovrin is a public permissioned distributed ledger dedicated to self-sovereign identity. It runs on open source software distributed under a permissive open source license from the Sovrin Foundation, a nonprofit organization responsible for worldwide governance of the Sovrin Network. 6 | 7 | ## Distributed Consensus 8 | 9 | Sovrin leverages an advanced Byzantine Fault Tolerant protocol, [Plenum](https://github.com/evernym/plenum/wiki), to achieve distributed consensus. Plenum makes several security improvements on the [Redundant Byzantine Fault Tolerant](http://pakupaku.me/plaublin/rbft/report.pdf) (RBFT) protocol, such as digital signatures over MAC authenticators, and full end-to-end encryption. 10 | 11 | RBFT is itself is an improvement on the [Aardvark](ftp://ftp.cs.utexas.edu/pub/techreports/tr08-27.pdf) protocol. RBFT executes several protocol instances with different primaries in parallel to detect any performance problems in real-time, without making assumptions about the previous or future performance/condition of the system. Aardvark sets the expected throughput based on past performance and triggers a view change as soon as the primary fails to match those expectations. This works well when the load is static but fails to detect a poor performing primary when load is not near the peak. RBFT resolves this. 12 | 13 | Aardvark addresses several known vulnerabilities of [Practical Byzantine Fault Tolerance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.6130) (PBFT): (1) a malicious client can trigger view changes at will that will stop the progression of the protocol, (2) it does not separate the logic of accepting client requests and ordering them, which leads to possible DoS attacks from the client, and (3) a malicious primary can order requests at an arbitrary speed without being detected. 14 | 15 | Consensus protocols will continue to advance, and the goal of the Sovrin Foundation is to continually leverage these advances over time. Although Plenum represents some of the best current thinking in the space, if a stronger protocol emerges that meets the requirements and has suitable licensing, Sovrin will migrate to it. 16 | 17 | ## Risk of Unintended Correlation 18 | 19 | Real-world use cases reveal how easy it is to violate privacy in a public ledger by correlating across transactions to make inferences about users. For example, every attribute stored and shared in the ledger has a unique address or transaction ID. If user attributes E, F, and G were shared with website A, and attributes E, H, and I were shared with website B, the two websites can easily collude to discover that all the attributes described the same user. 20 | 21 | To combat this risk, Sovrin supports anonymous credentials. While this form of privacy-preserving crypto is not new, to date neither UProve nor Idemix has enjoyed wide-scale adoption. Sovrin offers the opportunity for anonymous credentials to become a defacto standard for cross-domain identity and privacy. By including the logic in the Sovrin client to create anonymous public keys, issue credentials, generate proofs, and verify those proofs, these capabilities can become widely available to developers with little or no effort on their part. 22 | 23 | Sovrin’s current implementation supports a rudimentary implementation of Jan Camenisch’s Anonymous Credentials. We believe it will be relatively easy to extend Sovrin to support UProve credentials or other advanced privacy-respecting signature schemes. 24 | 25 | ## Implementation 26 | 27 | Sovrin has specific transactions for bootstrapping Issuers and establishing schemas for the credentials they will issue. Issuers have a globally unique Sovrin identifier and publish a set of public attributes. To create a new credential, Issuers create a credential definition with its associated attributes and public keys. This credential schema can evolve; other Sovrin transaction types enable adding or deleting attributes from the schema definition. 28 | 29 | Note that Issuers do not need to be public. Any entity in Sovrin has the ability to be an Issuer, Prover (Holder), or Verifier (Relying Party) at different times. The entity can add a credential definition with its associated attributes and public keys, issue an instance of the credential, and verify a proof of a credential it issued, all either directly or anonymously. 30 | 31 | Credentials can be issued as transactions on the ledger or directly to a principal or Prover/Holder depending on the use case. Provers/Holders may hold the credential in a wallet or repository. Provers/Holders call methods within the Sovrin client to generate zero-knowledge proofs of one or more credentials to present to some relying party or Verifier. The Verifier verifies the proof against the public key for the credential definition stored in the ledger. 32 | 33 | ## Use Cases 34 | 35 | ### Trust Establishment 36 | 37 | The Sovrin ledger serves as a registry for self-sovereign identifiers and associated public keys. These entries can be trusted to be correct based on the strength of the distributed consensus network. Requests to modify attributes of a Sovrin identifier are authenticated via verification of an Ed25519 digital signature. The only way a credential definition (including its public keys) can be established for an issuer is through verification of the issuer’s signature by a consensus of distributed Sovrin Validator nodes. 38 | 39 | Sovrin also supports reputation events. These transactions may be public (unencrypted) or private (encrypted) and can support any type of reputation assertion. At the most basic level, reputation events enable an observer to trust that the ledger entry identifying an Issuer really is the issuer. This bootstrapping of trust could of course also be established "off-ledger", for example by pointing to the Sovrin ledger entry from the Issuer’s website or distributing an X.509 certificate of the Issuer’s public key. But the Sovrin ledger is arguably more secure and trustworthy than DNS (and if the digital signature of a Certificate Authority is to be trusted, then the Issuer’s X.509 certificate could simply be published as a credential on the Sovrin ledger). 40 | 41 | While Sovrin supports publishing public or private reputation events that can be compiled into public or private reputation graphs, it does not include algorithms for compiling, evaluating or scoring these graphs. While the Sovrin Foundation may publish reference implementations of such algorithms, this is an area where market forces can and should innovate and compete. 42 | 43 | ### Facilitating Trusted Interactions 44 | 45 | The Sovrin ledger can bootstrap trusted interactions that take place entirely outside the Sovrin network. It enables Issuers, Provers/Holders, and Verifiers to publish endpoints (e.g., URLs) for any type of out-of-band communication. These endpoints can be public, semi-private, or fully pairwise private endpoints. The Sovrin network can also, with a user’s authorization, facilitate the real-time disclosure of the IP address and port of the user’s client (known by a Sovrin node, but not recorded in the ledger). This allows an Issuer to directly and securely deliver a credential to a Holder. 46 | 47 | This endpoint negotiation can be used for pre-negotiation of an agreement, secure messaging, or even bootstrapping of an interactive zero-knowledge proof. After establishing a trusted connection, peers can exchange as many messages as needed to establish the required confidence level without affecting the Sovrin network. 48 | 49 | Of course, IP addresses can become correlation points, so depending on the use case, some form of anonymizing routing may required. This is not currently implemented in Sovrin clients. 50 | 51 | ### Multiple Non-Linkable Identifiers 52 | 53 | To avoid widespread correlation, the notion of multiple identifiers for a single principal is integral to Sovrin’s design. These identifiers cannot be created directly by the principal, or that itself would lead to correlation; instead, they can be created by a third-party Registrar/Sponsor. However that requires trusting the Registrar/Sponsor not to store or share the correlation. 54 | 55 | A better solution is to use anonymous credentials to create new identifiers. The Registrar/Sponsor can issue an anonymous credential to a principal that allows the principal to create new Sovrin identifiers (pseudonyms/cryptonyms) without those identifiers being linkable. In Sovrin, transactions will ultimately have some cost in order to pay for the Validators nodes that achieve distributed consensus. A Registrar/Sponsor could sell (or gift) a principal a credential providing the right to create, for example, 100 new identifiers. The principal could prove this with zero knowledge, enable the transactions be correlatable back to the Issuer but not the principal. 56 | 57 | ### Anonymous Voting with Verifiable Right to Vote 58 | 59 | With anonymous credentials, a voter registration authority could issue a one-time voting credential to a voter. What’s more, with the Sovrin network, voters can actually vote anonymously by *submitting their vote directly to the Sovrin network*. 60 | 61 | The Sovrin Validators would all independently verify the anonymous credential against the public keys of the voter registration authority found on Sovrin. The anonymous, yet fully verifiable, vote would then be stored as an entry in the ledger and tallied automatically. Not only does this provide non-repudiable, provably authentic anonymous voting, but Validators can also verify that the voting credential was not expired and that a vote was not issued twice. (In fact, a second vote by the same voter could constitute a change of a vote, if allowed by the rules of the election.) 62 | 63 | This protects against attacks where a vote, while anonymous, is lost or censored by a voting authority because it provides a perceived advantage (e.g., the vote comes from a region of a country not sympathetic to an incumbent, and thus is likely contain a high percentage of negative votes). 64 | 65 | This approach can also be used for many other use cases including: 66 | 67 | * Employees giving anonymous peer-to-peer feedback or reviews. 68 | 69 | * Product vendors giving every purchaser the right to issue publicly verifiable yet anonymous feedback. 70 | 71 | * Hospitals giving patients the ability to provide to give anonymous feedback about a doctor (either public or private). 72 | 73 | * Anonymous tip-line. Limits "Swatting" and trusting credible sources. 74 | 75 | ### Anonymous Endorsements 76 | 77 | Skills endorsements such those on LinkedIn could also leverage anonymous credentials to improve quality and veracity. For example, a LinkedIn member could issue anonymous credentials to verified colleagues, past and present, allowing them to rate skills. By issuing the credential, the member understands that there may be some negative ratings, but the upside is more accurate and useful feedback for all parties. 78 | 79 | To guard against Sybil attacks, endorsers may also need a second credential, such as a verifiable proof of relationship to the principal, from LinkedIn. Also, the size of the group of colleagues could create a correlation risk if it was too small (e.g., for a group of one, the response is 100% linkable). However if the skills endorsement credentials were published in Sovrin, Alice could see that 150 others were issued the same credential from Bob, and therefore be assured that her endorsement would be sufficiently anonymous. 80 | 81 | ### Credential Revocation 82 | 83 | Blockchain technologies are triggering innovation in credential revocation. Some recent papers outline new schemes for simplified revocation; however most of these schemes remain to be tested. 84 | 85 | Anonymous credentials on Sovrin provides at least one clear solution using proof of group membership. Take the case of Alice as an employee of XYZ Corp. XYZ Corp gives Alice an employee credential that it must be able to revoke if Alice leaves or is fired. However, to protect Alice’s privacy, XYZ Corp does not want to publicly announce revocation of the credential. 86 | 87 | To solve this problem, XYZ Corp can publish a number of anonymous commitments in a format and at a URL published on Sovrin. XYZ Corp would regularly update these anonymous commitments to reflect its active employees. The publication would include a digital signature for the updates, verifiable with XYZ Corp’s current public keys on Sovrin. When Alice presents her proof of employment, the presentation could also include a non-interactive zero knowledge proof for set membership ([https://infoscience.epfl.ch/record/128718/files/CCS08.pdf](https://infoscience.epfl.ch/record/128718/files/CCS08.pdf)). In this case, the set would be the current employees of XYZ Corp. 88 | 89 | Using this scheme, if Alice is an employee, the credential will be valid; as soon as she is removed from the employee list, the credential will fail. The proof will be anonymous, and Alice will have no way to fake being a current employee of XYZ Corp. 90 | 91 | ## Continuing Innovation 92 | 93 | We are constantly finding cases where privacy can be compromised on a public ledger if proper care is not taken. In many of those cases, we’ve found that anonymous credentials can play a pivotal role. At the same time, other mechanisms can also be employed to help preserve privacy, such as anonymous authentication using group signatures. 94 | 95 | We will continue to advance Privacy by Design in Sovrin by exploring ways to remove the need for identification from any Sovrin transaction that does not require it, and to rely on privacy-protecting cryptographic proofs whenever possible. 96 | 97 | -------------------------------------------------------------------------------- /draft-documents/WisdomEmbedding-Human-Wisdom-in-Our-Digital-Tomorrow.md: -------------------------------------------------------------------------------- 1 | # Embedding Human Wisdom in Our Digital Tomorrow 2 | 3 | Humanness in Digital Identity Working Group: 4 | Daniel Hardman, Kaliya Young, Matthew Schutte 5 | 6 | + Insights: Natalie Smolenski, Shannon Appelcline, Robert Clint, Joe Andrieu, Zachary Larson 7 | 8 | Rebooting Web of Trust Fall 2016 9 | 10 | Much of what we know as a species has accreted through experience. We’ve seen things work and fail, and we’ve reacted: we've created checks and balances, institutions and procedures, making calculated tradeoffs for the net benefit of individuals and communities. This wisdom is embodied in laws, social norms, patterns, proverbs, and traditions. 11 | 12 | The digital landscape, with its turbulent pace and its jockeying technologies, is a new dimension of shared experience. Identity is a central aspect of that new dimension. Who we are, how we interact, how we give and receive value, and how we hold one another accountable are all integral to identity — and they are every bit as important to the digital landscape as they were in pre-digital times. 13 | 14 | Software and hardware are more malleable than human nature. Building the code and machines that run a social network can be done in months or years, and mostly by those writing the code — but changes in the nature of friendship, trust, family, employment, and other human relationships are evolutionary, incremental, and undirected, and they unfold over generations and centuries more often than months. This mismatch in evolution matters; we risk rushing into digital construction, and not pausing to consult moral calipers or experiential plumb lines. Widespread surveillance, doxing, online bullying, and the existance of child pornography are all evidence that our digital universe has the same opportunities and pitfalls familiar in other contexts. 15 | 16 | We should be deliberate about transferring our wisdom into this brave new digital world. A number of different themes highlight how this wisdom could be advantageous or problematic for our digital future. 17 | 18 | ## Theme 1: Vulnerability 19 | 20 | Communities often distribute privilege, power, and status unevenly. The reasons for such patterns may be good, bad, or mixed. 21 | * Parents care for young children, and proxy them in early interactions; in declining years, children often caretake for their elder parents. This stewardship is at its core altruistic. However, it can turn abusive, so we’ve created hotlines, requirements for reporting, restraining orders, and social norms as safety rails. 22 | * Immigrants cross national borders without the language and cultural skills that would empower them; remediation takes time and effort, and in the meantime, generosity and exploitation are both possible. 23 | Regardless of efforts to create equity, disparity emerge: the wealthy accumulate more wealth and the poor are unable to accumplate anything, there are the educated and the unschooled, healthy and sick… 24 | 25 | Digital systems need to facilitate patterns of behavior that society has evolved to cope with vulnerability. A digital identity needs to support the notion of guardianship and delegation, for example, but it also needs to make guardianship revocable, with strong accountability and an appeals or dispute process. This sort of technical requirement is not a “nice-to-have” when identity transactions are written to immutable ledgers; it is foundational. 26 | 27 | Dictatorships are described paternalistically by their supporters, but experienced as oppressive by most of their population. Will the digital frontier be friendly to coups and power plays, or will it bias toward equal access, symmetric power, and self-correcting imbalance? Will fads and witch-hunts abound, or will systems be resilient to them? 28 | 29 | What attitude will digital identity systems take regarding the role of the individual in relation to a group, organization, or state? Today, we see an accountability mismatch and inconsistencies between individuals and corporations (consider the recent Libor and Wells Fargo scandals). Individuals have limited resources, a single physical location, direct legal accountability backed by the threat of force, and one limited lifetime; companies may exist in many locales and jurisdictions, with dynamic membership, diminished sensitivity to force, and unknown lifespan. If the identities of these two types of entities (or of entities at other points on the individual/collective spectrum) are treated the same in digital contracts, transactions, and reputation, will it have the outcomes we hope? 30 | 31 | ## Theme 2: Shadows 32 | 33 | Shadows on multiple scales are real and affect how individuals, groups, societies, and cultures operate. Examples include, at the individual level drug addiction, at the interpersonal level emotional abuse, at the family level secret keeping, at the social level systemic discrimination of various populations. The emerging digital world can and does actively reveal the shadows. 34 | 35 | The leak of the Panama Papers offers an example of how Information and Communication Technologies have enabled the surfacing of the collective shadow of international money systems. This created a global conversation about issues around the use of international banking systems by the elites. 36 | 37 | Another example is the public conversation via social media (where anyone with an account can speak to a public audience) spurred by the Donald Trump tape about him assaulting women. Women used that media to speak out with the hashtag #notokay to share their own experiences of abuse by men and surface the extent of it in society. 38 | 39 | This trend to surface shadows on multiple levels will continue; we need to understand what healthy collective processes (social and emotional technologies) to use for composting and processing shadows that are surfacing on multiple levels. This will be key to supporting healthy social outcomes rather than creating active suppression that could cause them to fester and eat away at social fabric. 40 | 41 | To be clear the authors are not advocating that “everything” needs to be public; privacy is a need of the vulnerable that a wise digital ecosystem will safeguard it. Accountability is also a social good, paired with social and technical norms for how this is achieved in various transactions types. 42 | 43 | ## Theme 3: Healing 44 | 45 | People make mistakes. Things break. We act with imperfect information. And we have a variety of patterns for coping: forgiveness, forgetting, temporary kludges, approximations that are “good enough”, consensus, escalation procedures, heuristics … 46 | 47 | Some identity systems are imagined in ways that depend on idealizations with no room for mistakes. Distributed ledgers are usually assumed to be immutable; the smart contracts they enable are supposed to be executed with automated logic that’s 100% trustable; security assumes that key pairs are not compromised. 48 | 49 | What happens if these idealizations prove to be untrue (or undesirable)? A smart contract that has a bug is a scary prospect — and it’s even scarier if exploitable by hackers. How will debugging and upgrading to a more robust version of the contract happen? Do contracted parties both have to sign off on the upgrade, or can it be imposed by an arbiter? Is the upgrade documented? Is its timing negotiable? 50 | 51 | In the physical world, many mortgage delinquencies were probably forgiven for a time, in the wake of Hurricane Katrina. Will our digital world offer an analog, and if so, how easy will it be to trigger? 52 | 53 | Is it possible for friends to help me recover keys if Katrina destroys every device I own, and also damages the ISP that hosts some of my cloud data? If a thief steals a key to my house, I can change the locks when I find out; are there digital equivalents? 54 | 55 | In normal human experience, youthful indiscretions might be overlooked after years of responsible behavior; in a digital world where no information is forgotten, are there provisions for judicious squinting to skip minor details? Who decides how such provisions work — and are they subject to revision? 56 | 57 | ## Theme 4: Tensions 58 | 59 | Humans are forever making imperfect tradeoffs. Do we go out and work in the rain to plug the roof of our shed, or do we sit in our snug living room and clean up the damage when the sun is shining? Either choice has pluses and minuses. We make these tradeoffs based on incomplete information (Will the storm get worse? How bad is the leak?), and then we live with the consequences. Sometimes we use temporary workarounds (like running out in the rain and throwing a tarp over the hole in the roof). 60 | 61 | Identity systems that are too idealized in one dimension may be uncomfortable or downright dangerous when they can’t accommodate human messiness and tradeoffs. For example, a system that perfectly captures history and disallows repudiation may provide excellent accountability but it may also be ripe for misuse. Edwin Black’s *IBM and the Holocaust* is a cautionary tale in this regard; superb record-keeping from the census made the Nazi's ability to find and send Jews, and others to the death camps. Making the so called final solution far more efficient than it might have otherwise been. 62 | 63 | Temporariness and simplification are interesting considerations. If a person gets a job, discovers that it isn’t a good fit after a few weeks, and leaves, should it be okay to omit the detour on a resume or job application? This sort of gloss is innocent and even important to our truth-telling in human contexts; we may agree that describing the detour gets in the way of what’s essential. But an identity system that logs everything and treats all events as equally important can’t model such choices. If a person has a right to be forgotten, do ex-spouses have a right for their short, unhappy marriage and subsequent divorce to be forgotten too? 64 | 65 | Identity depends on context; a system that erodes that principle may conflate things that humans would separate (or vice versa). How should an identity be transferred (or preserved, or transformed) when an individual has a gender transition or chooses to be identified as non-binary, for example? If a person develops Alzheimers, or has a traumatic brain injury, or gets diagnosed as schizophrenic, is their identity invariant? How about a corporation under different CEOs, boards, or legal jurisdictions? Certainly there are facets of identity (the same person may be a mom, a CMO, a patient, a passport holder, and a Den Mother); are there also degrees of identity and sameness, rather than just binary equality? Are we friendly to the truth that identity unfolds as a process, and that the process may be experienced differently by different observers? 66 | 67 | ## Theme 5: Complexity and Gestalt 68 | 69 | Western thought is generally prejudiced toward an objective, discrete view of reality. We believe in countable, quantifiable things, and we tend to be at least partially unaware of intangibles and systemics. 70 | 71 | When a neighbor beautifies their yard, they create value for themselves but they also do so for those who live nearby. Is this a transaction that’s associable with their digital identity? In the “real world,” it definitely has the potential to affect reputation and relationships; it may even have monetary consequences if it changes street appeal and thus home prices… Similarly, a corporation that bulldozes a mountaintop might have legal rights that permit the choice, but might steal a beautiful view from thousands of people. Is such behavior recordable on a ledger, or on the reputation systems that depend upon them? 72 | 73 | Viewing everything as a transaction yields certain types of insights, but it may be counterproductive as well. If a neighbor shares cookies over the fence, and comes home later to find their flower patch weeded and edged, framing what happened as a tit-for-tat saps the potential for a shared sense of identity — a “we” that emerged from willing friends. The Israeli daycare study, where parents who were fined for late pickup showed spikes in tardiness because they felt entitled by the transaction, speaks to this risk. 74 | 75 | Should identity ecosystems ever be tentative? Humans certainly are ... Are we building a gods-eye view with Newtonian sensibilities about objective truth, or something much more pragmatic and integrative? 76 | 77 | Work on metacurrencies may teach us something here. 78 | 79 | ## Theme 6: Organizational Choices 80 | 81 | The majority of the protocols that run the internet today are at least somewhat centralized, and they tend to be client-server oriented: HTTP, SMTP, DNS, trust chains with certificates, and so forth. Globally useful handles (email addresses, gamer aliases, profiles on social media, phone numbers) are all dispensed by corporations or governments. 82 | 83 | Perhaps this reflects our tendency to trust institutions over individuals as a source for verification. State-issued IDs are assumed to be more trustworthy than a hand-written note in the family bible, for example. Are they, in actuality? 84 | 85 | It’s difficult for an individual to start up a service on their own, without help from an organization like an ISP, an Autonomous System, a domain registrar, etc. Do we like this? 86 | 87 | Some voting mechanisms have evolved to balance the power of individuals (or small groups) relative to larger groups; bicameral legislatures are an example. 88 | 89 | We’d like to also enable ad hoc and collaborative, grass-roots organizing. It needs to be possible to do tomorrow’s equivalent of the march on Selma, and have the organizations built for such efforts not be marginalized by status quo power, just because they are new. 90 | 91 | # Conclusion 92 | There are invisible architectures embedded in the systems that our society relies upon to make decisions and coordinate efforts. Some of these are a result of the contexts and capabilities present at the time of their emergence. However, they are not without consequences. 93 | 94 | Hence, as we go about designing and building new systems for fostering interaction and coordination through digital processes, we should be deliberate about what we are building. 95 | 96 | If we are unaware of our own assumptions, we may simply re-create in digital form, the very structures that we had hoped to transcend. 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | -------------------------------------------------------------------------------- /topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md: -------------------------------------------------------------------------------- 1 | # Blockchain Extensions for Linked Data Signatures 2 | 3 | ***by Manu Sporny, Harlan Wood, Noah Thorp, Wayne Vaughn, Christopher Allen, Jason Bukowski, and Dave Longley*** 4 | 5 | *A White Paper from Rebooting the Web of Trust III* 6 | 7 | ## Introduction 8 | 9 | The term [Linked Data](https://en.wikipedia.org/wiki/Linked_data) 10 | is used to describe a recommended best practice for exposing, sharing, and 11 | connecting information on the Web using standards, such as URLs, to identify 12 | things and their properties. When information is presented as Linked Data, 13 | other related information can be easily discovered and new information can be 14 | easily linked to it. Linked Data is extensible in a decentralized way, greatly 15 | reducing barriers to large scale integration. 16 | 17 | With the increase in usage of Linked Data for a variety of applications, there 18 | is a need to be able to verify the authenticity and integrity of Linked Data 19 | documents. The [Linked Data Signatures specification](https://web-payments.org/specs/source/ld-signatures/) added authentication and integrity protection to linked data documents through the use of public/private key cryptography without sacrificing Linked Data features such as extensibility and composability. 20 | 21 | Recently, there has been interest in extending Linked Data Signatures to 22 | support new use cases surfaced in the Blockchain and Verifiable Claims 23 | ecosystems. These use cases include: 24 | 25 | - Bitcoin-style [secp256k1](http://www.secg.org/sec2-v2.pdf) signatures 26 | - [Proof of Publication](https://web-payments.org/specs/source/pop2016/), 27 | [Chainpoint](http://www.chainpoint.org/), and other Blockchain anchoring 28 | use cases 29 | - Pure JSON normalization and clear-text signing algorithms 30 | - JOSE JSON Web Token-style signatures 31 | 32 | This whitepaper explores various extensions to the Linked Data Signatures 33 | specification that are designed to support the use cases listed above. 34 | 35 | ## Support for secp256k1 36 | 37 | Support for Bitcoin-style secp256k1 signatures would result in a signature 38 | block that looks like the following: 39 | 40 | "signature": { 41 | "type": "sha256-ecdsa-secp256k1-2016", 42 | "created": "2016-09-22T22:38:03Z", 43 | "creator": "bitcoin-address:1LGpGhGK8...rP4xWER", 44 | "domain": "example.com", 45 | "nonce": "ba9e0b95", 46 | "signatureValue": "IKwTJ...E37UsLgs=" 47 | } 48 | 49 | This signature would require the creation of a new 50 | [Linked Data Signature Suite](https://web-payments.org/specs/source/lds2016/) 51 | specification defining the following parameters: 52 | 53 | - canonicalizationAlgorithm - https://w3id.org/security#URDNA2015 defined in 54 | [RDF-DATASET-NORMALIZATION] 55 | - digestAlgorithm - https://w3id.org/security#sha256 defined in 56 | [RFC6234](https://tools.ietf.org/html/rfc6234) 57 | - signatureAlgorithm - http://w3id.org/security#secp256k1 defined in 58 | [SEC2v2](http://www.secg.org/sec2-v2.pdf) 59 | 60 | There are a few open questions that need to be discussed at Rebooting 61 | Web of Trust: 62 | 63 | - Is the nonce necessary or optional? 64 | - Are developers aware that the Universale RDF Dataset Normalization Algorithm 65 | is executed when performing the digital signature? 66 | - Are developers comfortable with using a JSON-LD context with their data? Are 67 | they aware that information that doesn't map is dropped? Should the JSON-LD 68 | processors fail when information is dropped from signed data? 69 | - Is a Signature Suite named `sha256-ecdsa-secp256k1-2016` easy for developers 70 | to remember? 71 | - Should the creator field (example: `bitcoin-address:1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER`) 72 | be dereferenceable outside of the Bitcoin Blockchain? 73 | - Is the Security Vocabulary the best place to put the secp256k1 signature 74 | algorithm term? 75 | - The pubkey is embedded with the signature — since the pubkey for 76 | ECDSA sig is the same as for a schnorr sig, should we explicitly separate 77 | them? Otherwise you have to understand how to parse composite signature 78 | format (I think it is a byte plus pubkey plus sig) if you wish to 79 | correlate any public keys. 80 | - If we separate out the pubkey from signature, how will that work 81 | with multisig? With smart signatures? 82 | - There is no standard for sharing bitcoin pub keys — it has been suggested, 83 | but never implemented that it should be a base58 prefix of 4,but in fact, 84 | most Bitcoin ASCII armored signatures use base64. 85 | - Another issue is that base58 is unique to Bitcoin, and there are no 86 | international standards for it. 87 | - What schema.org info do we need to define (applies to chainpoint as well). 88 | - Should the creator really be the pub key hash, or the pub key, or point 89 | to a verified claim or DID? If to the later, what field can the pubkey be 90 | put in? 91 | 92 | ## Support for CamLys 93 | 94 | Support for Camenisch-Lysyanskaya style signatures would result in a signature 95 | block that looks like the following: 96 | 97 | { 98 | "@context": "https://w3id.org/anoncreds/v1", 99 | "homeState": "Virginia", 100 | "signature": { 101 | "type": "CamLys2016", 102 | "created": "2016-09-22T22:38:03Z", 103 | "creator": "https://blue.example.com/keys/1", 104 | "claimDefinition": "https://blue.example.com/definitions/drivers-license", 105 | "revocationTails": "https://blue.example.com/tails/set-32893", 106 | "revocationTailsHash": "urn:sha256:43903bab3b4b2b3b4b4b2bb2b8384ad457", 107 | "accumulator": "https://blue.example.com/accumulator/set-32893", 108 | "domain": "example.com", 109 | "signatureValue": "IKwTJ...E37UsLgs=" 110 | } 111 | } 112 | 113 | This signature would require the creation of a new 114 | [Linked Data Signature Suite](https://web-payments.org/specs/source/lds2016/) 115 | specification defining the following parameters: 116 | 117 | - canonicalizationAlgorithm - https://w3id.org/security#NCA (no 118 | canonicalization algoirthm) 119 | - digestAlgorithm - https://w3id.org/security#sha256 defined in 120 | [RFC6234](https://tools.ietf.org/html/rfc6234) 121 | - signatureAlgorithm - http://w3id.org/security#camlys defined in 122 | [CAMLYS](http://groups.csail.mit.edu/cis/pubs/lysyanskaya/cl02b.pdf) 123 | 124 | 125 | ## Blockchain Anchoring 126 | 127 | Blockchain anchoring techniques are used to prove that data existed at a 128 | specific point in time. These techniques cryptographically embed data in a 129 | blockchain by publishing a hash of the data in a blockchain transaction. By 130 | comparing the hash embedded in a blockchain with the hash of a set of data, 131 | it’s possible to verify that the data existed at a specific time. 132 | 133 | Merkle trees are often used to store and hash the data, enabling large volumes 134 | of data to be stored into blockchains like the Bitcoin blockchain. These 135 | mechanisms, such as [Chainpoint](http://www.chainpoint.org/) and 136 | [OpenTimestamps](https://petertodd.org//2016/opentimestamps-announcement), 137 | are currently in 138 | the experimental standardization phase. It is possible to merge approaches like 139 | Chainpoint with Linked Data Signatures. The Linked Data Signatures 140 | [Proof of Publication](https://web-payments.org/specs/source/pop2016/) 141 | specification is one such approach, where the blockchain receipt may be 142 | embedded in the Linked Data Signature without any modification to 143 | the [LinkedDataSignature2016](https://web-payments.org/specs/source/lds2016/) 144 | signature suite. 145 | 146 | Included is an example of a Proof of Publication style Linked Data signature: 147 | 148 | "signature": { 149 | "type": "LinkedDataSignature2015", 150 | "creator": "http://example.com/i/pat/keys/5", 151 | "created": "2011-09-23T20:21:34Z", 152 | "domain": "example.org", 153 | "nonce": "2bbgh3dgjg2302d-d2b3gi423d42", 154 | "merklePublicationProof": { 155 | "@context": "https://w3id.org/chainpoint/v2", 156 | "type": "ChainpointSHA256v2", 157 | "targetHash": "bdf8c9b...cb8e85ef2", 158 | "merkleRoot": "51296f46...6581a7a", 159 | "proof": [ 160 | { "left": "bdf8c9b...e85ef2" }, 161 | { "left": "cb0dbbed...2e49faf" }, 162 | { "right": "cb0dbb...2e49faf" } 163 | ], 164 | "anchors": [{ 165 | "type": "BTCOpReturn", 166 | "sourceId": "f3be82...fadee" 167 | }] 168 | }, 169 | "signatureValue": "OGQzNGVkMz...ODIyOWM32NjI=" 170 | } 171 | 172 | There are a few open questions that need to be discussed at Rebooting Web 173 | of Trust: 174 | 175 | - Is there interest in supporting proof of publication in the signature block, 176 | or are unsigned blockchain receipts good enough because the proof exists 177 | in the blockchain itself? 178 | - Should blockchain receipts have digital signatures, or are digital 179 | signatures on blockchain receipts redundant? 180 | - Is there interest in integrating Chainpoint 2.0 style receipts into the 181 | signature block for Linked Data Signatures? 182 | - Do we need to more explicit the separation the data format for the message 183 | vs how the merkle root is stored? Like DIDs, there will be multiple methods 184 | for storing the merkle root — but the data format once you have a canonical 185 | message can be in common for all. 186 | - The merkle tree for Chainpoint itself is fairly basic, Peter Todd’s open 187 | timestamps uses a more sophisticated merkle tree. Should we do a 188 | Chainpoint 3.0? 189 | - Specific to open-timestamps on Bitcoin, it uses a different method to 190 | store the merkle tree root that may be more acceptable long-term than 191 | op_return. 192 | - Open-timestamp offers some additional services — should we start defining 193 | APIs? 194 | - Peter Todd has had some success to with open-timestamps and PGP for use 195 | with Github commit signatures. Should we try to get this to be a standard 196 | as well? 197 | 198 | ## JSON Normalized Clear Text Signatures 199 | 200 | The [JSON Web Signatures](https://tools.ietf.org/html/rfc7515) (JWS) 201 | specification defines how one may perform digital signatures on a block of 202 | JSON data. While ideal for a number of use cases that require digital 203 | signatures, the approach is not a good fit for other use cases that require 204 | digital signatures. For example, data signed using JWS, called 205 | [JSON Web Tokens](https://tools.ietf.org/html/rfc7519) (JWT), are base-64 206 | encoded. This creates a number of problems for developers: 207 | 208 | - JWTs cannot be natively stored in document-based storage engines (like 209 | MongoDB and CouchDB) without decoding them, which removes the digital 210 | signature information 211 | - JWTs cannot be nested within each other easily, requiring multiple nested 212 | base-64 encodings with duplicated data to support nested signatures 213 | - JWTs do not easily support multi-signature schemes, meaning that they can't 214 | be chained together without duplicating the data for each chained signature 215 | - JWTs are not JSON, which most developers expect when publishing, consuming, 216 | and working with data. While it's true that you can base-64 decode the 217 | data, you then lose the signature and have to track it through some other 218 | means if the signed object in question needs to be transmitted to a remote 219 | system. 220 | - You cannot express Linked Data in a syntax-agnostic way and are forced to 221 | create a signature on a JSON-LD document, which binds the signature to the 222 | JSON-LD syntax rather than making the signature more syntax agnostic. 223 | 224 | Linked Data Signatures were originally designed to sign Linked Data and 225 | overcome the shortcomings of JWTs above. There have been several requests over 226 | the years to support clear JSON signatures, resulting in a signature block 227 | that looks like this: 228 | 229 | "signature": { 230 | "type": "JsonSignature2017", 231 | "created": "2017-01-02T12:11:54Z", 232 | "creator": "https://example.org/keys/123", 233 | "domain": "example.com", 234 | "nonce": "ba9e0b95", 235 | "signatureValue": "IKwTuQqTwz...IEBAE3sLgs=" 236 | } 237 | 238 | Doing so requires a new JSON Normalization Algorithm specification and a 239 | Signature Suite with the following properties: 240 | 241 | - canonicalizationAlgorithm - https://w3id.org/security#JNA2017 which needs 242 | to be defined. 243 | - digestAlgorithm - https://w3id.org/security#sha256 defined in 244 | [RFC6234](https://tools.ietf.org/html/rfc6234) 245 | - signatureAlgorithm - http://www.w3.org/2000/09/xmldsig#rsa-sha1 246 | defined in [RFC3447](https://tools.ietf.org/html/rfc3447) 247 | 248 | There are a few open questions that need to be discussed at 249 | Rebooting Web of Trust: 250 | 251 | - Is this normalization mechanism desired by participants in the Workshop? 252 | - Is there a pre-existing JSON normalization algorithm that we should use as 253 | the basis for the normalization specification? 254 | - The JOSE group strictly avoided JSON normalization, is there something we're 255 | missing in attempting to provide such a mechanism? 256 | - Which use cases would require the use of this signature suite instead of 257 | using the existing Linked Data Signature 2016 suite? 258 | 259 | ## JWT-style Linked Data Signatures 260 | 261 | It has also been postulated that JWT-style digital signatures could be 262 | encapsulated in Linked Data Signatures producing a signature format that looks 263 | like the following: 264 | 265 | "signature": { 266 | "type": "Jwt2017", 267 | "signatureValue": " 268 | eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2Rtdi\n 269 | CJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJkaWQ6ZWJmZWIxZjcxMmVi\n 270 | YzZmMWMyNzZlMTJlYzIxIiwiZW50aXR5Q3JlZGVudGlhbCI6eyJAY29udGV4dCI\n 271 | 6Imh0dHBzOi8vdzNpZC5vcmcvc2VjdXJpdHkvdjEiLCJpZCI6Imh0dHA6Ly9leG\n 272 | FtcGxlLmdvdi9jcmVkZW50aWFscy8zNzMyIiwidHlwZSI6WyJDcmVkZW50aWFsI\n 273 | iwiUHJvb2ZPZkFnZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9kbXYu\n 274 | ZXhhbXBsZS5nb3YiLCJpc3N1ZWQiOiIyMDEwLTAxLTAxIiwiY2xhaW0iOnsiaWQ\n 275 | iOiJkaWQ6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiYWdlT3ZlciI6Mj\n 276 | F9fX0.LwqH58NasGPeqtTxT632YznKDuxEeC59gMAe9uueb4pX_lDQd2_UyUcc6\n 277 | NW1E3qxvYlps4hH_YzzTuXB_R1A9UHXq4zyiz2sMtZWyJkUL1FERclT2CypX5e1\n 278 | fO4zVES_8uaNoinim6VtS76x_2VmOMQ_GcqXG3iaLGVJHCNlCu4" 279 | } 280 | 281 | Doing so would require new JSON Normalization Algorithm specification and a 282 | Signature Suite with the following properties: 283 | 284 | - canonicalizationAlgorithm - https://w3id.org/security#JWT2017 which needs 285 | to be defined. 286 | - digestAlgorithm - https://w3id.org/security#sha256 defined in 287 | [RFC6234](https://tools.ietf.org/html/rfc6234) 288 | - signatureAlgorithm - http://www.w3.org/2000/09/xmldsig#rsa-sha1 289 | defined in [RFC3447](https://tools.ietf.org/html/rfc3447) 290 | 291 | This would raise the following open questions that would need to be discussed 292 | at Rebooting Web of Trust: 293 | 294 | - Is the ability to embed JWTs in a Linked Data Signature block desirable? 295 | - Is the duplication of the entirety of the content in the signature desirable? 296 | - Which use cases would require the use of this signature suite instead of 297 | using the existing Linked Data Signature 2016 suite? 298 | 299 | ## Next Steps 300 | 301 | In this paper, four extensions to the Linked Data Signatures specification 302 | have been introduced. The authors of the paper would like to explore each 303 | extension in more detail at the Rebooting Web of Trust III Workshop and 304 | produce one or more W3C-formatted specifications that summarize the state of 305 | findings during the course of the workshop. 306 | --------------------------------------------------------------------------------