Replies: 13 comments 12 replies
-
|
Who is developing identity solutions for the Polkadot ecosystem? What are the areas of strength/focus of the teams building these solutions? How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration? How can we elevate the profile of the Polkadot ecosystem within groups like the W3C DID working group and the Decentralized Identity Foundation? |
Beta Was this translation helpful? Give feedback.
-
|
Identity systems become unethical when they link users activities online in ways the user does not expect, which includes pressuring users to give unnecessarily information or unnecessarily link their activities. As such, each identity system should fit exclusively into one of two categories: Single/special purpose identities should only really function for one domain of activity, like a login for some website, like a bank account or online discussion forum. As these only serve one purpose, these should avoid federating with identity systems that serve other purposes. Examples:
Multi/general purpose identities should provide only Sibel protections but remain unlinkability across different domain/purposes, usually meaning they require a ring or group VRF inside the OAuth-like component. Proof-of-personhood parties provide a classical example. As a related notion, ZCash or Monero UTXOs operate with a linkable ring signature, which one obtains by taking a ring VRF and fixing the VRF input. There do exist unethical services like Google single sign-on and Facebook connect that breach this boundary, by foisting a multi-purpose identity upon users. We can hope some GDPR++ shuts them down one day, but our goal is mostly just not to be like them. I'd consider github's single login less problematic, since folks use it almost purely professionally. Abuse remains a danger of course, especially with all the discord integrations, but whatever. I've never thought about stackexchange using one identity across their sites, again not perfect for privacy but good for building community, which matters too. Yes, it's safer if one chooses fancy crypto like ring VRFs over OAuth, but OAuth can be used narrowly, and passwords suck. In this case, we're discussing a single/special purpose identity exclusively for use in the governance, staking, and development of polkadot and its parachains. We maybe call this social or whatever but it seemingly exists purely to facilitate governance, staking, and development. We somewhat fall into the github "professional" exemption of course. In fact, our dots weighted voting mean dot holders exercise power, which changes the rules even more. We conversely face more pressure from attacks like spear phishing, attacks on devs' machines by compromising minor upstream packages (well NPM has grown famous for this, but cargo is not immune). In short, we should design identities to be as useful as possible for governance, staking, etc. of polkadot and its parachains, but not much use for anything unrelated. So what information do we actually need in governance? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, Jeff, this is a lot to chew on and I certainly have a lot more to learn about things like VRFs and how they can fit into this equation. It seems that you believe that it is out of Polkadot's scope to provide an interoperable identity primitive - is that fair to say? You do seem to acknowledge that multi-purpose identities have a place when it comes to building communities, even if that means sacrificing some privacies. I will admit that I don't have a fully formed picture in my mind, but I feel like I could imagine a world where multiple parachains implement common identity standards that allow users to opt-in to a range of multi-purpose identity solutions. Can privacy protocols allow users to selectively reveal attributes of these multi-purpose identities in order to interact with other systems that have a notion of identity? Even if these primitives/standards are not implemented at the level of the Polkadot relay chain, what should the role of the Polkadot community be in establishing and curating these standards in order to support the promise of interoperability? |
Beta Was this translation helpful? Give feedback.
-
|
Interoperable withing our own narrow-ish purposes of saying "I have X many dots staked until after date Y and I support doing Z." We should not encourage using the W3C's DID spec though, but presumably it'll just create implementation headaches anyways. I doubt substrate itself needs any identity support beyond the single purpose identity system of staked accounts and their powers used by its own governance, staking, etc. Although these represent users exercising financial power, we must still comply with the "right to be forgotten" so associations between accounts and personally identifying information, or even human readable information, should stay off-chain, on websites that could comply with take down requests. It's risky even to place commitments or hashes to personally identifying information on-chain. We might for example have an off-chain nick server where people register a nickname and can sign that it controls some staked account, so that nicks can safely be deleted in future. We'd make this nick database public including signatures, making archival possible by anyone, and we'd keep historical records offline, but since nicks never touch any chain they could still be "forgotten" under GDPR, without the E.U. forcing a hard fork upon polkadot's council members.
No. I argued "professional" and "power wielding" single purpose identities actually wind up being quite broad, but they still basically serve only one purpose. There is no ethical or legal-like reasoning behind this assertion, and it worsens GDPR risks, but it jives with a few realities: people often behave more tactfully in professional environments and want their professional work displayed, and security is improved by knowing how people wield their power over the network.
If we're discussing an identity system for the governance of polkadot and it parachains then any attributes could just be public. Gav considered some anonymous roles, but these constitute another distinct account. A real multi-purpose identity proves "X is my only account on domain Y" and ideally reveals nothing else. It should not sacrifice any privacy except by absolute necessity. As an example, proof-of-personhood parties reveal who participates by who turns up at the party, while others might even reveal who participates across the whole system (although even this risks violating GDPR). Any multi-purpose identity has two components, first some registration and credential issuance, and second credential usage. We know two sensible registration regimes, proof-of-personhood parties and anonymized usage of government issued identity documents. In my mind, there is nothing useful to prove from coin ownership since owning numerous almost dust accounts costs little. In both cases, credential usage requires a (second) zero-knowledge proof that some particular domain (vrf input) corresponds to a provided identity (vrf/vuf outout). If identities were registered on-chain then credential usage requires invoking roughly https://github.com/w3f/ring-vrf/ although proof-of-personhood parties avoided the chain entirely using hierarchical threshold group VRFs, as opposed to run VRFs. Any registration based off government issued ids requires implementing an open source verifier for government issued id, either by trusting SGX for deSibeling, or else as a zero-knoweldge proof of verifying some government issued id, like an RSA signature by an epassport. In both cases, one should navigate GDPR for deSibeling the government issued ids themselves somehow, which sounds messy.
A multi-purpose identity cannot do much beyond prove "X is my only account on domain Y" without violating users' reasonable privacy expectations. There is afaik never any reason for users to selectively reveal attributes in a multi-purpose identity scheme. We cannot of course prevent users from revealing identifying details themselves, like telling their nationality, claiming they earned a nursing degree, or say id X on domain A leaking that they control id Y on domain B, but.. An identity designed for multiple purposes should never expose support for users proving these things. It's maybe okay if multi-purpose identity based on a government issued ids could prove that users are over 18, although not sure if that's worth the effort. In that case, one should ideally "penalizes" domains for requesting the over 18 flag by requiring they restrict their entire TLD to over 18, which gets doable but annoying.
As a rule, there is little on-chain here except registration of threshold master issuing keys for group VRFs and/or some Merkle tree of commitments to users VRF keys. There do exist on-chain use cases like granting some staking power to each human participant, but this could be implemented case-by-case in wasm, especially given our longer term fancy crypto plans. |
Beta Was this translation helpful? Give feedback.
-
|
just wanna share this and create awareness of the current Grant application for a domain specific DID from Parami: w3f/Grants-Program#160 |
Beta Was this translation helpful? Give feedback.
-
|
I had a conversation with @miseenplace about this topic, which led to the creation of an Issue on the Substrate repo that relates to enhancing/abstracting FRAME's capabilities for the management of account data. |
Beta Was this translation helpful? Give feedback.
-
|
Does it mean that the goal of implementation of |
Beta Was this translation helpful? Give feedback.
-
|
We must avoid this obviously, presumably by discouraging or preventing non-governance activities from using the same identity infrastructure as polkadot and parachain governance. As a rule, polkadot and parachain governance should only care about staked dots, which breaks most non-governance applications anyways I guess. In the long run. I'd support non-governance applications looking into our ring VRF crate or similar for providing unique identities. In principle, applications should construct the ring of all accounts they care about is some well defined way, and then users can identify their account in the ring and provide a zkSNARK proving their identity. We've more clean up work to do there right now, but sassafras requires it, so it's progressing. Also, ring VRF only works for Jubjub-BSL12-377 keys, which polkadot does not currently support. And it uses the Poseidon hash function which substrate does not yet support. We might even adopt the v3 design that gives super fast proofs if we add some nifty features to the arkworks prover. As for other key types, we could do a bulletproofs prover for sr25519 keys, but the proofs would be massive and slow like Monero. We'd maybe use arkworks nonnative arithmetic instead, which slows down proofs, but keeps them small. At this point, you'll want to know how can a non-governance application can verify that dots being locked? I'd expect this happens by the user transferring dots to the parachain itself because the application really cannot much benefit from the lock if its controlled by relay chain stuff. This requires SPREE modules, which should work before most of this fancy zk stuff. In the short term, non-governance applications should just deploy their own custom identity infrastructure on their own parachain, and not worry what anyone else does. It's fine if this uses some shared code base of course, but identity for non-governance stuff should avoid message passing ala XCMP, and thus should not know what happens on other chains, including the relay chain. There are exceptions when multiple parachains are really one application, but that's probably a ways off. A a rule, there is not much point in merely receiving an XCMP message about some dots existing anyways since unless locked they could move right after that message goes out. You'll want a SPREE message that actually transfers them to an account on your parachain. |
Beta Was this translation helpful? Give feedback.
-
|
In short, if you need an identity of some sort now then the easiest fastest thing is to role you own, and ignore what everyone else does. This is perfectly fine. It only gets complicated when you want de-Sibel-ing properties from other chains. That'll take a while, but you probably do not much care. |
Beta Was this translation helpful? Give feedback.
-
|
What are the needs related to identity in the Polkadot ecosystem? The Parami team think that a rich preference profile(domain-specific attribute, might be off-chain data) can be binded to identity, thus allowing rich-feature apps. In most cases, an anonymous identiy system is needed for the application, like online advertising or coupon distribution. Who is developing identity solutions for the Polkadot ecosystem? We the Parami team is developing a decentralized id solution focusing online advertising. It will be a domain-specific identity solution. What are the areas of strength/focus of the teams building these solutions?
How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration?
|
Beta Was this translation helpful? Give feedback.
-
I'd like to address this point and follow up on some of the concerns that @burdges mentioned. I've worked with the W3C DID/VC specs for uPort and Evernym along with some other chains. From my perspective, a DID compliant pallet would be incredibly valuable but I think it should first be built as a simple resolver with very little integrated into other on-chain functionality. The main purpose of a blockchain in the W3C design is to act as a verifiable data registry for DIDs and potentially VC's that are issued. However, the metadata around these DIDs and VCs do not need to be made public on a blockchain. The issuance and verification of credentials can happen entirely off-chain. The only transactions that need to be recorded on-chain are the creation of a DID and sometimes revocations of VCs. Overall, nearly all transactional activity between W3C identities does not need to be on a blockchain as most of the time the blockchain is just being read during verifications such as checking the DID that issued a VC. For example, the existing Evernym product suite built on the Sovrin blockchain handles most interactions between identities in a directly peer-to-peer manner off-chain. Every interaction can be done with a different identifier. In their demos, a student would receive a diploma VC through DID 1#. They could then apply for a job with that proof of diploma through DID 2# that results in a proof of employment VC. They could then apply for a bank loan with their proof of employment VC using DID 3#. All three DIDs are controlled by the user through different key pairs. They can then selectively disclose information to different parties with techniques to avoid linking their separate identities. Naturally, there are technical challenges to consider but I think @burdges already did a good job of discussing anti-linking techniques in more detail. Coming back to what a DID-Pallet on Substrate could be, I think it should first be built as a way to build permissioned blockchains or dedicated parachains as stand-alone identity networks similar to Sovrin or ION which act primarily as verifiable data registries. The advantage that Polkadot/Substrate offers over others is a way to build stand-alone identity ecosystems that don't run the risk of becoming siloed long-term; i.e. verifiable data registries on different networks could co-exist and trustlessly communicate with one another. The DID pallet could also be paired with a module or maybe off-chain workers that provide additional functionality for peer-to-peer communication that happens between identities off-chain just as an implementation guide for developers starting out. Down the road, these identities can eventually be paired with other on-chain use-cases as they become more apparent. I'm personally interested in building identity systems on Polkadot in the future. However, I'm currently focused on a different project and I've only recently begun to learn and build on Substrate/Polkadot so take everything I say here with a grain of salt. That being said, I do think following the W3C specification is valuable because of the potential interoperability it provides for identities on Polkadot down the road. Large governments, corporations, and several public chains are all gravitating towards W3C as a common standard that is required for new identity systems and I wouldn't want this ecosystem to miss out. Once Polkadot has some basic DID/VC compliant components, it opens up room to participate in the standards discussion and put Substrate down as a framework for more projects to consider; this is most relevant for both permssioned and public blockchain projects that know they need DID identities in their solution but also need flexibility for future upgrades and features that aren't yet defined. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, made some edits to clean up the content and a few errors. |
Beta Was this translation helpful? Give feedback.
-
|
There are two simple-ish ethical identity system types, special purpose ones that identify users only to itself, like polkadots' own governance, and a general purpose ones that only deSibel users but permit identification to third parties, which is a service we can provide to third parties. In other words, identities should either intentionally not be interoperable, or else reveal basically nothing but uniqueness. There are massive ethical problems with users proving diploma or employment to third parties online. It'll inherently be abused when third parties can easily request such things and users can approve them without much thought. It'll also increase in discrimination. Also, there is no real value in proving a diploma or employment quickly and easily, since the only parties to whom users should provide that information are parties with whom the user builds a deep relationship, like employment, governments for immigration, borrowing large sums, etc. There is zero unlinkability in methods discussed by the W3C because complex attributes inherently link users and their suggestions cannot prove uniqueness without revealing all those attributes. And they mostly just proposed credentials that lacked even basic cryptographic unlinkability and/or leaked everything via side channels. In fact, one could build identity systems that achieve roughly the W3C's stated goals, but avoiding a disaster requires (a) a uniqueness prove without revealing attributes, and (b) appropriate restrictions on requested attributes. I attempted to explain (a) to the VC working group, but they never cared or never grasped the point. We cannot handle (b) purely technically because attribute requesters should say declare a fiduciary duty or simialr to the user to even request employment information. Avoid the W3C DID proposal all together honestly. The W3C never even understood the problem. |
Beta Was this translation helpful? Give feedback.
-
|
This is the approach we've taken for now, a simple id registry that maps keys to usernames. Definitely want to migrate to a more privacy preserving module whenever we all come to an agreement on what that should look like! I wouldn't go as far as saying W3C never understood the problem, but it definitely had enough holes that made us question whether it would actually work at scale as they hope. Mainly I don't see how it doesn't require trusting that that resolvers, which is why if we do go the DID route we should include how to implement a resolver as well, the substrate way. If we go another route, i'd be happy to test these things from a user/developer experience level, which might help us create a better standard than DID. I think we should also be considering multisignatures and proxy accounts. If combined with a good UI or key rotation process, it seems like it could potentially solve the identity privacy issue as well. i.e. if multisignature is done off chain with threshold signatures, could we not just use that? Then we couple that to a front end sdk and make that the standard for substrate identity. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the comments. That all makes sense and helps me understand where Substrate's DID pallet stands now. Overall, I think the W3C specs are approaching SSI mainly from a data model perspective and have left resolvers up to implementation or future standards to be created. It leaves a lot of room to either build a relatively centralized solution for enterprise/government or a purely decentralized solution. There's already a strong debate between the Sovrin/Evernym and DIF/Microsoft camps on how to standardize the resolution and communication process for SSI. Naturally, Microsoft is leaning more towards resolvers and data storage being handled by cloud agents. Substrate could provide some good alternatives to these existing camps while providing interoperability out of the box. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, it would be good to have us listed on this page once we have a DID method in development to show: https://w3c.github.io/did-spec-registries/#did-methods |
Beta Was this translation helpful? Give feedback.
-
|
We at Edgeware (and Webb) are definitely interested in extending the existing identity system. I myself am looking more into zero-knowledge tools for handling identities, reputations, and voting. Once the tooling comes around for recursive proofs systems + WASM it seems unlikely there will be computational challenges to building complex identity systems. One goal I have is to build composable primitives for applications that are interested in privacy/identity, allowing them to leverage various pallets or smart contracts that define reusable primitives. Does anyone know if the PICOPs work is planned to be open sourced as well? Interested to investigate what the process around that was. |
Beta Was this translation helpful? Give feedback.
-
|
In the following, I would like to answer @danforbes’s original questions, but also reflect on the discussion so far how we see this topic at KILT Protocol. What are the needs related to identity in the Polkadot ecosystem? Differentiating between the needs and limits of single-purpose vs multi-purpose identity systems helps a lot to put things into perspective. The Polkadot ecosystem will obviously need to accommodate both. Currently, the single purpose on-chain identities set up with the registrars for the governance works well for its purpose, but (as already proposed) the step forward here could be self signed attributes attested by the registrars stored off-chain (basically we call these credentials) to provide the “opportunity to be forgotten”. Sure, projects can replicate these approaches for their own needs as it is happening now but this leads to fragmentation (good for privacy, bad for the ecosystem). Moreover, one must already be very aware where they reuse their Substrate address if they linked it with on-chain attributes for governance. This can/must be supported by UI/UX, communication and knowledge sharing. As for a multi-purpose system, it would be ideal if a project could pop in some common identity module, be it rooted in DIDs (first) or some advanced proof-of-personhood based identity (later), and I think achieving this would be a nice goal for us as a community. Who is developing identity solutions for the Polkadot ecosystem? We at KILT are developing tools for managing revocable credentials which, amongst many other use cases, can be used for building attribute based digital personal identities (i.e. a set of characteristics describing certain properties about an individual). What are the areas of strength/focus of the teams building these solutions? Main features of KILT: SDK for creating, attesting, verifying revocable credentials, messaging protocol around credential flows, on-chain credential revocation registries, on-chain hierarchies/delegations for attesters of credentials, token curated attester (TCA, similar to how the Polkadot governance curates the registrars in the network, but anyone could set up a TCA around a use case), incentivized service providers (who shall run the off-chain messaging, credential storage, etc. services for token rewards). How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration? I think the biggest challenge is to communicate what is possible now, what will be possible next year, and how this landscape could potentially look like in 5 years. Some coordination like this github discussion page is highly useful. The Web3 Foundation could also foster / kick-off a gathering of requirements for projects from a feature set point of view. We could start collecting all Polkaverse projects, and the columns could be identity related feature requirements such as use case summary, privacy requirements, jurisdiction/regulatory requirements, need for GDPR compliance, possible technologies in mind to use (wallet address/js extension, zkCircuits, DIDs, VCs, ringVRF/PoP). How can we elevate the profile of the Polkadot ecosystem within groups like the W3C DID working group and the Decentralized Identity Foundation (DIF)? The decentralized identity community (DIF and the associated W3C working groups) is a very diffuse group with many projects involved which might have very different expectations and agendas. Regarding @burdges’s criticism I agree with @everhusk that many members of the community understand that there are issues with DIDs, and there are proposals to address some of these issues (peer DIDs, KERI), also Mattr proposes a new blinded selective disclosure credential and signature scheme format called BBS+. The idea is that in some circumstances this approach might be a good fit, while also acknowledging viable alternatives such as just-in-time attestations and more complex zero knowledge based solutions. Also someone from DIF posted the recent critique by Harry Halpin (Nym) (press coverage) So as a pragmatic approach we could start working on 1) a common DID pallet and an accompanying resolver service (which would probably require some on-chain and some off-chain parts) which could be used in the nearest term but would need to come with strong disclaimers and warnings and information on how not to inadvertently misuse it. As a potentially better but longer term solution, 2) we could start coordinating around a ring VRF / proof-of-personhood concept proposed by @burdges. Specifically, I would be interested in a viable concept how we could build verifiable credentials on a such proper personhood foundation for identity (BTW, this is a nice short write-up of this proof-of-personhood topic). Using ZK based credentials instead of simple selective disclosure attribute credentials would be the next step. If we have a viable concept that is better than the current proposals at the DIF, we can always arrange a slot in one of their workgroups and get some feedback from their community. |
Beta Was this translation helpful? Give feedback.
-
|
Identity is a much needed infrastructure for the Polkadot ecosystem and I have learned a lot from the insightful discussions above. Here are my two cents on the topic. What are the needs related to identity in the Polkadot ecosystem? In the latest Polkadot lightpaper, it says Polkadot will help people to regain control of their identity and their data. As such, I think the concept of identity should reach beyond the need of governance/staking for the Polkadot network. We'd love to see that the vision in the lightpaper is supported at the application level and real-world users can actually benefit from it. Who is developing identity solutions for the Polkadot ecosystem? We at Starks Network are working on the concept of Self-Sovereign Data and Self-Proving Computation. Although they are not immediate identity solution, I think they are quite relevant to this workgroup. What are the areas of strength/focus of the teams building these solutions? We currently rely on the KILT Protocol (hi @csmarc) to achieve the concept of Self-Sovereign Data—store user data as off-chain credential and have them attested by a trust-worthy 3rd party (parties). As such, no human readable data is permanently stored on-chain and people will have full control over their own data. Despite you can save your data in your safe place, your privacy can still be misused/leaked when you send your data to 3rd parties for e.g. analysis/computation. The real strength of the Starks Network comes from the concept of Self-Proving Computation. Instead of sending your data to a 3rd party (maybe a centralized server) for computation/analysis, you do the computation in your own device such as in your mobile phone or in your PC. You generate a proof during the computation to prove the integrity of your computation (thus the name Self-Proving Computation) We use a zk-STARK virtual machine to do STARK proof generation and verification for regular computations. The Starks Network aims to be a common-good infrastructure and to provide zero knowledge proof as a service to parachains in the Polkadot ecosystem. So we don't have a plan to issue our own tokens—we will take e.g. dot/ksm as service fee. How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration? I think this work group can be a good starting point for Parity and Web3 Foundation to collect the requirements related to identity, to set goals/specifications for design work, and to coordinate collaborations between teams. They can also fund certain milestones which will directly benefit the identity subject. It would be also interesting if we can gather all the identity related applications/services into one common-good parachain and get a free parachain slot from Polkadot. How can we elevate the profile of the Polkadot ecosystem within groups like the W3C DID working group and the Decentralized Identity Foundation? Glacier Blockchain Ltd is the open source contributor of the Starks Network project. The company is a member of DIF too. As mentioned above, the work in the DIF is led by different companies in several fields—pretty diffuse indeed. I suggest we focus on the needs of identity in Polkadot at this moment and when we have some concrete work, we can always propose it to the DIF community. |
Beta Was this translation helpful? Give feedback.
-
|
A quick update: the Starks Network project has been rebranded as the zCloak Network project. |
Beta Was this translation helpful? Give feedback.
-
|
What are the needs for identity in the Polkadot ecosystem? In addition, approvals from a registrar result in a green Who is developing identity solutions for the Polkadot ecosystem? For purposes like on-chain governance, the linked addresses from different networks could be public and transparent. For other purposes like DeFi services, the linked address should be stored in a privacy-preserving way without revealing any unnecessary information or its relationship with other identities. This should be the case for identity registration as well as identity usage scenarios as @burdges indicated. I am very interested in how the ring VRF crate could help hide identity relationships, but I also concern that it is hard for the recipient application to keep the provided data private. We are also building a governance-focused app integrated with identity. We want to experiment how a user's on-chain governance history could turn into a credit/reputation and affect his voting rights and proposals. Such credit should be taken into account when calculating voting power. What are the areas of strength/focus of the teams building these solutions? How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration? As we collected more and more ideas and directions, on a strategic level I totally agree with @csmarc
We are submitting our registrar on Kusama and Polkadot at the moment (without legal name support), and we are highly motivated to attend the discussion on further improvement of How can we elevate the profile of the Polkadot ecosystem within groups like the W3C DID working group and the Decentralized Identity Foundation? As a DIF member, we do think that the connection with different DID working groups will inspire new thoughts and probably reduce duplicated work. But I think an efficient and concrete way is that we first set up a working group in the Polkadot ecosystem first and then share the information or make proposals to W3C DID WG or DIF. |
Beta Was this translation helpful? Give feedback.
-
|
A bit off topic, but I thought this group would be interested: Those interested in DIDs (the spec and the concept in general), and the web of trust may enjoy this event: https://www.eventbrite.com/e/decentralized-identity-privacy-tickets-138645736129 Early bird tickets are $99 - purchased by Feb 10, the $199 after. |
Beta Was this translation helpful? Give feedback.
-
|
At Encointer we're working on one specific aspect of identity, being digital personhood. I'll answer @danforbes questions mainly regarding this aspect What are the needs related to identity in the Polkadot ecosystem?Identity is a fundamental component in most real-world applications. Sometimes it is desirable to navigate online with complete anonymity (i.e. for gathering publicly available information), sometimes you want to be personally identifiable (to enjoy some service the provider only provides to known an/or identified users). This should involve a selective disclosure of just the information which is really needed by the other party to provide their service. The third case - which Encointer aims to solve - is when you need to prove personhood only, free of any attributes beyond the fact that you are human (like currently attempted by CAPTCHAs). In many practical cases this also involves proving uniqueness to prevent sybil attacks. Prominent use cases:
Who is developing identity solutions for the Polkadot ecosystem?Encointer develops a digital personhood system and provides APIs for sybil-defense What are the areas of strength/focus of the teams building these solutions?The Encointer Protocol claims to be one of the most secure decentralized personhood protocols. Other players like Idena or BrightId aim for UX and they are more accessible. But this comes at the price of weaker security guarantees. Encointer provides an unlinkable proof of personhood. You can attend meetups with changing pubkeys which later only need to be exposed to our trusted execution environments (SubstraTEE) when using the proof-of-personhood (PoP) This PoP can be used for sybil-defense by third party apps or parachains (demo) How can Parity & Web3 Foundation support these teams, reduce duplicated work, and increase collaboration?Encointer's challenge is not mainly technical. The protocol is very involved for participants because you need to attend physical meetups with random people in your neighborhood at regular intervals. Our biggest challenge is adoption. As a social attestation protocol our concept only works with many lively local communities around the world. So, any help with PR and education would probably be most impactful. How can we elevate the profile of the Polkadot ecosystem within groups like the W3C DID working group and the Decentralized Identity Foundation?Encointer is not really related to W3C DID as our digital personhood is not a verifiable credential which could be issued by the issuer. Uniqueness could (to my knowledge) not be proven unlinkably with a document which some *issuer" signs, which the subject holds and presents to the verifier. Mainly, because there is no entity for issuer. Its the Encointer blockchain which acts as the trusted registry - and as such it is not able to sign something. On a side note: I think more important than focusing on W3C DID is the very generic trust over ip architecture. |
Beta Was this translation helpful? Give feedback.
-
|
There is nothing wrong with parachain governance reusing information collected for relay chain governance of course. It's unlikely however that information collected for governance really fits other parachain use cases besides governance. I'd expect KYC must be done through off-chain companies for many legal reasons. Also KYC covers "nominators" while other identity uses only care about node operators. We're making some progress on the ring VRF code and write ups now, so hopefully within a couple months something useful to show people. This plays really nicely with "personhood only" stuff, so you can do things like every person has the right to run exactly one collator.
We should actively avoid directly or implicitly supporting the W3C DID and Verifiable Credentials working groups, including at a technical level, i.e. favor incompatible data models and data types. Those guys want really dystopian shit like private users proving they have a degree or proving they have a job. It's clearly classist and even racist to one-click prove that stuff from a browser. Also, the W3C models favor signatures by authorities, not Merkle trees or zkSNARKs of Merkle trees or other accumulators. As a result, their solutions lean heavily towards "blockchain washing" like what hyperledger does or what DFinity pivoted towards, or even private blockchains, which do not fit with polkadot. It's best if our parachain developers think first about data minimization and when necessary about the split between what data they need on-chain and what data they'd handle better via some off-chain resource. |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to see some write ups of the better approaches you mention to get that "aha" moment, zkSNARKS are still very cryptic to me(pun-intended). I want to believe there's a much better way to look at identity and that W3C DID is as evil as I've seen you mention several times but reality is that it has quite some momentum behind and looks easy and good enough for most people that are already implementing it(including projects in the Polkadot ecosystem). |
Beta Was this translation helpful? Give feedback.
-
I am starting this discussion to help organize efforts around the management of identity on Substrate-based chains and in the Polkadot ecosystem in general.
@BenWhiteJam - Parity Builders Program
@gautamdhameja - Parity Delivery Partners
@dvdplm - Parity Developer
@SuragSheth - Parity Ecosystem Growth
@Noc2 - Web3 Foundation Grants
@burdges - Web3 Foundation Research
@tjwelde - KILT Procotol
@NickLambert - Dock
Beta Was this translation helpful? Give feedback.
All reactions