summaryrefslogtreecommitdiff
path: root/transcripts/rebooting-web-of-trust/2019-prague/groups.mdwn
blob: 86eebd363aa9543f0fec419425293c36dbb6ffac (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Group 1: Agents

We talked about minimal requirements for ... a different set of protocols and other implementations, and we asked the question, what's out there for being able to create a minimal requirement for... Are we able to map this and pull it all down into a minimal requirement architecture for an agent without having to buy into the whole stack? What about building an agent for a smartphone or a feature phone, and then move on from there? Do you need a blockchain for that? Someone also talked about crypto identifiers. We also would like interoperable agents using math. What would an agent be, and how does it interoperate?

# Group 2

We had three hard problems. The first one is varying complexity while ensuring security. Those two things are diabolically opposed. Core useability metaphors that foster understanding for everyone. The last one is user centricity, not technical feasibility.

# Group 3: Context adaptive rubrics for assessing verifiable credentials and verifiable claims

The idea is that you can create a rubric but different characteristics or details might apply to different groups with different interests. Have ways of assisting people in assessing their participation in these things or choosing platforms. Have a framework to help assess these things.

# Group 4: Verifiable credential threat modeling

We had a mixture of fascinating topics. There were several like proof-of-human uniqueness. The theme that we coallesced on was verifiable credential threat modeling. There is a lot of risk that if we don't think about carefully what could be abused in the ecosystem, we'll be caught embarrassed.

# Group 5: Data hubs for architecture

We had an interesting discussion about architecture. There are some parts of architecture really missing. In the things that we talked about, we started expanding scope and talking about larger and larger architectures. At the end, we decided to narrow it down to one architecture. This is a data hub architecture: hwere do we store our stuff and what does that look like? Secure data hubs, solid pods, etc. Trying to come up with requirements around those, dangers and clear no-go areas around how do we store with, how do we claim to prevent vendor lock-in with the things where we are effectively storing our most private data.

# Group 6: Trustyness across value chains or an ecosystem

We had a diverse group. We looked at trust certificants, device trust, and then we decided that we need to look at trustyness across a value chain or ecosystem. Not only p2p but also like a supply chain or value chain. This applies to medical devices, doctors and patients, hospitals, how can we trust the entire data chain? There's also topics of custody- can we trust the wallet, is key management okay, identity theft in the system.

# Group 7: Generative identity

We came up with a single term to encompass everything that we wanted to talk about. It's generative identity, based on a 2006 paper of Generative Internet where the idea it is the end-to-end connectivity is a source of innovation. The problem is you have a problem of security as a balancing point and we want to restore the generative nature of the internet by using decentralized identity as a mechanism for security and take away the power of the aggregators. We need an identity meta-platform with rubrics and communication and key management and sharing hardware security modules, user experience, and reputation.

# Group 8: Really rebooting the web of trust

Our group talked about what the heck do we mean by web-of-trust, and actually breaking it down. There are three components. We agreed it's good to be rebooting the web of trust, because PGP is fundamentally broken. If you're going to do it right, you would start it out with-- a secure connection to an identity, identity attestation, trust worthiness which is how much can you trust an entity to do a specific thing. The right way to do this is to do a self-authenticating designator such as tor onion service which lets you know you're connecting to an identity, and identity attestion like pet names, and trustworthiness is by context like looking at verifiable credentials to trust someone to keep secrets or financial information.

# Group 9: Building blocks for reputation systems

Our focus ended up being, building blocks for reputation systems. It's not possible to have a singel global reputation system or score. The focus should be on a periodic table of elements for building blocks for building specific reputation systems which are generally culturally-specific, which are aware of local legal frameworks and take into account the organic ways that human reputation works. We need a general meta-framework for building reputation frameworks, but a single global unified one is not possible.

# Group 10

We had a robust debate about terminology. I'm going to talk about adoption. What about a plan or beta test to get this tech live in a new environment in new and small closed ways? We're not going to go to a country and immediately switch them all over, and their passports are now in the ledger and not physical or whatever. So the idea is to come up with identifiable ways of getting pilots live, getting adoption started so that we can learn and do proofs of concept for greater adoption. It's about getting this on the road, not just building a car but building it out there.

# Topic summary

These are the 10 of the topics that people brought to this conversation. We'll have a coffee break now. Find someone you don't know and ask them about their topic paper. Topic papers are how we get to know each other.