flip-fest
flip-fest copied to clipboard
onflow
New Standard: Decentralized identifiers (DIDs) on Flow
👋 If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!
Description (Problem Statement)
Decentralized identifiers (DIDs) are a form of self-sovereign identifiers that aim for a standard interoperable way of identifying and authenticating subjects inside decentralized systems.
From W3C: Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.
Use cases: https://www.w3.org/TR/did-use-cases/
The Verifiable Data Registry in the image above would be Flow. All other components need to be defined/provided by authors.
This issue is meant to invite any and all who may be working with the DID specification, to provide these components for Flow-based DID subjects, the most obvious being Flow accounts, but this could also be applied to individual resources!
Flow could benefit from dedicated DID infrastructure for interoperating Flow identities with services outside of Flow, such as decentralized data storage and credential verification systems.
Experience Required
- Familiarity with DIDs and SPKI
- Good understanding of Flow's account and keys system
Minimum Feature Set (Acceptance Criteria)
- Define the Flow DID (url)
- Define the scope of a Flow DID document
- Create a DID issuer (service) for holders of Flow accounts (e.g. a set of public key(s))
- Create a DID document resolver (service) for Flow-based DIDs
Extension Feature Set (Optional)
This issue does not include or require the creation of a wallet for storing/verifying DIDs.
Milestone Requirements
- Implement a MVP of the DID document resolver service for Flow accounts
- Implement a MVP of the DID issuer service for Flow account holders. (Includes methods for updating DID document)
- E2E test authenticating with a DID-based service using Flow DID document
- E2E test securely updating a Flow-based DID document
Software Requirements
Maintainability
- The tools or libraries used to construct the solution should be well-vetted and well-maintained.
- Code should be written in a way that's easily extensible to new functionality and semantic enough for open-source developers to contribute to.
Testing
- All core logic should have accompanying unit tests.
- There should be an end-to-end (E2E) test for each feature implemented.
Other Requirements
Miscellaneous
- Flow users may want to retain anonymity, or at least plausible deniability that a particular Flow account is NOT attached to the corresponding DID document.
Documentation
- The following pieces of documentation need to be completed alongside the code for a successful submission:
- Flow DID URL definition should be documented
- Flow DID document should be documented
- Methods for updating / modifying Flow-based DID documents should be documented
Judging Criteria
- For all projects, technical & high-level judging criteria apply.
- System is secure and handles edge-cases.
Resources
- https://www.w3.org/TR/did-core/
- https://www.w3.org/TR/did-use-cases/
- https://www.w3.org/TR/did-imp-guide/
- https://en.wikipedia.org/wiki/Decentralized_identifiers
- https://developers.ceramic.network/authentication/nft-did/method/
DID services diagram at-a-glance:
Hello there. Oh this is a good one. Mackenzie here. 🏄🏼♂️ I'm part of the Developer Experience team at Flow. Glad you're checking out this issue. I can help answer any questions you might have about what you see here, and if you decide to take this on, I'll be your primary point of contact for you or your team.
Please add your comments/questions here, or find me on the Flow Discord (mack)
Happy hacking! 🚀
I know the details of Flow and Ceramic. I'm interested in this
Awesome! Have you taken a look at https://www.hackerearth.com/challenges/hackathon/flip-fest/custom-tab/getting-started/#Getting%20Started ?
Do you have any questions about the (t)ask? 🙂
@aturX Awesome! Let us know if we can assist with your application to the hackathon, or anything else!
Should we abandon this idea?
Required reading for anyone interested in DIDs https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html
Important comments on the DID specification from Google, Microsoft and the W3C. Are their (Google/MS) critical comments objective? Or, could they be attempting to undermine an effort to remove centralized control over 'identities' on the web, over which they certainly have a monopoly (alongside Facebook et. al.)?
Notably (given many DID methods rely on PoW chains):
"We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the Ethical Web Sustainability principle."
@10thfloor this is kind of interesting. I'm not sure I get it yet... what do people use DIDs for currently? The W3C doc did list a few but I guess my question is: why is it not more common?
Are the contents & capabilities of the DID document wide open, as a matter of standard? It seems like there's a lot of ways to implement DID?
It's my understanding that DIDs are (usually) a way to attach metadata to a set of public/private keys. The primary motivation for their development being the proliferation of systems (such as blockchains) that identify individual accounts in such a way.
The spec isn't limited to keypairs, but this is afaik the most common use-case. What a DID should allow is keypair-based identities that are interoperable and user controlled ie Your keypair-based identity isn't owned by the system which created it. The DID and supporting 'DID method' for retrieval and modification providing a user-controlled interface to the underlying issuing system, and a means for other systems to verify the provenance of the DID, enabling authentication ... etc.
To answer your question, while I am by no means authoritative when it comes to this subject, my impression about why DIDs are not more widely used is because the spec is immature (and perhaps fundamentally flawed, as per the discussion above).
However, there are many companies building out DID infrastructure, and DIDs form the basis of some interesting innovation. Here are the most prominent examples I can think of, in the 'DID space', that are worth checking out (and there are certainly more than this, but I have these in my bookmarks : )).
- https://ceramic.network/
- https://fission.codes/
- https://nuid.io/
- https://trinsic.id/
- https://www.ibm.com/blockchain/solutions/identity
That's fascinating... there's a response to those claims later in the thread, which advances the idea that a diversity of standards for DIDs is generally helpful, since there's a lot of use cases we probably haven't imagined yet.
As to your question of whether to abandon this spec, I guess we should consider the question of what value an additional DID spec/implementation would bring. What kind of things would need to be included to make a useful/adoptable DID framework?
My thinking is that in web2, the IDs are attached to organizations, each with a set of guarantees, which makes them useful and understandable. Each ecosystem has value - if you have an email account, you get a mailbox. you can tweet with your twitter account, etc. It's really easy to understand the limitations & properties of each ecosystem: passport IDs, for example, are for the most part unique. And most importantly, web2 so far seems to work well enough - it's so easy to get an email. So to beat that, someone would need to make a DID ecosystem which is generally useful, or address a niche that isn't well-served by web2 currently? I guess that's hard to do.
In a sense, it seems like the best case right now is to go ahead and build general specs, and to make it easy enough to use that someone will come along and build a killer app on it :)
Ah... this link is super insightful (the W3C DID registry of all the stuff... I like the Tezos and Sol DID specs) https://www.w3.org/TR/did-spec-registries/#did-methods
For this topic, would we consider storing the documents on-chain? or somewhere off-chain, like on Ceramic?
@10thfloor Maybe I can officially work on this?
Team FlashyTigers, consisting of me (currently)
It might be interesting to make an extensible registrar (like ENS or Solana Naming Service), which would issue both human-readable and address-type names. These documents would be stored on Flow, but there would ALSO be a way to extend the registrar to have it refer to documents elsewhere (Ceramic, etc). There would be mechanisms for updating the DID documents as well (so basically, at the end we'd have another entry in the w3 registry
We'll also implement a basic client to interact with the registry :)
team ifesa can help, I need eip1812 in flow, https://ifesa.medium.com/did-nft-metadata-ownership-c0c30669d393
So I'm not sure if I can actually use Ceramic with Flow... it seems like the implementation of Ceramic rn is built on the idea of verifying signatures in this particular way (so you'd have to decrypt something to verify your identity).
So.. what can we do? Continue using Ceramic
- We can try to implement some compatible providers (but this seems unlikely). Right now, the Ceramic-native DID is used to authenticate to documents (and no other type can do it). Unfortunately, this type requires us to implement some providers of this format! So, we'd either have to enable some kind of decryption ability (to use Flow keys directly), or generate some deterministic seeds (from which Ceramic will generate some keys).
- We can modify Ceramic client/core (this seems also very hard). Alternatively, we can go deeper into Ceramic (at which point, it might stop being Ceramic). Why do we really need the JWS/JWE abilities? It seems like these are used to verify some structure on IPFS, and it might be possible to change the implementation.
Don't use Ceramic
- We can go back to the basic data storage provided by IPFS, and have the simple solution of "pointing" to them from Flow. This seems most doable and the added benefit is we get to keep our key authentication strategy. However, in order to get cross-blockchain compatibility, we'd have to implement some of Ceramic's functionalities (signature-based linking, etc) ourselves.
tl;dr -- going to try the third solution! Just point to DID docs on IPFS
I was just reading on this, I think this one can fit somehow to integration with flow.
https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-79/CIP-79.md
@mwufi Just waiting to hear back from Blocto about how they are handling signature verification, and why their signatires are not deterministic. Any other progress this week?
oh! not so much, but i'm contemplating doing it all on flow! the document would only require storing a few keys/signatures (like Ceramic), but resolve would expand that out into JSON. maybe this weekend
Hi guys, IFESA spent most of the last 3 to 4 weeks doing this , we'll get going for Flow next week
https://ifesa.medium.com/ics23-vector-commitments-in-cosmos-sdk-370b1ae306ad
Hi guys, IFESA spent most of the last 3 to 4 weeks doing this , we'll get going for Flow next week
https://ifesa.medium.com/ics23-vector-commitments-in-cosmos-sdk-370b1ae306ad
Awesome! Let us know when/if you need any support.
Hello!! I did a writeup of my approach here!!
let me know your thoughts --
Currently trying to make the demo look good :)
Looks good.
Here is the Cadence ICS23 Vector Commitments (not tested, and there are few changes to be made regarding concat) https://github.com/Electronic-Signatures-Industries/ancon-protocol/blob/4a073fda9c76f5e165b04f2fe3ff9a576cade2ec/flow/atlantico/ics23.cdc
It will thought only work from proofs generated from Cosmos SDK blockchains or Tendermint if used standalone. Ideally, to be able to do easier cross chain messsaging we will need a IBC Protocol light client. That + DID implementation and we get Flow connected to any chain
Wow, looks good
behind the scenes, this turns into did:flow:0xe64d0c52f286f42622abbeba9fe179dff0b99c40535b1910124b9227d2ccd785
Good day @mwufi!
Thanks so much for all your hardwork & participation. In order to finalize winners & prepare for prize payout, we'll need the following actions from your end.
Please provide the following information by Nov 17, 2021, (in this GH Issue is fine):
1. Team Information
- Team Members Information - Github Username + Email Contact + Percentage of prize allocation (total should = 100%)
- All mentioned members MUST react to the post with a 👍 which will act as confirmation that the information is correct, or a 👎 to indicate that the information is not correct.
- We will be reaching out via e-mail
🎖IMPORTANT: We will only proceed with prize payouts once all members have confirmed with 👍 on the post.
2. Video Demo (optional)
- Please provide a 5-minute video demo to be featured & showcased in the FLIP Fest Closing Ceremonies
- Link format & Downloadable (eg. Google Drive, Vimeo)
- Content Format (Problem Statement, your work / how you solved it, final outcome)
We will be hosting Closing Ceremonies on November 23rd, 8AM PT where we'll having closing remarks from Dete & will be announcing the winners! I'll share the details here before Nov 17.
Hey folks,
We've received and reviewed over 82 submissions! What an amazing community on Flow! To commemorate all the hard work done, we have finalized winners and will be announcing them during our Closing Ceremony on Nov 23rd, 8AM PT. Be sure to join us - there may be some attendance prizes & a keynote from our CTO, Dete 😉!
RSVP here so you don't miss out! See you then!
Hi @kimcodeashian ! Didn't see this until today -- My team was only me: so mwufi ([email protected]) 100%!
Uh.. would you like a video demo?
If you'd like to share one that'd be great - but it's up to you. Might be a bit too late for closing ceremonies but we'll host it up on our channel in a playlist 👍