Identity Proofs and the Trust and Reputation API

Identity proofs make it possible for users to provide information about themselves without revealing related personal details to other parties requesting the proofs.

DecentKit supports transmission of these proofs as part of its messaging support. Communication from one identity endpoint -- a name, wallet, email, handle, token, etc. -- to another identity endpoint can include requests and transmissions of identity proofs between the parties.

This API addresses the problem of 'how can I trust the identity and the message content of a resolved endpoint that I am messaging.'

Identity Proof Use Cases

Here are a few examples of how identity proofs can provide value in real-world scenarios:

• A driver might present proof of age without revealing private info on an underlying government-issued driver's license;

• A gamer might prove to other gamers that she is not a bot and provide achievement and reputation signals that cannot be spoofed or forged;

• A pediatrician may issue proof of a youth's fitness for scholastic sports which a family can use without sharing private medical info;

• A fan might show proof of attendance at an in-person concert or event without revealing the price, seating, or other details of the ticket;

• A financial institution might issue proof of KYC which a user can present to a protocol or marketplace without leaking the underlying private data;

• A medical facility might issue proof of vaccination which a patient may keep in a mobile wallet on their phone, and be sure the proof cannot be copied or spoofed.

Verifiable Credentials as Proofs

There are several potential technical implementations of the identity proof concept. Verifiable Credentials (VCs) are one proposed standard which provide cryptographic identity proofs in a decentralized manner that cannot be spoofed. Moreover, they cannot be transferred to other identities and they are not public on a chain, but custodied by their respective owners. VCs play a significant role in enhancing trust, privacy, and interoperability, and are the first identity proof implementation that DecentKit supports.

You can learn more about the Verifiable Credentials standard here.

Verifiable Credentials and Decentralized Identity Standards

DecentKit follows standard guidelines presented by the W3C, DIF, and consortium efforts such as Verite. DecentKit provides a simple API for using these technologies in an identity messaging app context, but please note that many use cases, such as those involving multi-jurisdictional proofs in a regulatory context, carry a great deal of complexity that is not addressed here and is beyond the scope of DecentKit.

DecentKit's Role Among Standards

DecentKit's goal with regard to identity is primarily to facilitate the transfer of identity proofs within messaging contexts. It aims to implement and build upon identity standards and best practices to accomplish this, and to collaborate with those building at that level, but it does not propose any new standards itself, nor does it address any governance issues with regard to issuance or verification of proofs. It simply aims to make these implementations and governance approaches easier for developers to employ.

Using Verifiable Credentials in DecentKit

Here are two examples of how the VC exchange process can work which are intended to follow standard guidelines presented by the W3C, DIF, and consortium efforts such as Verite.

Pattern: Direct Exchange

One party can request a verifiable credential from another party by using a version of the Presentation Exchange sequence (a proposal defined here). Verifiable Presentations are essentially wrappers around VCs that enable useful features while preventing replay attacks (e.g., ensuring that the party submitting the VC in the moment is the same identity as the VC's subject at the time of issuance). DecentKit provides an app-level API aimed to support and simplify the sequence.

1. Credential Request: Party A requests that Party B prove some information. Party A uses the API which generates the request in a standard format. The visual experience of creating the request could be a text message, a QR code to scan, a chatbot request, or other interface depending on the developer's app and use case.

2. Credential Submission: Party B responds by submitting a Verifiable Credential to prove the requested information (potentially employing selective disclosure to further limit the information shared). In a given app, the visual experience may simply be a picker in a wallet application, or an in-game inventory, or bluetooth request to hardware wallet, etc.

3. Verification: Party A verifies the submitted presentation and credential.

Pattern: Third-Party Verifier

It is also possible for a relying party to employ an independent verifier to conduct the exchange and provide proof, so long as the relying party trusts the verifier. This pattern may be appropriate when the relying party lacks the ability to execute exchange and verification itself, such as when the relying party is a smart contract or series of contracts composing a protocol.

1. Credential Request: Party A requests that Party B prove some information.

2. Verification Proof Generation: Party B uses their private credential to get a “Verification Proof” from Party C, a third-party verifier, using the presentation exchange sequence.

3. Proof Sharing: Party B provides Party C's verification proof to Party A.

4. Proof Verification: Party A verifies that the proof has not been tampered with and, upon satisfaction, the transaction continues.

Here's a high-level pseudocode example of how such a VC exchange could occur:

// Party A requests a proof of a certain claim
const claim = decentKit.requestProof('claim', 'PartyB');

// Party B verifies their credentials with a verifier, which responds with a verification proof
const verificationProof = decentKit.verifyCredential(credential);

// Party B provides this proof to Party A
decentKit.provideProof(verificationProof, 'PartyA');

// Party A verifies the proof
const isVerified = decentKit.verifyProof(verificationProof);

if (isVerified) {
    // Transaction continues
} else {
    // Transaction halted
}

Please note that this is high-level pseudocode and the actual code will depend on the implementation specifics. For a more in-depth discussion of these sequences and an illustration of the standard protocols beneath the API, the Verite documentation is a helpful place to start.

Additional Identity Proof Implementations in DecentKit

In addition to Verifiable Credentials and the Decentralized Identifier standard related to it, DecentKit may in the future add support for mechanism like tokenized identity, Proof of Attendance Protocol (POAP), or other implementations within its simplified API.

As previously stated, DecentKit's intent with regard to identity is to facilitate the transfer of identity-related proofs within a decentralized messaging context. It does not propose specific standards or implementations, nor does it enforce governance related to issuance or verification. It simply aims to make these mechanisms easier for developers to employ in their games, wallets, communities, and other apps.