now that we have an identity system with Kilt.io, it is time to also have a decentralised identity provider, to replace all those centralised IAM systems: Active Directory, AWS Cognito, Google IAM, etc.)
In order to achieve this goal, we need an inexpensive system which derives its trust from randomness and decentralisation.
At its core, the system would work like this:
the user creates a validation request in the identity network (can be a smart-contract)
the ID Network selects a random set of validators and creates a random challenge for the user to sign
the user signs the random challenge and sends the validation request to the selected validators
the validators verify the request and submit their decision, encrypted with the client’s public key, to the ID Network
the client reveals the responses and by doing so, triggers the payment to the validators
the network creates a JWT with a BLS signature from the validators which the user can send to any application which accepts the ID Network as its identity provider
let me know your thoughts on the idea, I’d like to submit a funding request to Decentralized Futures
I do like the idea of a decentralised DID credentials verification provider and your process makes perfect sense… its great to have Deloitte within the ecosystem but if we are to offer choice and an end to end decentralised solution then we need someone to fill that void.
I sincerely appreciate the idea; I believe it’s the natural next step. Once DIDs and VCs become commonplace, a decentralized, efficient, and convenient solution like the one you described will be imperative. Are you exploring use cases where your validators are also required to authenticate? Thank you for sharing your thoughts.
Indeed, it makes sense to require the Validators to also authenticate. There will be situations in which the validation of a VP can only be performed by accessing private information. In such cases, the validator selection process must take this requirement into account.
The ability to access private data could be self proclaimed, as the validator how is not able to access the data will be slashed for not fulfilling their job. But there might be other reasons to pretend to be someone you’re not and hence it makes sense for the validators to provide proof of their credentials.
Another use-case can be regulatory: in many countries, the banking system is not allowed to use services outside of the country. In such a case, having validators who can prove their residence is important. It can be made that no data leaks outside of the borders by using encryption.
Deloite’s KYC is also a good example as only registered verifiers can read the VC. You would want to select from this sub-group if the KYC is from Deloite
this would not be a competitor to Deloite’s on-chain KYC. Quite the contrary: it provides a decentralised way to check the KYC.
Deloite’s solution is a bit special as it requires the verifiers to be registered. The VC is encrypted in the Deloite extension and can only be read by registered verifiers.
What you are saying is that the ID network, despite its decentralized nature, can effectively accommodate centralized verifier registries use cases, right? In the case of Deloitte’s KYC, the approach could simply involves issuing curated network validators with appropriate VCs.
That would be a great idea (we are doing something similar with Real Estate Development Loan Evaluators)… I have a meeting with Deloitte tomorrow… I will offer it up as a suggestion and see what they say
Meeting went very well thanks… although the conversation was based more on the technical issues currently being experienced and our need for some test credentials. We have another meeting this week so will try and delve in to the conversation around having their verifiers more decentralised (although i think its quite a foreign concept and they like to retain control for brand protection so we’ll see what they say).
Although brand control could potentially hinder true decentralization, it can be effectively managed by implementing KYC procedures for node operators. By enforcing KYC, the network can maintain a carefully selected group of nodes under a PoS consensus mechanism. This approach effectively addresses brand control concerns while preserving the significant benefits of DePIN.
Thanks for pursuing the impossible.
Hello! Introducing yet another level of intermediation for potentially sensitive credentials is going in the wrong direction, I think.
Also, some questions should be answered like: what is the information that should be revealed by these verifiers? What to do with selective disclosure? Is it really ok to record those “tokens” on the blockchain, even if encrypted? Few other steps are unclear as to what goes on chain, what stays offchain, and what information flows between what parties when.
I think instead that the solution should build on the identity system that KILT has already made available, namely DIDs. They are powerful and flexible, and the KILT chain has a way to deal with them as first class citizens within its runtime.
Nevertheless, we are always receptive to new needs from ecosystem projects, and on-chain credential verification is a big thing we want to achieve next year, regardless. Maybe it would make sense to better define exactly the requirements of such a use case, and whether they can be fulfilled by building on top of KILT, instead of devising a completely new way of doing this. The DIP (Decentralized Identity Provider), naming conflict maybe (?), could help as it allows DIDs to be used across all chains. If we devise a way to do the same with credentials, we are golden.
we propose to use DID and Verifiable Presentations VP. The system would simply be more flexible than just one DID method. The verifiers would be able to verify any VP even those with mixed DID methods.
Disclosure of data
selective disclosure and data privacy are important indeed. Having a network of decentralised verifiers would make data more private not less. By sharing your data with a network of verifiers, you ensure that no central party ever learns about all your data or finds out about all the applications you use online.
We believe that somebody will provide verification services in the future because application developers will want to outsource this function. Just like they outsource authorisation management to Okta, they will outsource VP verification. A netowrk of verifiers is better than a centralised solution.
using Kilt
Kilt is a great DID method and this is the technology we have started with. But Kilt is not the only game in town and many users will have a different DID. Creating an open verifier network will allow users to get their VCs from any issuer, with the certainty that it will be verifiable.
I am not sure I agree with this sentence. Instead of a model where an attester issues something to a claimer, who is free to use the credential whenever they want as long as the relying party trusts the attester, now we have introduced a new party, the network of verifiers (which themselves can be malicious) that both the claimer AND the relying party have to trust. The claimer must trust that none of the verifiers mishandle the data they have access to, and the relying party must trust the attester network to provide authentic information.
When it comes with dealing with user’s sensitive information, delegating that to a decentralized network of verifiers might not be the best solution, in some case not even legally allowed (e.g., for GDPR compliance). Difference is federation, where a party delegates verification of credentials to a well-defined set of trusted third parties. We have started some work in this direction, with our OpenDID service.
I agree that more than a single DID method must be supported, but I do not agree with delegating user-identity verification to a decentralized entity incentivised solely based on economic rewards, without establishing legal boundaries and clear responsibilities.
I think we’re talking about different use cases. The verification of the validity of an authorisation does not necessarily require sharing Personally Identifying Information. It might be as simple as I am an Admin instead of My name and address are XYZZ
The service we propose here is simply a decentralised version of the OpenDID service. I understand that the ideal situation is when the application hosts the OpenDID service itself. But that is not always possible.
We’re thinking about use-cases like P2P authorisation: e.g. doctor - patient approval on mobile app
I agree with you. Establishing legal boundaries and clear responsibilities will always be a must for any solution. But I’m also convinced that, in the long run, decentralization has proven to work better than centralized solutions when it comes to these matters.
Furthermore, I think this is something we can better solve by implementing SSI properly, KYC-ing participating nodes, and providing them with proper VCs (it’s not solely about implementing an incentivized decentralized rewards system). We could even implement Kilt’s delegation method between nodes to make boundaries more robust.
If we end up thinking that the only way SSI could evolve is by having the Big4 issuing, verifying, and demanding us to use their wallet to hold our credentials, then why did we even bother about SSI in the first place?
That is not what I am suggesting. The original idea of this post was to rely on KYC credentials issued by one of the big 4s. KILT provides infrastructure, and as such does not make any decisions on its own as to what represents an authoritative answer. Also, I am not advocating for centralisation either. Above I mentioned federation, which I think represents the best of both worlds, while still allowing all parties to be held accountable without sacrificing the overall system efficiency that much (decentralisation introduces some sort of consensus-enforcing rules, which for some use cases is totally unnecessary).
In conclusion, we are all fans of SSI here, and we seem to have different views as to how best make use of it. My goal in engaging with this post was to bring an “expert” perspective into the conversation. I would be curious to see how this proposal evolves into a fully-fledged project, and where that project will take us
Great to see @drgorb bringing his expertise to this ecosystem! Glad to read your post here.
I think we need to state very clearly that what deloitte offers has nothing to do with SSI (because the control who can verify) and it doesn’t offer strong privacy guarantees (yet?).
With regards to SSI, I welcome @drgorb 's initiative. I’d like to add suggestions for privacy enhancement:
As a first step, I think we should use KILT solely for revocations which we’d like to have global consensus about. I don’t think it is necessary to leave traces on KILT’s chain for each and every issuance of VCs as is currently designed for the deloitte case AFAIU.
If we allow an unpermissioned set of verifiers, we could require them to perform their verification inside TEEs. Integritee has previously demonstrated how that could work and demoed a similar case at sub0 2023
This could also enable GDPR compliance.
thank you for the kind words @brenzi! I completely agree with you about the Deloitte approach, it’s a missed opportunity to see that they want to control the verifiers. Maybe they could be convinced to allow some Off-Chain workers in a TEE to perform the verification. That would allow the verifier to re-issue the VC in a trusted manner. Deloitte would be off the hook and the user would have a VC that can be trusted just as much.
I was thinking about using the TEE Off-Chain workers to perform the verification in order to remove the need to reach consensus. It would be more efficient and offer the advantage to allow the verification of any DID method VC. There are more methods than just Kilt out there. That is the big issue with SSI.
Also, the result of the verification can be kept private to the holder but still anchored on chain. Publishing the hash and the result would be sufficient to make it easily verifiable without disclosing anything.
Integritee would be a good platform to deploy such a solution on. I have to do my homework and check what is required to build on your chain.
