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

Slide 1

Slide 1 text

相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向 2025/8/1 伊藤忠テクノソリューションズ株式会社一般社団法人 OpenID ファウンデーション・ジャパン/代表理事米国OpenID Foundation/共同議長 eKYC&IDA WG 富士榮尚寛（ふじえなおひろ）

Slide 2

Slide 2 text

自己紹介デジタルアイデンティティ分野で約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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Source: https://onekeyresources.milwaukeetool.com/en/construction-software-interoperability

Slide 8

Slide 8 text

Slide 9

Slide 9 text

国、機関、業界などを超えて自由に行使できる状態発行機関、利用者の環境、行使先サービスに依存せずプライバシーに配慮した状態（利用者が安心して自由に行使できる状態）例）日本の大学が発行した卒業証明書をアメリカの企業に就職する際に使える民間企業の発行した資格証明を使って単位認定する機械可読性、信頼性が自由なデータ流通実現の要 DFFT（Data Free Flow with Trust）、Trusted Webの考え方信頼するための一定のガバナンスを確保した状態での自由な流通を促進するクレデンシャルの相互運用性とは 9 Copyright © 2025, Naohiro Fujie, All Rights Reserved

Slide 10

Slide 10 text

Slide 11

Slide 11 text

集合の中で実体を一意に識別するための属性情報（一つとは限らない）スコープに依存する国内、国際、グローバル例）日本の中に「富士榮」は複数いるので苗字は識別子にならないが、大阪府の中なら苗字で識別できるプライバシーと永続性に対する考慮が必要変更できない識別子だとプライバシーの課題ありメールアドレス、学籍番号などは卒業後や他機関へ異動したときに課題識別子（Identifiers）の形式 11 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical ⽇本⼤阪府富⼠榮富⼠榮富⼠榮富⼠榮

Slide 12

Slide 12 text

エンティティとアイデンティティの関係性 12 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）@_NAT ZONE https://www.sakimura.org/2011/06/1124/ • エンティティ（主体・実体）は直接観測できない • アイデンティティ（属性の集合）を通じて認識・観測する • 自観：提供する属性を通じ、他人に見てほしい「自己像」 • 他観：提供された属性を通じ、実際に感じ取った「自己像」 • 提供する相手毎に提供する属性を変えて「自己像」を形成（コンテキストの切り替え）余談

Slide 13

Slide 13 text

コンテキスト毎に自己像を構築し、やりとりを行う 13 国地域現在の職場取引先出身校以前の職場家族 XX大学出身 YY社での実績 ⇒採用 ZZ社所属 ⇒取引 XX大学出身 ⇒採用 A県出身 ⇒入寮許可家族構成 ZZ社所属 ⇒補助金 XX大学出身 ZZ社所属 ⇒結婚コンテキスト・関係性余談

Slide 14

Slide 14 text

コンテキスト侵害→プライバシー侵害 14 国地域現在の職場取引先出身校以前の職場家族親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要職場での姿 ⇒家族に知られたくない？学生時代の交友関係 ⇒労働には無関係 ○○地区出身 ⇒採用には無関係職場での姿 ⇒家族に知られたくない？余談

Slide 15

Slide 15 text

コンテキスト侵害→プライバシー侵害 15 国地域現在の職場取引先出身校以前の職場家族親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要職場での姿 ⇒家族に知られたくない？学生時代の交友関係 ⇒労働には無関係 ○○地区出身 ⇒採用には無関係職場での姿 ⇒家族に知られたくない？コンテキスト毎に自己像を自身の意思で形成することが必要コンテキストごとに識別子を分けられることが重要余談

Slide 16

Slide 16 text

Slide 17

Slide 17 text

スキーマ属性の種類、型ネームスペース署名アルゴリズム署名形式とアルゴリズムクレデンシャルフォーマットにも依存 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

Slide 18

Slide 18 text

様々な標準化団体による標準化が推進（以下は例） 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)

Slide 19

Slide 19 text

