The rwot6-santabarbara from weboftrustinfo

Rebooting the Web of Trust VI: Santa Barbara (March 2018)

This repository contains documents related to RWOT6, the sixth Rebooting the Web of Trust design workshop, which ran in Santa Barbara, California, on March 6th to 8th, 2018. 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.

Please see the Web of Trust Info website for more information about our community.

Topics & Advance Readings

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:

A specific problem that they wanted to solve with a web-of-trust solution, and why current solutions (PGP or CA-based PKI) can't address the problem?
A specific solution related to the web-of-trust that you'd like others to use or contribute to?

Please see the Topics & Advance Readings directory for a listing of all the papers.

Complete Papers

The goal for each Rebooting the Web of Trust workshop is publication of three to five white papers:

BTCR DID Resolver Specification (Text)

Kim Hamilton Duffy, Christopher Allen, Ryan Grant, and Dan Pape

This describes the process of resolving a BTCR DID into a DID Document. The draft reference implementation is available at https://github.com/WebOfTrustInfo/btcr-did-tools-js (see didFormatter.js). Note that not all steps described in this document are implemented yet.

Decentralized Autonomic Data (DAD) and the three R's of Key Management (Text)

by Samuel M. Smith Ph.D. with Vishal Gupta

This paper proposes a new class of data called decentralized autonomic data (DAD). The term decentralized means that the governance of the data may not reside with a single party. A related concept is that the trust in the data provenance is diffuse in nature. Central to the approach is leveraging the emerging DID (decentralized identifier) standard. The term autonomic means self-managing or self-regulating. In the context of data, we crystalize the meaning of self-managing to include cryptographic techniques for maintaining data provenance that make the data self-identifying, self-certifying, and self-securing. Implied thereby is the use of cryptographic keys and signatures to provide a root of trust for data integrity and to maintain that trust over transformation of that data, e.g. provenance. Thus key management must be a first order property of DADs. This includes key reproduction, rotation, and recovery. The pre-rotation and hybrid recovery methods presented herein are somewhat novel.

Decentralized Identifiers v1.0 (Text)

A Status Note

The Decentralized Identifiers specification editors and implementers spent some time at Rebooting the Web of Trust 6 processing the remaining issues in the issue tracker. This document summarizes the proposed resolutions that the group has put forward to resolve all of the DID specification issues that were submitted before 2018-03-05.

Exploring Sustainable Technology Commons using Appreciative Inquiry (Text)

by Heather Vescent, Kaliya “Identity Woman” Young, Adrian Gropper, and Juan Caballero

Technology commons come in a variety of flavors and have achieved varying levels of financial success. For-profit corporate activities have in few historical cases been set up with a financial feedback mechanism to support the commons upon which they depend and capitalize. Why do the commons and the technology sectors’ available forms of capitalism act as incompatible as oil and water, even though they support each other’s aims? When capitalist benefactors support the technology commons that they utilize, it creates a sustainable and thriving commons which enables and supports additional capitalistic technology innovation. Having worked on both sides of the equation, the authors of this piece propose a vocabulary to nourish these interactions between the two sides; identified characteristics of a sustainable technology commons; identified commons models and variations; applied Appreciative Inquiry principles to one commons model; and identified future research areas.

Identity Hub Attestation Flows and Components (Text)

by Daniel Buchner, Cherie Duncan, John Toohey, Ron Kreutzer, and Stephen Curran

In this document, we define a set of user flows and describe the associated Action Objects that support a Hub-centric approach to the request, issuance, presentation, verification, and revocation of interoperable attestations. This document extends the Identity Hub Explainer.

Introduction to DID Auth (Text)

by Markus Sabadello, Kyle Den Hartog, Christian Lundkvist, Cedric Franz, Alberto Elias, Andrew Hughes, John Jordan & Dmitri Zagidulin

The term DID Auth has been used in different ways and is currently not well-defined. We define DID Auth as a ceremony where an identity owner, with the help of various components such as web browsers, mobile devices, and other agents, proves to a relying party that they are in control of a DID. This means demonstrating control of the DID using the mechanism specified in the DID Document's "authentication" object. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to establish mutually authenticated communication channels and to authenticate to web sites and applications. Authorization, Verifiable Credentials, and Capabilities are built on top of DID Auth and are out of scope for this document. This paper gives on overview of the scope of DID Auth, supported protocols and flows, and the use of components of the DID Documents that are relevant to authentication, as well as formats for challenges and responses.

Open Badges are Verifiable Credentials (Text)

By Nate Otto & Kim Hamilton Duffy

We identify use cases and requirements that connect threads of work happening in the Rebooting Web of Trust community around: educational achievement claims (particularly using the Open Badges vocabulary); use of decentralized identifiers (DIDs) within web services where educational claims circulate; and integrating blockchain-reliant verification layers. We illustrate each of these cases with a set of example documents and describe user stories for Open Badges ecosystem software in the roles of Issuer, Host/Backpack, Displayer, and Verifier that need to be implemented in order to enable the capabilities described.

