-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decentralised identity (SPEC-458) #203
Comments
tarcus in HQ suggested https://openalias.org/ after my fosdem talk (https://fosdem.org/2017/schedule/event/matrix_future/) which certainly sounds quite interesting... |
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 |
@ara4n I checked out OpenAlias project website and their repositories and discovered several major problems:
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:
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. |
To quote @xuhcc'comment on #246: |
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. |
Why not use the local database to store users and their profiles even with 2fa athentification |
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 |
This recommendation was recently approved. I think we should go with this for two reasons:
Note there are two degrees of "resolution" or "mapping" of DIDs:
That said, what is the scope of this issue? It seems very similar to #246, which has much more discussion. |
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:
|
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 (Coming to think of it, |
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)
The text was updated successfully, but these errors were encountered: