Decentralised identity (SPEC-458)

[matrixbot]

Submitted by @​matthew:matrix.org
Somehow we've got this far without a bug tracking replacing sydent and the Identity Service with a decentralised equivalent. There's been lots of discussion about this, talking about using existing decentralised identity systems or ledgers ranging from keybase, blockstack (onename), webfist, stellar.org, evernym, uport.me, namecoin, WebAuthn, WebID, Alpenhorn's anytrust model, etc. We haven't yet found a good solution for simply replacing the email->mxid mapping system of the current ISes with a decentralised one, given the problem of validating an email address in a decentralised manner, when emails themselves are inherently centralised to the SMTP servers responsible for that domain, and existing SMTP have very limited hooks for validating the identity of its users.

(Imported from https://matrix.org/jira/browse/SPEC-458)

[ara4n]

tarcus in HQ suggested https://openalias.org/ after my fosdem talk (https://fosdem.org/2017/schedule/event/matrix_future/) which certainly sounds quite interesting...

[ara4n]

someone in the audience also suggested indieauth during the talk.

there's also a new persona-like service called https://portier.github.io/ which might be relevant

[uniconstructor]

@ara4n I checked out OpenAlias project website and their repositories and discovered several major problems:

1. Almost zero developer activity in all OpenAlias repositories: https://github.com/openalias?tab=repositories
2. They have no solution or naming standard for blockchain apps: "...For other applications, Bitcoin for example, that prefix would be oa1:btc or whatever the developers choose. OpenAlias does not maintain a repository of prefixes at this stage, but may do so in future."
3. No clearly defined specification for project
4. OpenAlias is a side-project of Monero developers. it's not as open standard or protocol of any kind

If you need an open, reliable and well-designed solution for decentralized identity system - consider to use an existing open source p2p ecosystem: libp2p.io. It is a toolset developed by Protocol Labs team.

Now the main part: what parts of this this toolset you can use, and how can it help you with you goals:

1. You need "a good solution for simply replacing the email->mxid mapping system" - it is about naming and addresing.
   Check out multiaddr: https://github.com/multiformats/multiaddr
   Multiaddr is a part of more global Multiformats project: https://multiformats.io/
   It can help you to create a protocol/application/format agnostic identity storage and allow you to use any persistance technology that you like (DNS-record/blockchain transaction/IPFS ond so on)
2. "There's been lots of discussion about this, talking about using existing decentralised identity systems or ledgers ranging from keybase, blockstack (onename), webfist, stellar.org, evernym, uport.me, namecoin, WebAuthn, WebID, Alpenhorn's anytrust model, etc" - you don't have to choose - use all of them, and convert identity data between any formats. Multicodec can be useful for this: https://github.com/multiformats/multicodec . Multicodec provides public registry of existing encoding formats sou you are not have to reinvent the wheel: https://github.com/multiformats/multicodec/blob/master/table.csv. If we talking about implementing logic of conversion identity data between different formats - GraphQL is a good choice for this too.
3. You need an ability to request, issue and verify claims of any kind. W3C have a working draft for this, named "Verifiable Claims": https://www.w3.org/TR/verifiable-claims-data-model/
   As a developer you often need a detailed instruction about how to implement something (like "zero knowlenge proof") using "the right way". I think w3c standards - is a best thing that we have for this.
4. globally accessible, up-to-date public registry of public identity information: IPFS is a perfect solution for this: https://ipfs.io
   IPFS + (Any popular blockchain) = absolutely immutable storage for any important file.
5. Finaly, and most important - you need a common way to link several identity accounts together. IPLD will be perfect solution here: https://ipld.io/

That's all for now - I hope you that some of this projects/ideas will be useful for building decentralized Matrix-based identity system.

You doing a great project. Have fun.

[jh72de]

To quote @xuhcc'comment on #246:
"There is a draft of W3C standard for decentralized identifiers: https://w3c.github.io/did-core/"

[AdamEunson]

It may be worth getting in touch with the team at the IOTA Foundation. They're working on their open source Digital Identity protocols that are built based on the W3C standards for DIDs and VCs. They're working on DIDComms as well, pretty sure auth is in the roadmap somewhere, if not already being implemented.
https://github.com/iotaledger/identity.rs

[GentleRV]

Why not use the local database to store users and their profiles even with 2fa athentification
All decentralized locations are sources for hacking
Before I installed rocketchat and had no issues with it, the look from synapse change my mind.
Also in rocket chat was easy to connect my home jitsi server without any issues, with matrix I already see that i need to install riot on my server to make it possible.

[ShadowJonathan]

I just came across this, "Petnames", which seems to do away with global DID naming and instead introduce relative names to users, possibly backed by a key, on local scale: https://spritely.institute/news/two-petnames-papers-are-released.html

[izN8nu6RyeneG5XnBoBgyRMVGH6H43WF]

@jh72de said:
There is a draft of W3C standard for decentralized identifiers: https://w3c.github.io/did-core/

This recommendation was recently approved. I think we should go with this for two reasons:

1. It's the standard, so a protocol as general purpose as Matrix ought to follow established standards for interoperability reasons, and
2. W3C DIDs are probably generic enough for any conceivable Matrix DID use case.

Note there are two degrees of "resolution" or "mapping" of DIDs:

1. "Mapping" of human-readable identifiers to DIDs. A solution for this is forthcoming, and this is out of scope of the DID spec. This may even be out of scope for the Matrix spec, unless we want to e.g. integrate this into Matrix Identity Services.
2. DID resolution, which resolves a DID to a DID document containing authentication information and other metadata. The DID spec states the way to handle this is with a DID method. We would probably specify this "Matrix" DID method in the Matrix spec.

That said, what is the scope of this issue? It seems very similar to #246, which has much more discussion.

[fadyanwar]

@jh72de said:
There is a draft of W3C standard for decentralized identifiers: https://w3c.github.io/did-core/

This recommendation was recently approved.

This is very interesting, are you aware of any ongoing implementations for this?

[izN8nu6RyeneG5XnBoBgyRMVGH6H43WF]

@fadyanwar said:
This is very interesting, are you aware of any ongoing implementations for this?

Note that the implementation is for a DID method, a partial protocol for identity management that meets certain requirements (DID Core is basically a protocol for writing decentralized identity protocols, combined with identifier syntax). We haven't formally written one for Matrix, so there's not much to implement yet. A DID or DID Document syntax validator might be useful, but I couldn't find any single-purpose libraries for this. We may be able to extract this from a more elaborate framework built on DID, such as SideTree, which has a reference implementation.

Although the DID Implementation Guide recommends using existing methods if available, I would recommend that we write (or at least "name", by registering with W3C) our own method, so that the Matrix Foundation keeps control over the entire Matrix protocol, including our method.

This means we'll probably have to write our own implementation, maybe as so:

1. Write DID method(s) that describes the existing Matrix identity system. This can be done, since DID semantics also permit describing centralized and federated systems. This method should be maintained as part of the Matrix spec.
2. Submit this method to the W3C DID method registry, to reserve a method name, e.g. "matrix".
3. Draft an amended method to extend the original, which incorporates highest priority concerns, e.g. account portability. This would include describing the verifiable data registry for decentralized identities.
4. Implement, revise, iterate, then submit amendments to the registry as we make changes to the identity system.

[imax9000]

Thanks to Bluesky, DIDs are getting some attention. IMO, a good starting point would be to at least define DID->mxid mapping. That would allow people to declare their mxid using any existing method (including did:web). Clients of course will have only a subset of all possible methods supported, but a manual lookup can bridge this gap in the context of inviting someone into a room.

(Coming to think of it, did:web may end up being good enough for use by default. E.g., did:web:matrix.org/user/${username} requires nothing more than a simple HTTP handler that returns a DID document)