Drill down the project and break it into pieces

[satazor]

This issue serves as starting point to kickstart the project.

• Re-read about the three pillars, DID + Verifiable Claims + DID auth, and decompose them in libraries that we can glue together.
• Build the IDM sandbox both in terms of UI and its postmessage API, including sessions, signing, and so on
• Think about stuff that we can build on top of the Identity. For instance, how can a DApp retrieve up-to-date information about an identity that already interacted with it, such as an updated profile picture or even the name?

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]

Would a Google Document suit better to collaborate?

[aschmahmann]

@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]

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]

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

[pgte]

Added @jimpick to the identity team.

[pgte]

@satazor do you have a deadline for this?

[satazor]

I want to have a draft early next week!

[pgte]

I suggest that you do the following:

• create a first draft of that document (I suggest google docs)
• post it here
• give us some time to review it, adding comments to the doc
• you set up a meeting a few days later (fixed time in CET afternoon, to whoever can come) for us to review it together

Sounds good?

[jimpick]

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

[oed]

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]

@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]

@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]

@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]

@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]

//cc @jonnycrunch

[oed]

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]

@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:

• IPNS-style record with custom validator
  • There is an update key U that users can publish the next version of the DID to IPNS[U] = DID'. If there exists a record IPNS[U] then the current record is out of date.
  • If there is exactly one update published then the update can be used, however if there is more than one update then flag that the key has been compromised. Figuring out which keys to use is a problem 2 issue.
  • Having a multi-writer IPNS would also solve this without needing a custom validator
  • 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)

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:

• A centralized trusted authority that is the arbiter of who is who (e.g. a government or employer)
• 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

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]

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]

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]

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:

• Iterate on the document and improve it based on feedback
• Assign each point to a person based on what they are interested in contributing

[satazor]

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]

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]

@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]

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