個別の技術要素だけでは相互運用性は実現できない発行者・利用者・検証者が同じ技術スタックを同じ方式で利用している必要があるプロファイルは個別の技術要素の組み合わせを定義するプロファイルを活用することで個別の技術要素を選択するのに比べて簡単に相互運用性を実現することができる技術プロファイルの必要性 19 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

技術プロファイルだけでは不十分機械可読性を持たせるためには値の持つ意味の標準化が必要例）男性を表すGender属性値は1なのかMなのか要するにクレデンシャルの受け渡しができて署名検証ができても属性値の解釈ができなければ相互運用性があるとは言えない値の持つ意味（セマンティクス） 21 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical

Slide 22

Slide 22 text

値の持つ意味が標準化されても、値の妥当性（質）を保証するためのフレームワークが必要誰がその値の妥当性を認定したのか？ UNESCO標準ベースのフレームワーク日本：National Qualification Framework（NQF/NIAD）欧州：European Qualification Framework（EQF/Europass）この辺りは野田先生のパートで・・・質保証フレームワーク 22 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical

Slide 23

Slide 23 text

関連するエンティティ（発行者、ウォレット、検証者）を信頼できるのか？クレデンシャルの署名を検証することで確認できるのは改ざんされていないこと本当に発行者は正しい認定機関なのか？本当に発行者は正しく資格情報を付与しているのか？信頼できる状態で相互運用するには、各エンティティが一定の基準で運営されている必要があるこの基準を定義したものがトラストフレームワークトラストフレームワーク 23 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical

Slide 24

Slide 24 text

国や業界毎に定められ運用されている米国における政府調達：NIST SP800-63 日本の学術ネットワーク・リソース共有：学術認証フェデレーション（学認）日本の金融取引：犯罪収益移転防止法日本の携帯電話契約：携帯電話不正利用防止法サービス提供者目線だけではなく、利用者目線も大切サービス提供者目線：利用者・顧客は信頼できるのか？利用者目線：そのサービスは情報を適切に扱ってくれるのか、信頼できるのか？トラストフレームワーク（Cont.） 24 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

リソースアクセスをシームレスに行うための国際的なルール例）どの国の大学でもeduRoamに繋がる日本では国立情報学研究所が運営する「学術認証フェデレーション（学認）」学認技術運用基準に則って運営されるIdPとSPを認定国外のフェデレーションとの連携 eduGainを通じてフェデレーション間連携を実現（例：米国InCommon）現状はSAMLベースのフェデレーションが対象 IHV（Issuer-Holder-Verifier）モデルに合わせてブラッシュアップの動き学術機関におけるトラストフレームワーク 26 Copyright © 2025, Naohiro Fujie, All Rights Reserved Non-Technical

Slide 27

Slide 27 text

Slide 28

Slide 28 text

標準技術仕様を採用しただけではダメ信頼と質保証の枠組み（質保証フレームワーク、トラストフレームワーク）に関する合意も必要技術と非技術の両方をカバーしたプロファイルが必要個別にすり合わせをしているだけだと相互運用には至らないのでより大きな枠組み（グローバル、国際、地域、業界など）が必要技術・非技術両方のプロファイルが必要 28 Copyright © 2025, Naohiro Fujie, All Rights Reserved Technical Non-Technical

Slide 29

Slide 29 text

Slide 30

Slide 30 text

しばしば話が混ざって会話されていることも学修歴、単位認定卒業証明、成績証明他にも学生証など身分証明書などもクレデンシャルの用途も混ざっているので要件が不明確クレデンシャルの用途と管理要件 with 慶應義塾（後述）で整理関与している団体も様々（国内も国外も） 1EdTech、JMOOC、DCC（MIT）、DC4EU（EU）、DG-Connect（EU）、 VC4ED（W3C）、、アカデミアにおけるデジタルクレデンシャル 30 Copyright © 2025, Naohiro Fujie, All Rights Reserved

Slide 31

Slide 31 text

