Digital Credential Protocols

Milestone

Verifiable Actions

Protocols

JLINCProofIdentityTrustGenerosity

Technologies

Core NexusENSAd4mCoasysEthereum L1ÆtherCeramicEAS

MC2 supports protocols for the following:

• Identity
• Your digital and physical identities.
• Statements
• Things you say online.
• Asset ownership
• What you own, like a car or house.
• Votes
• What you care about.
• Reputation
• Your trust and credibility.
• Credentials
• Your skills and badges.
• Eligibilities
• What you have access to.
• Financial status
• Scores and financial health.
• Digital signatures
• Verified signatures on chain.
• Provenance
• The origination and lineage of anything.

MC2 only uses entries secured by personally identifiable digital signatures in an immutable ledger in order to track proofs of task completion. JLINC and Ceramic Verifiable Claims with a multi-ledger connection to a blockchain(s) each provide a perfect architecture to submit these proofs to, being programmable, immutable, and natively allowing for personally identifiable digital signatures through cryptography.

Example Use Case

When a user (ie: a volunteer or an offeror) signs up in for an action, event, offer, or experience in the MC2 network, MC2 creates a secret cryptographic string (known as a private key) for them, based upon a password provided by the user/volunteer. The private key will be reinforced with other pseudo-random input, so two users with the same password will not coincidentally have the same private key. This private key, through a standard mathematical process, may derive into a shareable cryptographic string (known as a public key), which may be freely shown as part of the process of proving one’s identity.

As a volunteer completes a task, they will use the Faya Bot, Dashboard, or Wallet to submit an entry to the common ledger protocol ensuring its recoding on a chain via JLINC and onto the Ceramic Network as a Verifiable Claim via Aether. The Verifiable Claim, JLINC record, and Holochain or blockchain will contain the following data, encrypted with the volunteer’s public key:

• The proof that the task was completed (possibly a link to a photo, a pre-arranged code, etc)
• The specific time the task was completed

The entry will also have a UPI, or Universal Profile Identifier, formatted using a MC2 Universe specific identifier that uniquely identifies the task that was completed, left unencrypted, anywhere across the MC2 Network, and if configured, across the entire MC2 Universe or within permission ecosystems in the MC2 Network. This is how MC2 powers many ecosystems.

The Universe on a MC2 Network via Aether will continuously read the Holochain, or blockchain, searching for entries that match this payload. When one is identified, the identifier for the task will be read and compared to the internal ledger of offers in Universe in the MC2 Network. The encrypted payload will then be forwarded to the offeror, who may decrypt the payload with their private key. After decryption, they will either confirm that the task has been completed or deny that it is completed. If it is confirmed, the volunteer will be forwarded the claim instructions set forth in the original offer. If it is denied, the volunteer will be notified as well.

In this way, a secure, one-to-one communication of proof is established between the offeror and the volunteer, in a way that is auditable forever.

Credential Repos on GitLab