Open Badges：検証できる証明を支えるオープンな標準規格

この規格は証明を3つの部分に分けます。この分け方は、一見して思うよりよく考えられています。Issuerは誰が発行するかを表します。名前、ウェブサイト、連絡先です。BadgeClassは何を授与するかを表します。証明の名称、説明、基準、画像です。そしてAssertionは個々の授与そのものです。この人が、このBadgeClassを、この日付で受け取った、という記録です。

おかげで、証明書の種類の記述は一度あればよく、それを20人に授与しても2,000人に授与しても変わりません。実際に私たちのシステムが返すAssertionはこのような形です。トークンだけを短く省略しています。

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

もう一度見ておく価値のある点が2つあります。badgeフィールドはアドレスにすぎません。そこにBadgeClassがあり、それがさらにIssuerを指すので、検証ツールは連なり全体をたどっていけます。そしてrecipientにはここでは証明書ページのアドレスが入ります。メールアドレスは、ハッシュ化したものであっても、どこにも現れません。つまり公開文書には直接の連絡先が含まれません。本人の名前は、リンク先の証明書ページに載ります。受け取るときに本人が自分で入力した場所です。

仕様にはAssertionを検証可能にする方法が2つあります。署名型のバッジでは、文書に発行者の暗号署名が付きます。文書自体が正しさを証明しますが、その分、発行者側で鍵の管理が必要になります。ホスト型のバッジには、もっと単純なルールが当てはまります。Assertionは、それ自身のidアドレスで発行者のもとから取得できるかぎり本物、というものです。検証とは、URLにアクセスして照合するだけのことになります。

ホスト型の方式には、見過ごされがちな利点があります。取り消しがきれいに行える点です。発行者が証明を取り下げると、同じアドレスはその時点からHTTPステータス410と、『revoked: true』の一行が入った短い文書を返すようになります。取り下げられた証明書は、黙って消えるわけではありません。自分はもう有効ではないと、はっきり示します。OneClickBadgeでも同じように扱っていて、たとえば証明書を誤って二重に発行してしまったときがそれにあたります。

この規格のある細部は、ほとんど詩的です。『ベイキング（baking）』と呼ばれるしくみです。バッジの画像、多くの場合はPNGは、自分のAssertionと検証用アドレスを画像ファイルの中に直接埋め込みます。技術的には、openbadgesというキーワードを持つiTXtテキストブロックとして格納されます。画像の見た目はそのあとも寸分変わりませんが、検証の経路を内側に抱えています。そのファイルを検証ツールに読み込ませれば、いくつのダウンロードやチャットを渡り歩いてきた画像であっても、Assertionにたどり着きます。

順位は変わりません。証明できるのはホスト型のAssertionだけです。画像はいくらでも複製も改変もできます。証明アドレスが返す応答を握っているのは、発行者だけです。

ここで、多くの記事に取り憑いている最もよくある誤解を片づけておきます。LinkedInはOpen Badgeのメタデータを読み取りません。バッジのインポートも、自動的な検証も、検証済みバッジ専用のマークも存在しません。LinkedInにあるのは、プロフィールの『ライセンスと資格』欄で、名前・発行組織・URLの入力欄があるだけです。それによってLinkedInが何かを認証したり承認したりするわけではありません。

だからといって、この規格がLinkedInで役に立たないわけではありません。むしろ逆です。URL欄に入れるべきは証明アドレスです。プロフィールで『証明書を表示』をクリックした人は、検証可能なAssertionが控える証明書ページにたどり着きます。この記載は、受け取る人のために入力欄をあらかじめ埋めた状態で用意でき、クリック1回で済みます。参加者の側から見たときの流れは、プロフィールへの記載ガイドで紹介しています。

規格を自前で実装して割に合う主催者は、ごくわずかです。Issuer、BadgeClass、そして一つひとつのAssertionのために常時アクセスできるエンドポイントが要りますし、取り消しのしくみとベイキング済みの画像も必要です。イベント、ウェビナー、研修なら、できあがったものを使えます。OneClickBadgeでは参加証明書をデザインするだけで、発行される一通ごとに、ホスト型のAssertion、取り消しのしくみ、画像を含むPDFが自動で付いてきます。

大勢の参加者への配布も、名簿のアップロードなしで進みます。イベントの後に共有する、参加者が自分で受け取るリンクを使います。証明という話題で、これがなぜプライバシーの選択でもあるのかは、大勢の参加者への証明書のページで説明しています。

バージョン3.0は、規格の土台をW3C Verifiable Credentialsへ移します。暗号署名を使い、受け取る側の管理権限がより大きいモデルです。大学のエコシステムや長く使う教育証明にとっては、これは正しい方向です。イベント参加という用途では、ホスト型の2.0が今のところ実務的な到達点です。よく使われる検証ツールはどれもこれを理解しますし、取り消しも機能し、ウォレットや鍵を管理する必要もありません。だから私たちはホスト型の2.0を採用し、3.0は落ち着いて見守り続けています。