Seller Credential

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

The buyer can validate the seller’s business qualifications through seller credentials.

Context

In blockchain-based payment applications, different policies stipulate rules for the usage of tokens. Some of these rules specify eligible sellers and their products or services regarding their qualifications or qualities.

Problem

How can the buyer verify the eligibility of the seller before transferring a token to buy a product or use a service?

Forces

Immutability – A payment cannot be reversed if a token is later found to be ineligible to spend for the chosen product, service, or its seller.
Complexity – A seller’s qualifications or qualities might be complex and difficult to codify.
Privacy – The disclosed eligibility information should contain minimum data necessary to identify relevant aspects of oneself without revealing additional information.
Authentication – The authenticity of proof of eligibility documents must be ensured as the documents might be counterfeit.

Solution

When a token stipulates rules for its usage in terms of the eligibility of a seller and its products or services, the sequence of activities illustrated in the figure can be used to prove the eligibility to a potential buyer. First, the seller applies for a credential from the token issuer. Once approved, the credential is stored in the seller’s wallet and the credential registry (i.e., a registry that tracks the seller’s attributes using the token registry pattern). Third, when a token requires a specific credential from the seller to be validated before spending, the seller can present the credential to the token owner (i.e., buyer) as proof of eligibility. Finally, the buyer then validates the credential from the credential registry.

A token could stipulate rules for its usage in term of the eligibility of a seller or its products/services using the policy contract pattern. Similarly, the seller’s credentials, qualifications, and qualities could be specified as a set of attributes (e.g., codified as a JSON schema) or digital certificates signed by the issuer. The credential registry could be implemented similar to the token registry pattern. Specific use cases also require the credentials of the buyer to be validated by the seller. For example, the seller may want to validate the buyer’s age or whether the buyer has the right to spend the given token. In such cases, the pattern can be applied by interchanging the role of seller and buyer.

Rather than sending the credential to the seller’s wallet, the issuer could send an identifier/link to the credential stored in the credential registry. Either way, the seller should share the credential (or relevant parts of its) or its identifier with the potential buyer. This can be handled off-chain, e.g., using the sharing functionality provided by the seller’s wallet or attaching the identifier/link to the invoice. Even if the credential is shared, the buyer may want to check the credential registry to ensure that the issuer has not updated or revoked the credential presented by the seller.

Benefits

Privacy – Immutability – As the seller’s credential is verified before initiating the payment, the need for payment reversal does not arise.
Authenticity – Digital signatures can guarantee the authenticity of credentials. Also, only the issuer is authorised to add credentials to the credential registry.
Reusability – The seller credential can be used for all related tokens associated with the same policy.
Cost – No cost is involved in sharing the credential to multiple buyers as it is handled off-chain.
Upgradability – The credential details can be updated once it is issued to a seller by issuing a new credential and updating the credential registry.

Drawbacks

Security – A seller may present a revoked or old credential; hence, the buyer needs to validate with the credential registry.
Cost – A transaction fee needs to be paid on a public blockchain to add a credential to the credential registry. Further, transaction fees need to be paid when the credential verification process involved more complex operations than read-only ledger data access.

Related patterns

The token template pattern specifies tokens that require seller validation, and the policy contract pattern specifies the seller credentials to be validated.
The token registry pattern can be used to build the credential registry.
When seller credential involves external/physical attributes, those can be verified using the oracle pattern.

Known uses

Smart money developed by TietoEVRY defines spending rules for tokens. Credentials are created and issued to the registered merchants. Credentials need to be checked before making the payment.
Polymesh specifies credentials such as the seller’s KYC status and whether the seller is affiliated, accredited, or exempted from a specific jurisdiction.
Sovrin provides a blockchain-based self-sovereign identity infrastructure to issue credentials.
uPort Serto provides a blockchain-based credential management platform to achieve self-sovereign identity.