SSI: A Roadmap for Adoption (Text)

By Moses Ma, Claire Rumore, Dan Gisolfi, Wes Kussmaul & Dan Greening (Senex Rex)

This document proposes the formation of a short-term team to develop consistent messaging for the Self-Sovereign Identity (SSI) market. It will target key stakeholders who would actively promote SSI adoption. The goal is to create an SSI market roadmap. This roadmap will help SSI leaders, standards bodies, developers, academics, media, and investors coordinate and clarify their messaging for the market, to accelerate the SSI adoption.

Complete Rebooting the Web of Trust Listing

A different repository is available for each of the Rebooting the Web of Trust design workshops:

Complete Rebooting the Web of Trust Listing

A different repository is available for each of the Rebooting the Web of Trust design workshops:

License

All of the contents of this directory are licensed Creative Commons CC-BY their contributors.

DID Auth: Adjust away from "identity" and "ownership"

In the DID-Auth paper, https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md, the term "identity owner" is used as a cornerstone for discussing who controls a DID.

Unfortunately, "ownership" is a legal point of fact and will be adjudicated by the courts. Even if a thief steals your private keys and proves control of a DID, if you can prove the theft, courts will NOT recognize the thief as owner. So control != ownership so referring to the controller as the owner is an unfortunate shortcut.

Second, although DIDs and DID documents enable proof of control over the DID document, they do not establish control over the entire resulting identity. In particular, any verifiable credential "about" that DID may or may not be owned or even controlled by the controller of the DID.

For example, wrt a digital driver's license, issued to a DID. Who owns the driver's license? Who controls it? Almost certainly, the Department of Motor Vehicles controls it. Not the DID controller. Even if the credential is literally sold to another individual, along with the DID key, it would not transfer the privilege of driving.

Which is to say that part of the identity--or one of the identities--as manifest in that driver's license is NOT fully under the control or ownership of the subject.

So, yes, the licensed driver could prove the DID in the credential is under their control, but that does NOT mean they have control over the credential itself. The full identity is the combination of DIDs + VCs + how both are created, stored, used, and governed that comprises the actual identity. At best, DIDs demonstrate control over one or more anchors to an identity, which itself can manifest across myriad of verifiers.

Perhaps more important, the DMV has a bunch of non-DID-based authentication policies and procedures. The credentials and information they use to identify individuals is completely outside the scope of DIDs. The DMV will have an internal record, an internal identity, for everyone it issues a driver's license or ID card to. That identity doesn't suddenly become owned or controlled by the licensee just because the DMV uses a DID as the public facing identifier on a digital credential.

Although these may seem like minor tweaks, I think it's important to frame DIDs and DID-Auth rigorously in terms of what they can actually do rather than fall into industry vernacular that can and will be read differently by outsiders trying to understand our work. In particular, the twittersphere is still reeling from the early advocacy that DIDs give people control over their identity--notable leaders in this space advocated DIDs as a panacea for just about every privacy problem on the Internet and off. They aren't. They are a vital cornerstone in a new framework that promises to restructure how identity works. They aren't magic fairy dust that gives us control over all the information organizations use to recognize, remember, and respond to us as specific people. The use of "identity owner" reads like magic fairy dust to me.

@peacekeeper @kdenhartog @christianlundkvist @AlbertoElias @andrewhughes3000 @jljordan42 @dmitrizagidulin

I think these suggestions could be adopted without changing the fundamental work. If you're open to the changes, I would be happy to make a stab at a PR.

weboftrustinfo / rwot6-santabarbara Goto Github PK

rwot6-santabarbara's Introduction

Rebooting the Web of Trust VI: Santa Barbara (March 2018)

Topics & Advance Readings

Complete Papers

Kim Hamilton Duffy, Christopher Allen, Ryan Grant, and Dan Pape

by Samuel M. Smith Ph.D. with Vishal Gupta

A Status Note

by Heather Vescent, Kaliya “Identity Woman” Young, Adrian Gropper, and Juan Caballero

by Daniel Buchner, Cherie Duncan, John Toohey, Ron Kreutzer, and Stephen Curran

by Markus Sabadello, Kyle Den Hartog, Christian Lundkvist, Cedric Franz, Alberto Elias, Andrew Hughes, John Jordan & Dmitri Zagidulin

By Nate Otto & Kim Hamilton Duffy

By Moses Ma, Claire Rumore, Dan Gisolfi, Wes Kussmaul & Dan Greening (Senex Rex)

Complete Rebooting the Web of Trust Listing

Complete Rebooting the Web of Trust Listing

License

rwot6-santabarbara's People

Contributors

Stargazers

Watchers

Forkers

rwot6-santabarbara's Issues

Recommend Projects

Recommend Topics

Recommend Org