ウォレットにクレデンシャルを格納して持ち運ぶモデル構成要素（IHV） Issuer Holder Verifier フェデレーションにはない新たなシナリオへの対応 Issuerがオフラインでも利用できる（例：大学を卒業した後）複数の標準により構成クレデンシャルフォーマット（VC、mdocなど）、トランスポートプロトコル（OID4VCI/VP、didcomなど） IHVモデルへの期待が高まる 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

https://dal.sfc.keio.ac.jp/ja/TR/management-requirements-for-digital-credentials/ ディスカッションペーパー with 慶應

Slide 34

Slide 34 text

何に使うクレデンシャルなのかを明確化することが重要身元確認書類として本人確認に利用資格証明や属性証明に利用クレデンシャルを行使する主体の違いを認識する基本的に身元確認書類は本人が利用する暗黙の前提あり資格証明、属性証明は本人以外の主体が利用する可能性ありポイントはVerifierの目線で考えること Verifierが当該のクレデンシャルを何の目的で使うことを想定して発行するか？目的外利用されない工夫も必要（ex. 成績証明で身元確認？） • Open Badgesをウォレットに入れると身元確認に使いたくなる人もいるはずクレデンシャルをデジタル化する前に 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

主にデジタルクレデンシャルが関係するのは身元確認デジタルクレデンシャルとの関係性は？ 37 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）民間事業者向けの業界横断的なデジタル本人確認のガイドライン/OpenIDファウンデーションジャパン、2023年 https://www.openid.or.jp/news/2023/03/kycwg.html 参考

Slide 38

Slide 38 text

主に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 参考

Slide 39

Slide 39 text

身元確認書類として使う場合は特に重要 Verifierが当該クレデンシャルが確かに提示者となるHolderに対して発行されたことを判別・判定できることみだりに大量発行されていないこと（同時に発行できる枚数の制限など）証明書のライフサイクル全般にわたってステータスの管理（取り消しなど）ができること実装に向けた要件の例 Holder・クレデンシャル・Walletインスタンスがそれぞれバインディングできること Issuer起点でクレデンシャルの発行状態を保持・管理すること Issuer起点で発行済みクレデンシャルを特定して取り消しできることクレデンシャルの状態管理の必要性 39 Copyright © 2025, Naohiro Fujie, All Rights Reserved 参考

Slide 40

Slide 40 text

IHVモデルの構成 40 参考

Slide 41

Slide 41 text

一般的な期待事項 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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

OB2で一般的に利用されてきたメールアドレスの課題複数の人物によって使用される可能性がある個人の所属（職場や学校）が変わると無効になることが多いセキュリティが不十分である元々識別子として意図されていない結局は結局はVerifier側で検証した識別情報とOB内のidentityHashを比較 Verifierで検証できる識別子（メールアドレスなど）を渡す必要がある DIDと当人の紐付けは誰が管理するの？ Walletの機種変更などでDIDを引き継げないのが実態識別子としてのDIDの利用 43 Copyright © 2025, Naohiro Fujie, All Rights Reserved

Slide 44

Slide 44 text

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/

Slide 45

Slide 45 text

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等における一般的な定義とは異なる点に注意

Slide 46

Slide 46 text

トランスポートあくまで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

Slide 47

Slide 47 text

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）：サステイナブルで相互運用性のあるデジタルアイデンティティについて検討する国際コミュニティ

Slide 48

Slide 48 text

既存のシステムを変更するのは難しい Proxy/brokerが必要となる可能性が高い Proxy/brokerへの信頼性の課題は残るので、包括的な合意なども検討が必要（安易にGatewayビジネスを始める事業者に注意）オーバーレイ・アプローチが必要 48 Copyright © 2025, Naohiro Fujie, All Rights Reserved IdP Issuer Verifier Relying Party Wallet Federation Federation IHV Model

Slide 49

Slide 49 text

Proxy/Brokerをどうやって信頼するのかクレデンシャルの署名がProxy/Brokerになってしまう本来の発行者の署名を解いて再署名するか派生クレデンシャルの課題再署名するということは原本ではなくなる原本とコピーと派生の課題（同じく慶應とのディスカッションペーパーに詳しくは記載）については次ページ以降でオーバーレイ・アプローチの問題 49 Copyright © 2025, Naohiro Fujie, All Rights Reserved

