Skip to content
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

New Standard: Decentralized identifiers (DIDs) on Flow - Milestone 4 #114

Merged
merged 1 commit into from
Nov 16, 2021

Conversation

mwufi
Copy link

@mwufi mwufi commented Oct 31, 2021

New Standard: Decentralized identifiers (DIDs) on Flow - Milestone 4

Description

This PR is for issue #17 (#17)

Submission Links & Documents

Notion Blog

image

Demo App Walkthrough

You can modify the DID contents by changing the metadata!

Live Demo on netlify

image

image

Github repo

Requirements Check

  • Have have you met the milestone requirements? YES
  • Have you included tests (if applicable)? YES
  • Have you met the contribution guidelines of the repos you have submitted code to (if applicable)? YES
  • If this is the last milestone: YES

Other Details

  • Is there anything specific you'd like the PoC to know or review for? NO
  • Are there other references, documentation, or relevant artificats to mention for this PR (ie. external links to justify design decisions, etc.)? NO

@10thfloor
Copy link
Contributor

Awesome!!

Copy link

@gregsantos gregsantos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Successfully tested securely updating a Flow-based DID document 💥
Congratulations on completing Milestone 4!

@JeffreyDoyle
Copy link
Member

Awesome demo @mwufi ! Really great stuff here :)

@srinjoyc srinjoyc merged commit 9b5ff06 into onflow:main Nov 16, 2021
@10thfloor
Copy link
Contributor

10thfloor commented Nov 25, 2021

@mwufi Thanks for your submission, we wanted to provide you with a final round of feedback, to help guide you if you are considering continuing to work on the project.

Completeness:

The project is mostly complete, and fulfills the requirement of creating a POC for producing DIDs using Flow. We would have liked to see a more complete backend.js with some code for returning a JWS or JWT encoded DID like you mentioned, but the method you provided was enough for a proof of concept.

Scope:

Overall the scope of what you attempted was ambitious (that’s a good thing). There was no requirement to create a name service for Flow users. As there is already an existing Flow name service (FlowNS), we wont be able to support this project as an alternative, as it might cause confusion.

Next steps:

We would love to see you continue working on this project, and will be able to offer some ongoing support if you decide to take the following direction, while re-using as much of the work you’ve already done:

Simplify the DID itself, and remove the name-service functionality.

  • It’s important that you remove any mention or features in progress that refer to ENS, as the project in it’s current form does not adequately support ENS identifiers on Flow. Flow cannot verify ownership of an ENS domain
  • More so, Flow can't track ownership changes for ENS domains. This means that the contract can only verify that a user was the first to register an ENS domain on Flow, but cannot attest to ownership of the actual underlying domain. This poses a security risk; it may mislead client applications into thinking that a user controls an ENS domain that they do not own based on their Flow DID.
  • There is already an ENS implementation for DIDs being proposed here: https://github.com/veramolabs/did-ens-spec
  • The DID implementation guide recommends to avoid allowing users to control the structure of the DID suffix, explained here: https://www.w3.org/TR/did-imp-guide/#did-syntax Your implementation technically allows for arbitrary string input that, although hashed, can be used to grind vanity IDs

After looking at DID implementations on other blockchains like Ethereum, Solana and NEAR (inc. links), we think it's possible to simplify your solution to serve a wider degree of use cases on Flow. In short, by using resource interfaces and the security properties of the Cadence account model, it should be possible to attach a DID to any resource (e.g. an NFT) on Flow. We'll follow up with more feedback and details related to this point.

To create account DIDs for Flow, (which could then be extended to include names or NFTs as you imagined) examine:
https://www.w3.org/TR/did-spec-registries/#blockchainaccountid
https://www.w3.org/TR/did-spec-registries/#did-methods (Specifically the DID specifications submitted by well-know blockchains like Ethereum or Solana)
https://github.com/identity-com/sol-did.

Thanks again for your efforts. We hope you’ll decide to build on what you learned, and will continue to help us build out DID infrastructure for Flow, based on the suggestions we’ve made above.
If you have any questions about the feedback above feel free to reach out to the team.

@mwufi
Copy link
Author

mwufi commented Nov 25, 2021

@10thfloor Thanks a lot for the additional feedback!! I definitely think there's going to be some iteration before we identify the right niche for this implementation. Do you mind if I reach out on Discord? :D

  • Decoupling name-service and DID functionality - I like what you say about decoupling the name-service and DID functionality. Right now, the name-service aspect is like an elementary version of what is offered by projects like Find and FlowNS. It very much is an implementation detail here... so if there's better ways of implementing DIDs (ie, using resource interfaces? and also different addressing), I think we'd 100% opt for that. Let's discuss!

  • DIDs for every resource - This is a bit of a milestone! Ideally, the DID system would support creating millions of DIDs, and creating one would be so easy&cheap that everything will have a DID. Originally, I was thinking something along the lines of NameTokens being owned (ie, like KittyHats), but still able to be stored in a lookup table -- but I haven't made it work for this demo yet. I think Find (by bjartek) is looking at something similar, but not from the DID perspective -- we might be discussing next week on how to synergize...

  • Using DIDs - part of the weakness of the current demo has to do with the keypairs. Right now, it takes the first key of the authAccount as the DID public key, but we need to make this more robust+integrated with the Cadence account model. I'd love some help on this, actually!

Overall, I think the fundamental architecture could be improved -- planning to revamp it in a week or two. The next iteration will probably support better keypair management, NFT-ownership, and more structured off-chain data!

In short, by using resource interfaces and the security properties of the Cadence account model, it should be possible to attach a DID to any resource (e.g. an NFT) on Flow. We'll follow up with more feedback and details related to this point.

Maybe we can start some kind of Discord chat about DIDs!

Looking forward to moving this forward!! Also thanks for your help!! (literally went from 0 knowledge of DIDs to... a tiny nonzero quantity haha)

@mwufi
Copy link
Author

mwufi commented Nov 25, 2021

Will think about interfaces.... I think it will be game changing to have it be more extensible.. happy thanksgiving, everyone!

@fotescodev
Copy link

Why did we stop?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants