search

ipfs-shipyard / pm-idm

IDM project management repository
MIT License
63 stars 9 forks source link

Drill down the project and break it into pieces #2

Closed satazor closed 5 years ago

satazor commented 5 years ago

This issue serves as starting point to kickstart the project.

All of this will require a thoughtful analysis of the whole concept from top to bottom. I would love to do this collaboratively with anyone that is interested.

//cc @daviddahl @aschmahmann @pgte @dirkmc

RFC Peer-Star-Identity

satazor commented 5 years ago

Would a Google Document suit better to collaborate?

aschmahmann commented 5 years ago

@satazor Not sure if a Google Doc is better for this, but I think it's easier for managing multiple streams of thought, while GitHub issues are good for discussing one particular issue/stream of thought. So if you'd like to tackle the different identity components separately then my vote is Google doc, if you'd like it to be one bigger discussion then here is good.

satazor commented 5 years ago

I think having a Google Doc would be better to agree on the hierarchy of components first with small descriptions of what they would do and where they would fit in the overall picture. Then we would open GH issues for each of those components where a more in-depth discussion happen, such as their APIs.

Does that sound good?

satazor commented 5 years ago

Couldn’t assign this to Jim so I’m ccing instead //cc @jimpick

pgte commented 5 years ago

Added @jimpick to the identity team.

pgte commented 5 years ago

@satazor do you have a deadline for this?

satazor commented 5 years ago

I want to have a draft early next week!

pgte commented 5 years ago

I suggest that you do the following:

Sounds good?

jimpick commented 5 years ago

I just noticed my name mentioned ... so I added myself to the list of assignees...

oed commented 5 years ago

We (3Box, former uPort) are working on a DID method using ipfs. Right now we are focusing on making it more modular. One component that we are creating that you might be interested in we will call ipfs-did-document which basically encodes a DID Document as an ipfs object. The hash of the object becomes your Method-specific Identifier. The document specifies your public keys as well as a the method used for key revocation and rotation (usually some kind of blockchain system). The idea is to make it very abstract so that it can be used for any DID method based on ipfs.

Definitely let me know if we should sync more on it!

dirkmc commented 5 years ago

@oed can you link us to a source code repo? I'm curious how you address the requirement that the DID should be in the document itself, given that IPFS is content addressed

oed commented 5 years ago

@dirkmc sure! https://github.com/3box/js-ipfs-did-document To answer your question: basically the DID is not included in the document. However there's a function cidToDocument which takes the document an adds the DID in the right places. This function would then be used by any DID resolver for the DID methods that use this module.

satazor commented 5 years ago

@oed This is very interesting!

One question: Given a DID based on ipfs-did-document, how do you retrieve to most up to date cid of the document? Are u planning on implementing a DID method on top of IPFS that uses IPNS? Or use a blockchain to store the latest cid?

As it seems, I may use this module to implement the IPID spec, which uses IPNS. The way it works is that your IPNS key becomes your DID. Unfortunately, this has a huge downside: in case the IPNS key is compromised, the whole identity is compromised and can't be recovered. Any thoughts on how to solve this without having a blockain? (if that's even possible).

oed commented 5 years ago

@satazor We are planning on using a blockchain, most likely ethereum for now.

I've seen IPID, but yeah that seems like a huge downside. AFAIK it's not possible to do this without a blockchain since you need a way of publicly and permanently revoke a key.

satazor commented 5 years ago

//cc @jonnycrunch

oed commented 5 years ago

Hm, maybe it would be possible to use one time signatures? So that each time you publish a new DID document you have to create a new "update key". Not sure if you can use these kinds of keys in IPNS. Either way it seems like there could be a data withholding problem for updates. Maybe you'd have to specify a location in your DID doc where you publish updates?

Edit: Nevermind, this of course breaks if the secret key is stolen.

aschmahmann commented 5 years ago

@oed @satazor This might be a bit long, but the TLDR is blockchains don't solve the actual revocation problem and for what blockchains can be useful for IPNS (or something similar) could be similarly useful.

Unfortunately, this has a huge downside: in case the IPNS key is compromised, the whole identity is compromised and can't be recovered. Any thoughts on how to solve this without having a blockain? (if that's even possible).

I think there are two different problems here:

  1. How do I know that the keys that I'm using are out of date?
  2. What is the new key and how do I know it actually belongs to the correct party?

Blockchains can help with problem 1, since you are able to advertise to the world that a key has been revoked. However, there are IPNS-style alternatives that can similarly solve problem 1 albeit with different security guarantees such as:

The solutions to problem 2 can be very tricky, but most of the solutions that I've seen require some "authorized group" to restore access to your keys. Two common examples are:

It is worth noting that if we wanted to, we could use our solution to problem 2 to help with problem 1. For example, if I can only change my DID if my friend group approves then we can use a construct that allows my friends to assemble U and that group can collectively be trusted to only push one change to IPNS[U]. However, requiring your "authorized group" to approve every DID change a user wants to make might be too cumbersome, therefore having separate solutions to problem 1 might be useful.

