Skip to main content

Identity & Claim verification

In order to verify claims on Identities linked to game entities, we must perform multiple steps :

  • Get the Identity address
  • Get the public key of the owner of the entity
  • Verify that the owner is a manager of the Identity
  • Check that the Identity has the required claim

You can perform all of these actions with the functions on wallet and contracts provided by the plugin. But it is quite tedious.

To simplify this verification process, we provide two complementary actor components : ClaimVerifier (BP_ClaimVerifier_Component) and ClaimAnnouncer (UClaimAnnouncer).

ClaimVerifier and ClaimAnnouncer are both suited to be used in a multiplayer context. They will behave slightly differently depending on their environment (client/server) and their individual context (owned by a Client or not), but it is seamless from the user's perspective. The final verification is always performed on the client that initiated the verification procedure.

ClaimAnnouncer​

The role of the ClaimAnnouncer is simply to receive and handle challenges from ClaimVerifiers. This component should be added to any actor whose owner you might want to verify the claims.

It does not need any configuration, and should not be called directly.

Handling a challenge consists in requesting a signature. If the owner of the announcer has paired a wallet, it will receive a personal_sign request. Otherwise, his game instance will try signing with a private key (defined in the Web3GISub configuration, in DefaultGame.ini).

ClaimVerifier​

The role of the ClaimVerifier is to send challenges to ClaimAnnouncers and to verify the resulting signatures. It should be added to any actor you want to be able to verify claims.

It has three attributes that must be set before use :

  • Identity Net : Url through which to query Identity contracts
  • Sign Display Name : Name displayed in the signature request
  • Chain Id : Supported chain (TODO should be defined elsewhere ?)

Set Verifier Component attributes

Sending a challenge can be done by calling RequestVerificationChallenge, with a reference to the announcer and the target topic.

Claim Verification Challenge node usage

Upon receiving a signature, it automatically performs verification and sends an OnClaimVerified event. Multiple claim verification processes can be run at the same time ; so, in order to differentiate the results, the event is thrown with a reference to the announcer and the topic of the claim, in addition to the claim data.

How to use​

Demo​

The use of these components is quite flexible. See the demo, which explores verification between different entities in a multiplayer context and various applications for simple gameplay purposes.

More complex solutions​

The verifier can challenge the owner of an announcer for any claim, announcer components simply act as a bridge. So, in an environment with a large variety of potential claims, it might be judicious to have announcing actors advertise their claims preemptively. In these conditions, verifying actors could choose to only verify relevant claims.

Appendice : Complete verification sequence diagrams​

The sequence diagram provided at the start of this page is a heavily simplified representation of the real exchanges happening during the claim verification process.

Hereafter diagrams going into further details, especially regarding the remote procedure calls, which tasks are performed on which game instance and under which conditions.

A component is considered Owned by Unreal if it is associated to a client. The most common Owned objects are the player Character and its components. All clients are aware of the ownership status of the objects in their instance despite not being able to interact directly with the owners. They must use the game server as a middleman.

This restriction is imposed by the Unreal multiplayer system, using mostly RPCs (functions called from a game instance to be executed on another). See Unreal RPC documentation. In short, clients can only send ServerRPCs on object they own (executed on server instance) and the server can only send ClientRPCs on owned objects (executed on owning client instance).

There also exists MulticastRPC that allows for very lineant broadcasting. But it is not suited for communication between specific instances.

From client​

From server​