Slide 50

Slide 50 text

クレデンシャルの段階の例（原本～派生まで） 50 Copyright © 2025, Naohiro Fujie, All Rights Reserved 現実世界発行者が直接発行したもの（例：パスポート）発行者が直接発行したもの（発行者が複数発行することが可能なもの。原本として扱うことができるもの）コピー機等で複写されたもの（例：パスポートのコピー）原本の発行者以外の第三者が原本を元に別途発行したもの（例：「本人確認済み」のスタンプが押された書類）デジタル世界電子署名とタイプスタンプを組み合わせて作成以後改ざんされていないことが証明できるもの原本を電子的に複製したもの（原本と明確な差異はない）原本の発行者以外の第三者が原本を元に別途発行したもの

Slide 51

Slide 51 text

クレデンシャルの段階の例（原本～派生まで） 51 Copyright © 2025, Naohiro Fujie, All Rights Reserved 現実世界発行者が直接発行したもの（例：パスポート）発行者が直接発行したもの（発行者が複数発行することが可能なもの。原本として扱うことができるもの）コピー機等で複写されたもの（例：パスポートのコピー）原本の発行者以外の第三者が原本を元に別途発行したもの（例：「本人確認済み」のスタンプが押された書類）デジタル世界電子署名とタイプスタンプを組み合わせて作成以後改ざんされていないことが証明できるもの原本を電子的に複製したもの（原本と明確な差異はない）原本の発行者以外の第三者が原本を元に別途発行したもの複製（Duplicate）派生（Derived）原本（Original）

Slide 52

Slide 52 text

技術的には明確な違いがある署名者が異なる当然ビット配列も異なる完全に別のもの利用者やVerifierの解釈が“混ざる”ことがあるマイナンバーカードで本人確認を行なったデジタル証明書マイナンバーカードをデジタル化した証明書（カード代替電磁的記録）ビジネスの視点？あえて混乱させた方が“売れる”かも？→ゲートウェイ事業者が蔓延ると悲劇原本と派生クレデンシャルの問題 52 Copyright © 2025, Naohiro Fujie, All Rights Reserved

Slide 53

Slide 53 text

とはいえ、中間地点となるテンポラリ解の検討は必要。学認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

Slide 54

Slide 54 text

全体構成）ゲートウェイアプローチ 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を含む）を提示

Slide 55

Slide 55 text

既存のトラストフレームワークの拡張検討 with NII 55 Copyright © 2025, Naohiro Fujie, All Rights Reserved 学術機関 Issuer 認定サービス Verifier ウォレットプロバイダーウォレットインスタンス例在学証明書 Status List プロバイダー利用者提供・維持使用・有効化参照登録・維持発行提示参照トラストリストプロバイダー参照非認定サービス Verifier 例在学証明書教育資格基準準拠教育機関レポジトリー質評価機関 Trust Framework Qualification Framework 信頼評価機関評価を実施し、参加エンティティが定められた基準に準拠して運用していることを担保教育資格基準への準拠品質参加エンティティ運用基準への準拠品質 Framework の保証対象関連する Framework とそのエンティティ学術機関 Issuerを運営する機関が定められた教育資格基準を満たすことの信頼アンカーとしてQF を参照評価を実施し、学術機関が定められた教育資格基準に準拠していることを担保

Slide 56

Slide 56 text

相互運用性は技術の話だけではないクレデンシャルフォーマット、トランスポート、スキーマだけでなくセマンティクスや質保証やトラストに関するフレームワークが重要標準技術仕様を採用したからと言って相互運用性があるとは限らない OB3はW3C VCDMをベースにしているが、一般的なIDウォレットの対応しているトランスポート（OpenID for VCI/VP）への対応はしていない信頼性・検証可能性を維持するための仕組みが大切相互運用性を一時的に得るためにゲートウェイを作るのは良いが、永続させてはならないまとめ 56 Copyright © 2025, Naohiro Fujie, All Rights Reserved