oed commented 5 years ago

The security tradeoff here with a blockchain is related to availability, if an attacker can eclipse or distort a users' view of IPNS to see only one update instead of two then they are successful. Given that this is a forking attack some of the standard solutions to mitigate forking attacks can be employed (e.g. Keybase uses user tracking of keys, but any sort of embedding DIDs into other data to increase the amount of the network that needs to be forked is useful)

Does this basically means that you can sybil attack the DHT? Would like to better understand how that can be mitigated.

Some group signature or Shamir secret sharing scheme to allow n of m users/organizations that can be collectively work to restore a user's identity

We have been considering this for quite a while do deal with identity loss. We have a library for it even: sss-wasm

One thing that might be interesting is if you could rotate your DID document with a key that you control, but then you have a separate key in control of a group of friends that can override the rotations done by the key you control.

aschmahmann commented 5 years ago

Sorry for another long one folks 😅

Does this basically means that you can sybil attack the DHT? Would like to better understand how that can be mitigated.

Sybil attacks on the DHT are just one of the various possible attacks available. In reality any kindkey of attack on data availability causes you trouble. As an example, say we were using a PubSub-only style of IPNS with 100 users, three of whom are Alice, Bob and Mallory. Mallory can execute the following attack:

  1. Alice updates her key to A' and signs the update with her original key, A
  2. Alice pushes A' out to the network but not to Bob (maybe he's offline or maybe she only pushes to 5 random users)
  3. Mallory compromises A and advertises M' as an update to A and signs the update with A
  4. Mallory isolates Bob's network so that Bob only sees M' and not A' (could be by DoSing the users who know about A', manipulating the packets going through Bob's router to not go to parties who know about A', etc.)
  5. Mallory can now Man-in-the-Middle attack messages Bob sends to Alice

These tend to be mitigated by increasing the cost of step 4, the step which forks the network into A' the network with the "good" update and M' the network with the "bad" update.

For example, say Bob has some friends Charlie and David who both communicate with Alice. Charlie and David can both store objects in IPFS that have the latest keys of all their friends e.g. {Alice : A', Bob : B, Evan: E''') that is pointed at by some IPNS record Bob knows about. Mallory now needs to obstruct Bob's view of these objects that Charlie and David are updating in addition to obstructing Alice's update. Keybase does this for somewhat different reasons as described here (https://keybase.io/docs/server_security/following). A second similar approach works if Bob was sharing lots of documents with Alice and Charlie and they were both signing the updates to their files (updates managed by something like IPNS). Then if Mallory starts isolating Alice from Bob but not from Charlie, then Charlie as part of updating Bob on the latest version of the document will implicitly give Bob Alice's latest key.

The name of the game here is basically tainting, the more pieces of data you taint with A' the harder it becomes to stop Bob from seeing A'.

One thing that might be interesting is if you could rotate your DID document with a key that you control, but then you have a separate key in control of a group of friends that can override the rotations done by the key you control.

Absolutely, that's part of what I was referring to at the bottom of my post above. If you have two methods/keys that you are ok performing updates with, one less trusted key (yours) and one more trusted (your collective friends') then as long as people can detect misuse of the less trusted key (e.g. more than one message Key -> Key') they will know to go look for the more trusted key to arbitrate.

satazor commented 5 years ago

I have a first draft of the breakdown in markdown format here: https://gist.github.com/satazor/415244ecbe80f424ea51f403c24aa79a

It was easier for me to use markdown, but let me know if I should put it in a google document so that we can collaborate easier.

Have a look at it and please provide feedback. Next steps:

satazor commented 5 years ago

I've moved the document to google so that we can collaborate on it. I've sent an edit invitation to all members of the DDC Working group and @daviddahl & @jonnycrunch as well. Anyone else interested in contributing, please reach me out and I will give you permission as well. Nevertheless, the access to the document is public so everyone can read.

Here's the link: https://docs.google.com/document/d/1g0TjSPjEM4pryPwJTGhIeE4DBsj-VJpz_JqbfllJUgA

jonnycrunch commented 5 years ago

sorry I haven't been able to make the calls. Big problem really has to do with standards for interoperability. I have been involved with the w3C creds community group and unfortunately they are focused on the http protocol and don't want to replace it. They also are very much tied to JSON-LD, which doesn't scale (everyone hits the schema.org or w3c site for the @context. not to mention the issue with MiTM with DNS spoofing or that the url endpoint might change. I'll check out the doc and give some feedback. Best, jonny

dirkmc commented 5 years ago

@whyrusleeping @magik6k you may be interested in commenting on the document @satazor linked to as it relates to things we talked about with respect to IGIS and naming for filecoin

satazor commented 5 years ago

Going to close this issue as the document was created and reviewed. Thanks everyone for giving feedback!

I will be adding the link to the document in the README as part of #8