Authentication with myDid on Discord

3 min readJun 2, 2022


Creating a myDid bot in order to authenticate a Discord user and giving them appropriate access rights via a DID mobile wallet.

Decentralized identity wallets and verifiable credentials are interesting tools for managing communities on different platforms, but services and gateways must be offered to enjoy simple authentication features.

These authentications can use credentials that are provided when applying for a traditional KYC or special credentials given specifically to control access. These details will not be discussed here, however let’s focus on the particular case of users using a Discord server.

Architecture / Diagram of Discord bot for authentication via myDid wallet

On Discord, an external authentication is complex and as in other solutions that we will see later, it is not really possible to offer an authentication solution upstream.

As with other Discord’s authentication bots, our goal here is to give a Discord newcomer reduced access rights for introductory channel that is needed for this second form of authentication and to put all other Discord server’s channels in “private” with additional rights that the user will only obtain after being authenticated.

The newcomer has only limited access to the Welcome channel

By default, direct messages are authorized and, in most cases, the new user will therefore receive a DM (always private) indicating the procedure to follow: scan a QR Code with their myDid wallet app. If the user does not accept DMs, he is prompted to enter a command in the home channel typing section after changing this setting.

Simplified version of the private message sent by the bot to the new user

The new user is invited to scan this QR code with myDid application which briefly explains the context of this request.

Example (not complete yet) of consent confirmation screen

The origin of the request can be verified (Discord Bot also has a DID Document) and in order to avoid “Replay” type attacks, the nickname appearing in the request is one of the signed and displayable data.

Note: We are also working on improving consent in this context, by working with verifiers on standardized charters/commitments that may appear here. Examples: “This service keeps data only for the duration of this verification” or “The data will be stored and encrypted”, etc.

Once consent has been obtained, Verifiable Credentials are sent to the authentication server. This server:
• links them with the launched session (date, challenge, nickname, etc.)
• verifies necessary Verifiable Credentials
• verifies user’s signature
• asks bot to change user’s rights (for access)

The bot then informs in a private conversation (DM) with the new user that they have been verified and that their access rights have been modified too.

Message when authentication is successful

The user has now access to the server channels (that previously required verification).

The verified user automatically gets access to other channels (here the “vip-channel”).

Note: In addition to being given access to Discord, it is possible to send a Verifiable Credential to the user in order to confirm that they are now a verified user in Discord server and possibly allow further authentications from this new credential.

Apart from opening codes of this bot and server, we are also thinking about how great of an opportunity it would be to make this bot an “official” Discord bot, which would be easier to install on Discord servers.




Decentralized Identity