Rarimo is an aggregator of digital identity artifacts, whereby dierent artifacts can be presented in the form of various digital entities, such as:
Ownership of these types of artifacts is linked to:
Address of EOA (in the case of NFT and SBT tokens)
DID identity identier (used for issuing veriable credentials)
Rarimo allows you to create a cross-chain proof of ownership of an artifact and use it either in a target contract (calling a method that requires proof) or by an o-chain verier (for example, access to a discord channel only for owners of NFTs from a certain collection).
At the same time, it is important to understand that proofs in their current form allow us to learn more about the user than just proof of ownership of a separate artifact. Obtaining the account address of the NFT owner allows you to obtain his entire financial history existing on public networks, which is tied to this account. If the user linked the account with their personal information (used login with metamask on the service, and then filled out a profile with personal data), the financial history can be linked with a pseudonym (account) and a specific person.
Knowing the user's DID, in turn, allows you to associate it with various verifiable credentials if verifiers cooperate with each other. That is, if an attacker learned from one of the verifiers that a user with a specific DID is indeed a human and from another that a user with the same DID is a resident of the United States, etc., they could create a dossier about the user without his consent to this.
Perhaps verifers (for example, owners of web resources) would not like to know additional data. Still, they cannot avoid this since they must identify the user (make sure that the user is a person / he is 18 years old / he is not a resident of the United States, etc.). They could ensure the anonymity of user data if the proof looked like the picture below, but unfortunately, we understand what guarantees such proofs have.
Therefore, if the verifier diligently identities the user with guarantees of authenticity, this becomes a vector of attack on the user’s privacy. Because those who need it know that verifers know.
As a result, we conclude that the ideal authentication model for a service does not consist in recognizing a user with their metadata (the user’s ownership of the account registered by the service), but in checking whether the user meets the necessary criteria: