You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 13, 2021. It is now read-only.
Inspired by uPort Connect's selective disclosure, where the two peers share their DID's with authenticated claims about their metadata. This would make it easy to build both a backwards compatible DID resolver for WalletConnect v1.0 protocol and also allow v2.0 protocol to support multiple resolvers.
This would dramatically expand the scope of WalletConnect to not only support other blockchains like for example Bitcoin which already has it's own DID resolver as part of the current W3C spec but also allow WalletConnect to serve as a protocol for DID Authentication for non-blockchain protocols.
The idea is to introduce this as part of the v2.0 protocol at the handshake process which will then allow the two peers to parse and agree on how to handle the communication during the session.
This would also allow to more flexibly describe accounts and their specific-protocols. Instead of tightly coupling the WalletConnect protocol to how Ethereum handles accounts with an array of addresses, it could instead allow accounts to be DIDs and expand different types of accounts and their own signing schemes
Inspired by uPort Connect's selective disclosure, where the two peers share their DID's with authenticated claims about their metadata. This would make it easy to build both a backwards compatible DID resolver for WalletConnect v1.0 protocol and also allow v2.0 protocol to support multiple resolvers.
This would dramatically expand the scope of WalletConnect to not only support other blockchains like for example Bitcoin which already has it's own DID resolver as part of the current W3C spec but also allow WalletConnect to serve as a protocol for DID Authentication for non-blockchain protocols.
The idea is to introduce this as part of the v2.0 protocol at the handshake process which will then allow the two peers to parse and agree on how to handle the communication during the session.
This would also allow to more flexibly describe accounts and their specific-protocols. Instead of tightly coupling the WalletConnect protocol to how Ethereum handles accounts with an array of addresses, it could instead allow accounts to be DIDs and expand different types of accounts and their own signing schemes