概要
SSIの実行環境
はじめに
ロール別SSIガイドです。3つの役割を順にたどり、データ境界を理解し、Web、サーバー、モバイルSDKの例を比較します。
自己主権型IDは、各責任の主体を明確にすると理解しやすくなります。発行者が検証可能なクレデンシャル(VC)を作成し、保有者がモバイル端末の安全な保管庫に保存し、検証者が検証可能な提示内容(VP)を要求して検証します。
重要な注意
[発行者がVCを確認・署名] -> [保有者がモバイル端末に保管] -> [保有者が同意してVPを作成] -> [検証者がVPを検証]
主要概念
発行者
元データを確認してクレデンシャルへ署名し、DIDCommで受け取り案内を送ります。
保有者
1台のモバイル端末にある安全な保管庫でクレデンシャルを保管し、開示する属性を決めます。
検証者
必要な属性だけを要求し、署名、チャレンジ値、クレデンシャルの状態を確認します。
DIDレジストリ
CertNet、did:web、ION、社内レジストリでDID文書を公開・解決します。
クレデンシャル境界
はじめに
Identraは責任を明確に分離します。発行者がVCを作成し、保有者の電話だけが唯一の保管庫となり、検証者はVPを要求して検証するだけです。
最も重要なルール
Webとサーバーには保管用SDKを提供しません。利用者のVCをインポート、エクスポート、バックアップすることはできません。
DIDレジストリはCertNetに固定されない
CertNetはSandboxの既定プロバイダーです。同じSDKで、デプロイ方針に応じてCertNet、did:web、ION、社内レジストリへDID文書を公開し、解決できます。
重要な注意
説明用SDKであり、本番利用向けではありません。このOverviewに示すパッケージ名と契約仕様はサンプル文書です。
クレデンシャル発行
発行者
ロール別SSIフローのステップ01/03です。
誰がクレデンシャルを作り、コードはどこで動くのか
発行者はデータを確認し、VCへ署名して利用者へ送ります。社内Web、サーバー、アプリのいずれにも組み込めます。
データと鍵の境界
組織の署名鍵は実行環境に応じて保護する必要があります。サーバーではHSMを優先します。
リファレンス
| 実行環境 | SDK例 | 使う場面 |
|---|---|---|
| Webクライアント | @identra/web(Browser JavaScriptまたはTypeScript) | 鍵ポリシーを管理できる社内発行ツール |
| サーバー | @identra/nodeまたはidentra-go | HSMや管理KMSで保護する署名サービス |
| モバイルアプリ | @identra/react-native、Android SDK、iOS SDK | 管理対象の社内発行アプリ |
フローの手順
- 初期化: 現在の実行環境向けにSDKを初期化します。
- DID作成: 選択したDIDレジストリで発行者DIDを作成または読み込みます。
- VC署名: 受け取り側DID向けに検証可能なクレデンシャルへ署名します。
- オファー送信: DIDCommでクレデンシャルオファーを送ります。
コード例
1. 実行環境を選択
2. SDKと言語を選択
import { Identra } from '@identra/web';
// 説明用SDKであり、本番利用向けではありません。
const identra = new Identra({
environment: 'sandbox',
didRegistry: {
defaultProvider: 'certnet',
providers: ['certnet', 'did:web', 'ion', 'internal-ledger']
},
mediatorUrl: 'https://mediator.sandbox.identra.dev'
});
// 発行者側で動作します。Web、サーバー、社内アプリで利用できます。
const issuer = await identra.issuer.create({
did: 'did:identra:university',
keyProtection: 'platform-secure-storage'
});
// DID文書は複数のレジストリへ公開できます。CertNetはSandboxの既定プロバイダーにすぎません。
await issuer.publishDidDocument({
registries: ['certnet', 'did:web']
});
const credential = await issuer.issue({
// 保有者DIDは接続確立後、または業務システムから取得します。
subjectDid: 'did:identra:holder',
type: 'UniversityDegree',
claims: { degree: 'Information Technology', graduationYear: 2026 }
});
// クレデンシャルはQRに入れません。QRはDIDComm接続を開始するためだけに使います。
await issuer.didcomm.sendCredentialOffer({ credential, connectionId });詳細
保有者DIDは接続確立後、または業務システムから取得します。クレデンシャルはQRに入れず、QRはDIDComm接続を開始するためだけに使います。
クレデンシャル検証
検証者
ロール別SSIフローのステップ03/03です。
検証者はどのようにVPを信頼するのか
検証者はVPを受信し、保有者と発行者のDIDを取り出し、CertNet、did:web、IONなど対応するレジストリプロバイダーでDID文書を解決してから、署名、チャレンジ、失効状態を確認します。
データと保存の境界
検証者はWeb、サーバー、アプリで動かせますが、保有者のようにVCを保存してはいけません。
ガイド
- 要求作成: 再送攻撃に強いチャレンジ付きの提示要求を作成します。
- QR表示: DIDComm invitationを含むQRを表示します。
- VP受信: 新しく確立した接続でVPを受け取ります。
- 解決と検証: 保有者と発行者のDIDをレジストリプロバイダーで解決し、検証します。
コード例
1. 実行環境を選択
2. SDKと言語を選択
import { Identra } from '@identra/web';
// 説明用SDKであり、本番利用向けではありません。
const identra = new Identra({
environment: 'sandbox',
didRegistry: {
defaultProvider: 'certnet',
providers: ['certnet', 'did:web', 'ion', 'internal-ledger']
},
mediatorUrl: 'https://mediator.sandbox.identra.dev'
});
// 検証者側で動作します。Web、サーバー、アプリで利用できます。
const verifier = await identra.verifier.create({
did: 'did:identra:jobs-example'
});
const request = await verifier.createPresentationRequest({
credentialType: 'UniversityDegree',
// 保有者の開示を減らすため、必要な属性だけを要求します。
fields: ['degree', 'graduationYear'],
challenge: crypto.randomUUID()
});
const qrDataUrl = await verifier.createQr(request);
const presentation = await verifier.didcomm.waitForPresentation(request.id);
const result = await verifier.verify({
presentation,
// SDKは対応するレジストリプロバイダーからDID文書を解決します。
resolveDid: (did) => identra.didRegistry.resolveDidDocument(did),
checkCredentialStatus: true
});
if (result.verified) grantAccess();このページは役に立ちましたか?
改善のため、ご意見をお聞かせください。