相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向

2025/8/1に1EdTech様主催のLearning Impact Japan 2025で講演した際の資料。
学修歴クレデンシャルの相互運用性についての考察です。

1. 相互運用可能な学修歴クレデンシャル に向けた標準技術と国際動向 2025/8/1 伊藤忠テクノソリューションズ株式会社 一般社団法人 OpenID ファウンデーション・ジャパン/代表理事 米国OpenID Foundation/共同議長 eKYC&IDA WG 富士榮 尚寛（ふじえ なおひろ）
2. 自己紹介 デジタルアイデンティティ分野で約20年の経験を持ち、大手自動車製造業のグローバルID基盤に関するコンサルティ ング～PMなどを歴任。 2018年よりOpenIDファウンデーション・ジャパンの理事に就任、KYC WGを設立。2020年1月より米国OpenID FoundationにてeKYC and Identity Assurance Working Groupの設立および共同議長に就任。2021年6月 よりOpenIDファウンデーション・ジャパンの代表理事に就任。 CTCでは研究部門の責任者を務める。 各種役割 OpenIDファウンデーション・ジャパン代表理事/KYC WG発起人 米OpenID Foundation/eKYC&Identity Assurance WG共同議長 日本ネットワークセキュリティ協会/デジタルアイデンティティWG, ISOリエゾン 各種政府委員会構成員（Trust、デジタルアイデンティティ関連） 慶應義塾大学SFC研究所/研究員、大阪大学/客員教員 富士榮 尚寛（ふじえ なおひろ） Copyright © 2025, Naohiro Fujie, All Rights Reserved 2
3. 相互運用性と構成要素 学修歴クレデンシャルの相互運用性とは 目指す相互運用性を実現するために必要なこと 本日お話しすること 3 Copyright © 2025, Naohiro Fujie, All Rights Reserved
4. 異なる言語 異なる部族 異なる文化 異なる社会システム バベルの塔 4 Copyright © 2025, Naohiro Fujie, All Rights Reserved Picture: Rex Sorgatz
5. サイロ化された世界 5 Copyright © 2024, Naohiro Fujie, All Rights Reserved Picture: Doc Searls
6. 私たちが望むもの 6 Copyright © 2025, Naohiro Fujie, All Rights Reserved 国家、管轄、社会システム、業界などを跨いだコミュニケー ションが成立すること Source: SIDI Hub 2024 Strategy
7. Source: https://onekeyresources.milwaukeetool.com/en/construction-software-interoperability
8. 相互運用性と構成要素 Copyright © 2023, Naohiro Fujie, All Rights Reserved 8
9. 国、機関、業界などを超えて自由に行使できる状態 発行機関、利用者の環境、行使先サービスに依存せず プライバシーに配慮した状態（利用者が安心して自由に行使できる状態） 例） 日本の大学が発行した卒業証明書をアメリカの企業に就職する際に使える 民間企業の発行した資格証明を使って単位認定する 機械可読性、信頼性が自由なデータ流通実現の要 DFFT（Data Free Flow with Trust）、Trusted Webの考え方 信頼するための一定のガバナンスを確保した状態での自由な流通を促進する クレデンシャルの相互運用性とは 9 Copyright © 2025, Naohiro Fujie, All Rights Reserved
10. 技術（Technical） 識別子の形式 トランスポートプロトコル データモデル（スキーマ、署名アルゴリズム） 非技術（Non-technical） 値の持つ意味（セマンティクス） 質保証フレームワーク トラストフレームワーク 相互運用性を構成する要素 10 Copyright © 2025, Naohiro Fujie, All Rights Reserved
11. 集合の中で実体を一意に識別するための属性情報 （一つとは限らない） スコープに依存する 国内、国際、グローバル 例）日本の中に「富士榮」は複数いるので苗字は識別子にならないが、大阪 府の中なら苗字で識別できる プライバシーと永続性に対する考慮が必要 変更できない識別子だとプライバシーの課題あり メールアドレス、学籍番号などは卒業後や他機関へ異動したときに課題 識別子（Identifiers）の形式 11 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical ⽇本 ⼤阪府 富⼠榮 富⼠榮 富⼠榮 富⼠榮
12. エンティティとアイデンティティの関係性 12 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）@_NAT ZONE https://www.sakimura.org/2011/06/1124/ • エンティティ（主体・実体）は直接 観測できない • アイデンティティ（属性の集合）を 通じて認識・観測する • 自観：提供する属性を通じ、他人に 見てほしい「自己像」 • 他観：提供された属性を通じ、実際 に感じ取った「自己像」 • 提供する相手毎に提供する属性を変 えて「自己像」を形成 （コンテキストの切り替え） 余 談
13. コンテキスト毎に自己像を構築し、やりとりを行う 13 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 XX大学出身 YY社での実績 ⇒採用 ZZ社所属 ⇒取引 XX大学出身 ⇒採用 A県出身 ⇒入寮許可 家族構成 ZZ社所属 ⇒補助金 XX大学出身 ZZ社所属 ⇒結婚 コンテキスト・関係性 余 談
14. コンテキスト侵害→プライバシー侵害 14 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要 職場での姿 ⇒家族に知られたく ない？ 学生時代の交友関係 ⇒労働には無関係 ◦◦地区出身 ⇒採用には無関係 職場での姿 ⇒家族に知られたく ない？ 余 談
15. コンテキスト侵害→プライバシー侵害 15 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要 職場での姿 ⇒家族に知られたく ない？ 学生時代の交友関係 ⇒労働には無関係 ◦◦地区出身 ⇒採用には無関係 職場での姿 ⇒家族に知られたく ない？ コンテキスト毎に自己像を 自身の意思で形成することが 必要 コンテキストごとに識別子を 分けられることが重要 余 談
16. 関連するエンティティ同士がどのように通信するか デジタルクレデンシャルにおいては 発行プロトコル（発行機関からウォレットへの発行方法） 提示プロトコル（ウォレットから検証機関への提示方法） その他（取り消し確認、ウォレットへの通知など） トランスポートプロトコル 16 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical
17. スキーマ 属性の種類、型 ネームスペース 署名アルゴリズム 署名形式とアルゴリズム クレデンシャルフォーマットにも依存 JSON-LDベース（W3C VC Data Modelなど）：Data Integrity Proof JSONベース（IETF SD-JWT-VCなど）：JSON Web Signature CBORベース（ISO/IEC 18013-5など）：COSE 余談）JSON-LDには正規化の課題（一般論として脆弱な実装になりやすい） データモデル（スキーマ、署名アルゴリズム） 17 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical
18. 様々な標準化団体による標準化が推進（以下は例） 18 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical 対象 標準化団体 技術仕様等 識別 W3C(World Wide Web Consortium) Decentralized Identifiers(DID) core 認証 FIDO Alliance FIDO2, CTAP W3C(World Wide Web Consortium) WebAuthn アクセス認可 OASIS Open XACML OpenID Foundation AuthZEN API認可 IETF(Internet Engineering Task Force) OAuth2.0 フェデレーション OASIS Open SAML OpenID Foundation OpenID Connect OpenID for Verifiable Credentials クレデンシャルフォーマッ ト、データモデル W3C(World Wide Web Consortium) Verifiable Credentials Data Model IETF(Internet Engineering Task Force) SD-JWT-VC ISO(International Organization for Standardization) ISO 18013-5(mdoc)
19. 個別の技術要素だけでは相互運用性は実現できない 発行者・利用者・検証者が同じ技術スタックを同じ方式 で利用している必要がある プロファイルは個別の技術要素の組み合わせを定義する プロファイルを活用することで個別の技術要素を選択する のに比べて簡単に相互運用性を実現することができる 技術プロファイルの必要性 19 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical
20. OpenID4VC HAIP（High Assurance Interoperability Profile） OpenID Foundation DCP WGが策定 クレデンシャルフォーマット：IETF/SD-JWT-VC、ISO/IEC 18013-5 トランスポートプロトコル：OpenID for Verifiable Credential Issuance/Presentations トークン発行：Self-Issued OpenID Provider v2 欧州DIWのArchitecture and reference frameworkに採用 JWT VC Presentation Profile Decentralized Identity Foundationが策定 クレデンシャルフォーマット：W3C JWT VC（W3C VC Data Model1.1） トランスポートプロトコル：OpenID for Verifiable Presentations（ID1） トークン発行：Self-Issued OpenID Provider v2 技術プロファイルの例 20 Technical
21. 技術プロファイルだけでは不十分 機械可読性を持たせるためには値の持つ意味の標準化 が必要 例）男性を表すGender属性値は1なのかMなのか 要するにクレデンシャルの受け渡しができて署名検証がで きても属性値の解釈ができなければ相互運用性があると は言えない 値の持つ意味（セマンティクス） 21 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical
22. 値の持つ意味が標準化されても、値の妥当性（質）を 保証するためのフレームワークが必要 誰がその値の妥当性を認定したのか？ UNESCO標準ベースのフレームワーク 日本：National Qualification Framework（NQF/NIAD） 欧州：European Qualification Framework（EQF/Europass） この辺りは野田先生のパートで・・・ 質保証フレームワーク 22 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical
23. 関連するエンティティ（発行者、ウォレット、検証者）を 信頼できるのか？ クレデンシャルの署名を検証することで確認できるのは改ざんされていないこと 本当に発行者は正しい認定機関なのか？ 本当に発行者は正しく資格情報を付与しているのか？ 信頼できる状態で相互運用するには、各エンティティが一 定の基準で運営されている必要がある この基準を定義したものがトラストフレームワーク トラストフレームワーク 23 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical
24. 国や業界毎に定められ運用されている 米国における政府調達：NIST SP800-63 日本の学術ネットワーク・リソース共有：学術認証フェデレーション（学認） 日本の金融取引：犯罪収益移転防止法 日本の携帯電話契約：携帯電話不正利用防止法 サービス提供者目線だけではなく、利用者目線も大切 サービス提供者目線：利用者・顧客は信頼できるのか？ 利用者目線：そのサービスは情報を適切に扱ってくれるのか、信頼できるのか？ トラストフレームワーク（Cont.） 24 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical
25. IAL/AAL/FALの3軸でリスクに応じて採用強度を決定 例）NIST SP800-63-3 25 Copyright © 2025, Naohiro Fujie, All Rights Reserved 63A：IAL（Identity Assurance Level） ユーザが申請者（Applicant）として新規登録 （SignUp）する際に、CSP（Credential Service Provider）が行う本人確認 （Identity Proofing）の厳密さ、強度を示す 63B：AAL（Authenticator Assurance Level） 登録済みユーザー（Claimant）がログインす る際の認証プロセス（単要素認証or多要素認 証、認証手段）の強度を示す 63C：FAL（Federation Assurance Level） IDトークンやSAML Assertion等、Assertion のフォーマットやデータやり取りの仕方の強 度を示す Non-Technical
26. リソースアクセスをシームレスに行うための国際的なルール 例）どの国の大学でもeduRoamに繋がる 日本では国立情報学研究所が運営する「学術認証フェ デレーション（学認）」 学認技術運用基準に則って運営されるIdPとSPを認定 国外のフェデレーションとの連携 eduGainを通じてフェデレーション間連携を実現（例：米国InCommon） 現状はSAMLベースのフェデレーションが対象 IHV（Issuer-Holder-Verifier）モデルに合わせてブラッシュアップの動き 学術機関におけるトラストフレームワーク 26 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical
27. 27 Copyright 2018 OpenID Foundation Japan - All Rights Reserved. 出典）JICS2013 学認トラストフレームワーク 東京大学 佐藤先生 学生、教職員 大学、機関 電子ジャーナル などのアプリ 国立情報学研究所 （NII）が運営 Non-Technical
28. 標準技術仕様を採用しただけではダメ 信頼と質保証の枠組み（質保証フレームワーク、トラスト フレームワーク）に関する合意も必要 技術と非技術の両方をカバーしたプロファイルが必要 個別にすり合わせをしているだけだと相互運用には至らな いのでより大きな枠組み（グローバル、国際、地域、業 界など）が必要 技術・非技術両方のプロファイルが必要 28 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical Non-Technical
29. 学修歴クレデンシャルの相互運用性とは Copyright © 2025, Naohiro Fujie, All Rights Reserved 29
30. しばしば話が混ざって会話されていることも 学修歴、単位認定 卒業証明、成績証明 他にも学生証など身分証明書なども クレデンシャルの用途も混ざっているので要件が不明確 クレデンシャルの用途と管理要件 with 慶應義塾（後述）で整理 関与している団体も様々（国内も国外も） 1EdTech、JMOOC、DCC（MIT）、DC4EU（EU）、DG-Connect（EU）、 VC4ED（W3C）、、 アカデミアにおけるデジタルクレデンシャル 30 Copyright © 2025, Naohiro Fujie, All Rights Reserved
31. ウォレットにクレデンシャルを格納して持ち運ぶモデル 構成要素（IHV） Issuer Holder Verifier フェデレーションにはない新たなシナリオへの対応 Issuerがオフラインでも利用できる（例：大学を卒業した後） 複数の標準により構成 クレデンシャルフォーマット（VC、mdocなど）、トランスポートプロトコル （OID4VCI/VP、didcomなど） IHVモデルへの期待が高まる 31
32. EUDIW（2026年末までに展開）のLSP参加 既存のFederation等との連携（eduGain、Europass等） データモデルはELM（European Learning Model） Status Listに分散台帳を利用 想定ユースケース 国境を越えた入学手続き 専門職資格の検証 生涯学習の認定と蓄積 欧州の動向：DC4EU（Digital Credentials for European Union） 32 Copyright © 2025, Naohiro Fujie, All Rights Reserved
33. https://dal.sfc.keio.ac.jp/ja/TR/management-requirements-for-digital-credentials/ ディスカッションペーパー with 慶應
34. 何に使うクレデンシャルなのかを明確化することが重要 身元確認書類として本人確認に利用 資格証明や属性証明に利用 クレデンシャルを行使する主体の違いを認識する 基本的に身元確認書類は本人が利用する暗黙の前提あり 資格証明、属性証明は本人以外の主体が利用する可能性あり ポイントはVerifierの目線で考えること Verifierが当該のクレデンシャルを何の目的で使うことを想定して発行するか？ 目的外利用されない工夫も必要（ex. 成績証明で身元確認？） • Open Badgesをウォレットに入れると身元確認に使いたくなる人もいるはず クレデンシャルをデジタル化する前に 34
35. 身元確認でのでのクレデンシャルの使い方 について Copyright © 2025, Naohiro Fujie, All Rights Reserved 35 参考
36. 本人確認は身元確認と当人認証より構成される 本人確認と身元確認 36 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）民間事業者向けの業界横断的なデジタル本人確認のガイドライン/OpenIDファウンデーションジャパン、2023年 https://www.openid.or.jp/news/2023/03/kycwg.html 参考
37. 主にデジタルクレデンシャルが関係するのは身元確認 デジタルクレデンシャルとの関係性は？ 37 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）民間事業者向けの業界横断的なデジタル本人確認のガイドライン/OpenIDファウンデーションジャパン、2023年 https://www.openid.or.jp/news/2023/03/kycwg.html 参考
38. 主にResolutionとValidation（NIST定義）で利用される 身元確認プロセスの分解とデジタルクレデンシャル 38 Copyright © 2025, Naohiro Fujie, All Rights Reserved Resolution 属性とエビデンス収集 Validation 属性とエビデンスの真正性確認 Verification エビデンスと提示者の同一性確認 出典）NIST SP800-63A https://pages.nist.gov/800-63-3/sp800-63a.html 参考
39. 身元確認書類として使う場合は特に重要 Verifierが当該クレデンシャルが確かに提示者となるHolderに対して発行された ことを判別・判定できること みだりに大量発行されていないこと（同時に発行できる枚数の制限など） 証明書のライフサイクル全般にわたってステータスの管理（取り消しなど）ができ ること 実装に向けた要件の例 Holder・クレデンシャル・Walletインスタンスがそれぞれバインディングできること Issuer起点でクレデンシャルの発行状態を保持・管理すること Issuer起点で発行済みクレデンシャルを特定して取り消しできること クレデンシャルの状態管理の必要性 39 Copyright © 2025, Naohiro Fujie, All Rights Reserved 参考
40. IHVモデルの構成 40 参考
41. 一般的な期待事項 OB3はW3C Verifiable Credentials Data Model（W3C VCDM）をベースに 構成されており、グローバル標準に準拠しているため、相互運用性が高い 実はそうでもない OB3では、あくまでデータモデルとしてW3C VCDMを利用しているだけ APIはOpen Badges独自で一般的なVCを扱うトランスポートプロトコルとの互換性はない Verifiable Credentialsと一言で言ってもW3C VCDM 1.1（JWT/JSON-LD混在）/2.0 （JSON-LD）、IETF SD-JWT VC、もっと広義ではISO/IEC 18013-5のmdocや anonCreds（Hyperledger）などを含めVCと呼んでしまっているケースがあり、「VCだから 大丈夫」にはならない Open Badges 3.0（OB3）に対する期待と誤解 41 Copyright © 2025, Naohiro Fujie, All Rights Reserved
42. OB3の標準技術仕様への準拠 識別子（Subject）：URL、IRI、DID（Issuer IdentifierはURI、DID） クレデンシャルフォーマット：W3C VCDM 2.0 他のエコシステムとの相互運用性における課題 W3C VCDM 2.0を参照ではなくコピーしている？ W3CではJSONベースのシリアライズは削除されているがOB3の仕様には残ってしまっている 結果VC DM 2.0準拠といっているが相互運用性がない状態となっている トランスポート（発行・提示）は独自APIベース（Open Badges API） VCを使っているからと言って一般的なIdentity Walletへ格納できるわけではない あくまでOpen Badgesエコシステムの中での標準 Open Badges 3.0と相互運用性 42 Copyright © 2025, Naohiro Fujie, All Rights Reserved
43. OB2で一般的に利用されてきたメールアドレスの課題 複数の人物によって使用される可能性がある 個人の所属（職場や学校）が変わると無効になることが多い セキュリティが不十分である 元々識別子として意図されていない 結局は 結局はVerifier側で検証した識別情報とOB内のidentityHashを比較 Verifierで検証できる識別子（メールアドレスなど）を渡す必要がある DIDと当人の紐付けは誰が管理するの？ Walletの機種変更などでDIDを引き継げないのが実態 識別子としてのDIDの利用 43 Copyright © 2025, Naohiro Fujie, All Rights Reserved
44. Copyright © 2025, Naohiro Fujie, All Rights Reserved 一般的なVCのトランスポートプロトコル 44 IssuerからWalletへのVC発行 OpenID for Verifiable Credential Issuance Walletに格納したVCの提示 OpenID for Verifiable Presentations https://openid.net/sg/openid4vc/specifications/
45. Validation：VPの署名検証、VCの署名検証 Verification：VP Issuer/VC Subjectの一致検証 一般的なVCのValidationとVerification 45 署名検証 HolderとVC Subjectの 同一性検証 これで検証できるのは、 VCが発行後に改ざんされていないこと VCが発行されたウォレットから移動していないこと のみ。 ウォレットが別の人に操作されていないか等、ウォレットの利 用者が意図した人かどうかは検証できず、VC発行時の ユーザ認証やVC提示前のウォレットのロック解除の仕組み に依存している Copyright © 2025, Naohiro Fujie, All Rights Reserved ※本ドキュメントにおけるValidation/Verificationの用法はNIST SP800-63 をベースとする。ISO9000等における一般的な定義とは異なる点に注意
46. トランスポート あくまでOBプロトコル（発行系はあるが提示系は存在しない） DCC@MITのLearners WalletプロジェクトではOpenID for VCI/VPを試行 Validation/Verification Validation OB3の仕様としてはスコープ外（W3C VCDMに定義された方式を利用） Verification Verifier側で取得した識別子とSubjectのidentityHashの一致を検証 結局はVerifierで検証できる識別子（メールアドレスなど）を渡す必要がある （IdentifierTypeEnumにdidがない） OB3におけるトランスポートとVerification 46 Copyright © 2025, Naohiro Fujie, All Rights Reserved
47. ID基盤の3つのタイプ Federated：学認など Wallet Based：EU DIWなど API Based：Open Badgesなど 接続パターン Direct Proxy/Broker SIDI Hubの相互運用性パターン 47 Copyright © 2025, Naohiro Fujie, All Rights Reserved Federated API Based Wallet Based SIDI Hub（Sustainable and Interoperable Digital Identity Hub）： サステイナブルで相互運用性のあるデジタルアイデンティティについて検討する国際コミュニティ
48. 既存のシステムを変更するのは難しい Proxy/brokerが必要となる可能性が高い Proxy/brokerへの信頼性の課題は残るので、包括的な合意なども 検討が必要（安易にGatewayビジネスを始める事業者に注意） オーバーレイ・アプローチが必要 48 Copyright © 2025, Naohiro Fujie, All Rights Reserved IdP Issuer Verifier Relying Party Wallet Federation Federation IHV Model
49. Proxy/Brokerをどうやって信頼するのか クレデンシャルの署名がProxy/Brokerになってしまう 本来の発行者の署名を解いて再署名するか 派生クレデンシャルの課題 再署名するということは原本ではなくなる 原本とコピーと派生の課題（同じく慶應とのディスカッションペーパーに詳しくは記 載）については次ページ以降で オーバーレイ・アプローチの問題 49 Copyright © 2025, Naohiro Fujie, All Rights Reserved
50. クレデンシャルの段階の例（原本～派生まで） 50 Copyright © 2025, Naohiro Fujie, All Rights Reserved 現実世界 発行者が直接発行したもの（例：パス ポート） 発行者が直接発行したもの（発行者が 複数発行することが可能なもの。原本と して扱うことができるもの） コピー機等で複写されたもの（例：パス ポートのコピー） 原本の発行者以外の第三者が原本を 元に別途発行したもの（例：「本人確 認済み」のスタンプが押された書類） デジタル世界 電子署名とタイプスタンプを組み合わせ て作成以後改ざんされていないことが証 明できるもの 原本を電子的に複製したもの（原本と 明確な差異はない） 原本の発行者以外の第三者が原本を 元に別途発行したもの
51. クレデンシャルの段階の例（原本～派生まで） 51 Copyright © 2025, Naohiro Fujie, All Rights Reserved 現実世界 発行者が直接発行したもの（例：パス ポート） 発行者が直接発行したもの（発行者が 複数発行することが可能なもの。原本と して扱うことができるもの） コピー機等で複写されたもの（例：パス ポートのコピー） 原本の発行者以外の第三者が原本を 元に別途発行したもの（例：「本人確 認済み」のスタンプが押された書類） デジタル世界 電子署名とタイプスタンプを組み合わせ て作成以後改ざんされていないことが証 明できるもの 原本を電子的に複製したもの（原本と 明確な差異はない） 原本の発行者以外の第三者が原本を 元に別途発行したもの 複製（Duplicate） 派生（Derived） 原本（Original）
52. 技術的には明確な違いがある 署名者が異なる 当然ビット配列も異なる 完全に別のもの 利用者やVerifierの解釈が“混ざる”ことがある マイナンバーカードで本人確認を行なったデジタル証明書 マイナンバーカードをデジタル化した証明書（カード代替電磁的記録） ビジネスの視点？ あえて混乱させた方が“売れる”かも？→ゲートウェイ事業者が蔓延ると悲劇 原本と派生クレデンシャルの問題 52 Copyright © 2025, Naohiro Fujie, All Rights Reserved
53. とはいえ、中間地点となるテンポラリ解の検討は必要。 学認LMSで発行したコース受講証明の利活用に関する検討 発行側）Moodleから取得したOBをWalletへ発行 MoodleとWalletの間にIHVモデルに対応したVC Issuerサービスを構築 当時はOB2だったため、Moodleから取得したOBをVCに埋め込んでWalletへ発行 提示側）VCをSAML Assertionに埋め込み提示 Walletから提示されたVP/VCを検証した後にSAML Assertionとして再構成、SAMLプロト コルに対応したSP（アプリケーション）へ提示するConnectorサービスを構築 NIIでの実証実験（学認LMS） 53 Copyright © 2025, Naohiro Fujie, All Rights Reserved
54. 全体構成）ゲートウェイアプローチ 54 Copyright © 2025, Naohiro Fujie, All Rights Reserved 学認LMS (Moodle) OB2VC Gateway 学認IdP Wallet SP Connector Wallet 学認RDM d. Get OpenBadge via API b. SAML Federation b. SAML Federation e. SAML Federation b. SAML Federation a. Sign in to Gateway c. User authentication a. Sign in to GakuNin LMS e. Show and scan QR code f. Store badge as a VC d. Get badge c. User authentication a. Sign in to GakuNin RDM c. User authentication d. Access restricted page f. Show and scan QR code g. Present VP/VC h. Send SAML Assertion(via user agent) i. Get badge information from SAML Assertion • 学認LMSでOBを発行 • 利用者のWalletへOBを埋め込んだVCを発行 • Wallet SPコネクタを経由して学認RDMへVC（OBを含む）を提示
55. 既存のトラストフレームワークの拡張検討 with NII 55 Copyright © 2025, Naohiro Fujie, All Rights Reserved 学術機関 Issuer 認定サービス Verifier ウォレットプロバイダー ウォレットインスタンス 例 在学証明書 Status List プロバイダー 利用者 提供・維持 使用・有効化 参照 登録・維持 発行 提示 参照 トラストリスト プロバイダー 参照 非認定サービス Verifier 例 在学証明書 教育資格基準準拠 教育機関レポジトリー 質評価機関 Trust Framework Qualification Framework 信頼評価機関 評価を実施し、参加エンティティが定められた 基準に準拠して運用していることを担保 教育資格基準 への準拠品質 参加エンティティ運用基準への準拠品質 Framework の保証対象 関連する Framework と そのエンティティ 学術機関 Issuerを 運営する 機関が 定められた 教育資格 基準を 満たすことの 信頼アンカー としてQF を参照 評価を実施し、学術機関が定められた 教育資格基準に準拠していることを担保
56. 相互運用性は技術の話だけではない クレデンシャルフォーマット、トランスポート、スキーマだけでなくセマンティクスや質保 証やトラストに関するフレームワークが重要 標準技術仕様を採用したからと言って相互運用性があ るとは限らない OB3はW3C VCDMをベースにしているが、一般的なIDウォレットの対応している トランスポート（OpenID for VCI/VP）への対応はしていない 信頼性・検証可能性を維持するための仕組みが大切 相互運用性を一時的に得るためにゲートウェイを作るのは良いが、永続させては ならない まとめ 56 Copyright © 2025, Naohiro Fujie, All Rights Reserved