Skip to main content

基準（TBD)

· 4 min read

Reference:

OpenBadge ヨーロッパ、日本、アメリカで使用されている。

Blockcerts は、MIT Media Lab

https://github.com/1EdTech/cert-schema

OpenBadge の拡張版。

https://digitalpromise.org/initiative/educator-micro-credentials/ Marketingを勉強する には良さそう。しかし、ここが違う所。

waytoproove

https://microcredentials.digitalpromise.org/explore　のマーケットがいい感じ。

https://github.com/1EdTech/cert-schema/blob/master/docs/open_badge_v2_extensions.md

OpenBadge　のExtension/そのまま使う可能性を探る

didcore

InterOperabilityにすると、MECではここを補うことが必要。

あと　DID Methodは発行者独自と書いてあるから。ここも補うことが必要。

Task1: そこにIssuerのメタデータを置くか・IssuerのCRU（Dはなし）をだれが許可するかがDAOの役目？

OpenBadge V3 Structure​

+----------------------------+
|  AchievementCredential     |
+----------------------------+
| - @context                 |
| - id                       |
| - type                     |
| - issuer                   |
| - issuanceDate             |
| - expirationDate           |
| - credentialSubject        |
| - proof                    |
+----------------------------+
          |
          v
+----------------------------+
|         Issuer             |
+----------------------------+
| - id                       |
| - type                     |
| - name                     |
| - image                    |
| - url                      |
| - address                  |
+----------------------------+
          |
          v
+----------------------------+
|   CredentialSubject(User)  |
+----------------------------+
| - id                       |
| - type                     |
| - achievement              |
+----------------------------+
          |
          v
+----------------------------+
|        Achievement         |
+----------------------------+
| - id                       |
| - type                     |
| - name                     |
| - description              |
| - criteria                 |
| - image                    |
+----------------------------+
          |
          v
+----------------------------+
|         Criteria           |
+----------------------------+
| - type                     |
| - narrative                |
+----------------------------+
          |
          v
+----------------------------+
|          Proof             |
+----------------------------+
| - type                     |
| - created                  |
| - verificationMethod       |
| - proofPurpose             |
| - jws                      |
+----------------------------+

Reference

Open Badge = The badge cannot be verified (the badge's authenticity cannot be proven) without the Issuer's platform.

MEC = By using the blockchain as a registry, the authenticity can be verified without a platform.

  1. Structure of the Registry:
    • Classes can be aligned across multiple issuers. (Tag feature?)
    • Ability to have multiple courses.
- Verifiable Data Registry
- Issuer
- Verifier = Application generated according to standards.
- Reviewer = Users are companies seeking to hire.
- Holder = Learner

Use Case​

Issuer Side:

  1. The issuer registers issuer information and course content.
  2. The issuer issues MEC to the Learner.

Learner 1:

  1. Obtain MEC.
  2. Refer to MEC content.
  3. (Out of Scope) Optionally share MEC Bundle.

Learner 2:

  1. Go to the Registry and refer to courses of interest.
  2. View the Issuer's content.
  3. (Out of Scope) It would be nice to see how many MECs have been issued and evaluations from the Learner's side.

Data Structure​

Issuer (Issuer)

id: 0000-xxx00...
name: Chiba Institute of Technology
Corporate Number: xxx-xxx-xxx
Country: Japan
Address: Chiba Prefecture...
logo:

Class

id:
name:
description:
logo:
expiration (optional):
tags: [web3, it]
Verification Method: Public Key

Tags / Categories

name: web3

MEC

Issue Date:
Name:
logo:
expiration:

The format uses JWT data VC to check for tampering.

MEC Data Model​

MECDataModel

  1. badge: BadgeClass includes signatureLines images in BlockCerts, but I don't think they are necessary here (verification is done by Verification).
  2. Credential: In BlockCerts, the recipient is included in the Badge, but to conform to OpenBadge, it is moved back to the RootLevel. However, I like the term Recipient, so I want to keep it.
  3. Recipient: This needs further discussion. It is included in BlockCerts but not in OpenBadge.
  4. IssuedCredentialMeta: In the future, marketplace and similar course viewing functions may be possible. This could be a point of discussion whether to use IPFS or DB.

Examples​

Question 1:​

  • Can the Web3 Introduction course be included in the Registry?

Reference:​