Do you have any code samples or documentation about setting up and utilizing Web3ID proofs, especially concerning the roles of Issuer, Holder, and Verifier? For instance, for example how can one become an issuer of proofs?
1 Like
Are you aware of the documentation
The concrete example of an issuer is the SoMe issuer we have as part of Concordia
This is a “generic” issuer that will issuer credentials based on login with the relevant platform.
Holder is the wallet.
An example verifier is the Concordia backend
Thank you for sharing the links and examples. We’ll investigate them thoroughly. We are looking into how the process of associating physical products with Provenance Tags can be usd in Web3ID context. So anyone who possesses a product with a Provenance Tag can use the Web3ID system to affirm their ownership of the specific item, much like they can verify details such as being over 18. Provenance Tags will issue a verifiable credential for Provenance Tag ownership. dApps can authenticate this ownership when they perform an NFC scan of the tag directly on the product - this is our present conceptual direction.
1 Like
Sounds good!
Looking forward to hear more.
We have a use case where it would be advantageous to automate the issuance of credentials without direct access to the holders’ wallets. Is it correct that, to our understanding, this is not feasible in any way? Adding that we are aware of each holder’s Concordium account.
There may be multiple scenarios where mass issuance of verifiable credentials is practical. Take, for instance, a university issuing diplomas to a large number of students whose details are already known and verified. This would eliminate the need for each student to individually connect to a dApp and their wallet to obtain their diploma.
There is no need for the user to have an account, but they do have to create a public key to have the credential. The reason for this is that this puts the user in full control of the usage of the credential since they are the only ones who have access to the relevant secrets.
The way mass issuance should work I think is that one would generate data for the credentials and then ask users to claim them via a dapp. At that point the credential is actually registered on the chain and issued in the users’ wallet. You could even ask the users to pay for the issuance, that is supported.
To comprehend the final section, did/can the issuer here pre-generate some data on-chain in preparation for claims? or would that be off-chain.
For the claim process, is (or will be) that supported within the standard wallet, or is there a need for a dApp to facilitate the claiming?
In principle they can generate it on the chain as well and then let the users claim them themselves. It’s a bit unclear how you would identify these users though. The identifier of a user is a credential holder id, which is a public key generated by the wallet.
There is no support in the standard wallet directly It would have to be facilitated via a simple dApp.
Depending on what you register in the contract (if you preregister) then such a dapp might not need any backend.
Can you explain the advantages of your mass issuance approach compared to the traditional method?
I am not claiming there are advantages. There are different tradeoffs.
In a mass issuance scenario you might simplify your backend setup by just doing a batch job registering stuff you need on the chain. And later on you don’t have to be running any services.
This might be what you want in some cases so that you don’t have to manage any long-term state/service.