VCALM v1.0

概要

検証可能なクレデンシャルは、暗号学的に安全で、プライバシーを尊重し、機械で検証可能な方法で、Web 上にクレデンシャルを表現する仕組みを提供します。この仕様は、そのようなエコシステムで使用されるデータを発行、検証、提示、管理するためのデータモデルと HTTP プロトコルを提供します。

目標	説明
モジュール性	実装者は、ユースケースに必要な API のみを実装すればよく、発行、検証、提示の間でモジュール性を実現できます。
単純性	API の数と任意性は最小限に抑えられており、セキュリティの観点から実装および監査しやすいものになっています。
組み合わせ可能性	API は組み合わせ可能になるよう設計されており、少数の単純な API プリミティブを使用して複雑なフローを実現できます。
拡張性	API エンドポイントへの拡張は想定されており、API 設計で対応されています。これにより、基盤 API プラットフォーム上での実験や付加価値サービスの追加が可能になります。

VCALM OAuth 2.0 スコープ構文
scope = operation ":" path-absolute ([RFC3986] で定義) operation = "read" / "write"

この節には、適合する実装を作成する際に従うべき HTTP API エンドポイント定義と実装ガイダンスが含まれています。

この節では、エンドポイントが呼び出し可能であると想定されるコンポーネントごとに、 VC-API 内のすべてのエンドポイントの概要を示します。コンポーネントの下に一覧がない場合、それは VC-API が現在そのコンポーネント用のエンドポイントを規定していないことを意味します。

以下は、発行者コーディネーターによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
GET /interactions/{interactionId}	提供された URL を持つ誰でも	3.7.1 インタラクション URL 形式
POST /callbacks/{localCallbackId}	ワークフロー・サービス	3.6.7 交換ステップのコールバック

以下は、発行者サービスによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
POST /credentials/issue	発行者コーディネーター、ワークフロー・サービス	3.2.1 クレデンシャルの発行
GET /credentials/{id}	発行者コーディネーター、保持者コーディネーター、ワークフロー・サービス	3.2.2 特定のクレデンシャルの取得
DELETE /credentials/{id}	発行者コーディネーター、保持者コーディネーター	3.2.3 特定のクレデンシャルの削除

以下は、検証者コーディネーターによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
GET /interactions/{interactionId}	提供された URL を持つ誰でも	3.7.1 インタラクション URL 形式
POST /callbacks/{localCallbackId}	ワークフロー・サービス	3.6.7 交換ステップのコールバック

以下は、検証者サービスによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
POST /credentials/verify	検証者コーディネーター、ワークフロー・サービス	3.3.1 クレデンシャルの検証
POST /presentations/verify	検証者コーディネーター、ワークフロー・サービス	3.3.2 提示の検証
POST /challenges	検証者コーディネーター、ワークフロー・サービス	3.3.3 チャレンジの作成

以下は、保持者コーディネーターによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
GET /interactions/{interactionId}	提供された URL を持つ誰でも	3.7.1 インタラクション URL 形式
POST /callbacks/{localCallbackId}	ワークフロー・サービス	3.6.7 交換ステップのコールバック

以下は、保持者サービスによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
POST /credentials/derive	保持者コーディネーター、ワークフロー・サービス	3.5.1 クレデンシャルの導出
GET /credentials/{id}	発行者コーディネーター、保持者コーディネーター、ワークフロー・サービス	3.2.2 特定のクレデンシャルの取得
DELETE /credentials/{id}	発行者コーディネーター、保持者コーディネーター	3.2.3 特定のクレデンシャルの削除
GET /presentations	保持者コーディネーター、ワークフロー・サービス	3.5.3 提示の取得
POST /presentations	保持者コーディネーター、ワークフロー・サービス	3.5.2 提示の作成
GET /presentations/{id}	保持者コーディネーター、ワークフロー・サービス	3.5.4 特定の提示の取得
DELETE /presentations/{id}	保持者コーディネーター	3.5.5 特定の提示の削除

以下は、ステータスサービスによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
POST /status-lists	発行者サービス	C.1 ステータスリストの作成
GET /status-lists/{id}	公開	C.2 ステータスリストの取得
POST /credentials/status	発行者サービス	C.3 ステータスの更新

以下は、ワークフロー・サービスによって公開されることが期待されるすべてのエンドポイントと、そのエンドポイントを呼び出すことが期待されるコンポーネントです。

エンドポイント	想定される呼び出し元	定義
POST /workflows	管理者	3.6.1 ワークフローの作成
GET /workflows/{localWorkflowId}	管理者	3.6.2 ワークフロー構成の取得
POST /workflows/{localWorkflowId}/exchanges	コーディネーター	3.6.3 交換の作成
GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}	コーディネーター	3.6.6 交換状態の取得
POST /workflows/{localWorkflowId}/exchanges/{localExchangeId}	誰でも	3.6.5 交換への参加
GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}/protocols	検証者コーディネーター、保持者コーディネーター	3.6.4 交換プロトコルの取得
POST /{inviteId}/invite-request/response	/interactions/{interactionId} を含む URL に POST した者	3.7.4 インタラクション・プロトコル応答

Verifiable Credential を発行するために、以下の API が定義されています。

エンドポイント	説明
GET /credentials/{id}	ID によってクレデンシャルまたは検証可能なクレデンシャルを取得します。 credential.id が設定されていないが、関連付けられた credentialId 値を持つクレデンシャルを取得するには、代わりに credentialId を渡します。
DELETE /credentials/{id}	ID によってクレデンシャルまたは検証可能なクレデンシャルを削除します。 credential.id が設定されていないが、関連付けられた credentialId 値を持つクレデンシャルを削除するには、代わりに credentialId を渡します。
POST /credentials/issue	クレデンシャルを発行し、それを応答本文で返します。
POST /credentials/status	発行済みクレデンシャルのステータスを更新します
POST /status-lists	新しいステータスリストを作成します
GET /status-lists/{id}	ステータスリスト・クレデンシャルを取得します

このエンドポイントは、検証可能なクレデンシャルを発行するために使用されます。

注記: 発行済みクレデンシャルのメディア型

application/vc 以外のメディア型、たとえば application/mdoc、application/vc+sd-jwt、 application/vcb;barcode-format=qr_code、または application/vcb;barcode-format=pdf417 でクレデンシャルを発行するには、応答で EnvelopedVerifiableCredential を返すことができます。

POST /credentials/issue - クレデンシャルを発行し、それを応答本文で返します。

/credentials/issue エンドポイントは、POST を受信する際に以下のスキーマを使用します。

プロパティ説明

プロパティ	説明
`credential` [object]	発行を意図した W3C Verifiable Credential。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] オブジェクト、または { "type": "array", "items": { "type": "object" } }
`options` [object]	クレデンシャルがどのように発行されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。 `mandatoryPointers` [array] 選択的開示方式で、必須の開示文を指定するために使用されます。 `mandatoryPointers` 配列内の各項目は文字列で MUST あります。 `credentialId` [string] クレデンシャルを識別するために使用できる URI であり、API において発行済みの検証可能なクレデンシャルを参照するために使用できます。 credentialId が発行者コーディネーターによって提供されない場合、発行者サービスはその値を credential.id から自動的に設定します。 credentialId も credential.id も提供されない場合、発行後にこのクレデンシャルを参照することも、重複エラーを扱うこともできません。 credential.id プロパティが設定されている場合、credentialId は発行者コーディネーターによって設定されるべきではなく、credential.id の代替として使用されるべきでもありません。むしろ、credentialId は id プロパティ（すなわち credential.id）が設定されていないクレデンシャルを識別する手段です。発行者サービスは、発行者コーディネーターから提供されない場合に credentialId を自動生成すべきではありません。そうすると、結果がクライアントに受信されなかった場合にパーティショニング・エラーを生じさせる可能性があるためです。

credential [object]

発行を意図した W3C Verifiable Credential。これは以下の形式のオブジェクトで MUST あります。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

オブジェクト、または

{
  "type": "array",
  "items": {
    "type": "object"
  }
}

options [object]

クレデンシャルがどのように発行されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。

mandatoryPointers [array]: 選択的開示方式で、必須の開示文を指定するために使用されます。 mandatoryPointers 配列内の各項目は文字列で MUST あります。
credentialId [string]: クレデンシャルを識別するために使用できる URI であり、API において発行済みの検証可能なクレデンシャルを参照するために使用できます。 credentialId が発行者コーディネーターによって提供されない場合、発行者サービスはその値を credential.id から自動的に設定します。 credentialId も credential.id も提供されない場合、発行後にこのクレデンシャルを参照することも、重複エラーを扱うこともできません。 credential.id プロパティが設定されている場合、credentialId は発行者コーディネーターによって設定されるべきではなく、credential.id の代替として使用されるべきでもありません。むしろ、credentialId は id プロパティ（すなわち credential.id）が設定されていないクレデンシャルを識別する手段です。発行者サービスは、発行者コーディネーターから提供されない場合に credentialId を自動生成すべきではありません。そうすると、結果がクライアントに受信されなかった場合にパーティショニング・エラーを生じさせる可能性があるためです。

/credentials/issue エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答本文

201

応答	本文
201	クレデンシャルが正常に発行されました! content-type: application/json 以下の形式のオブジェクト: `IssueCredentialResponse` [object] 検証可能なクレデンシャルの正常な要求から返される形式。これは以下の形式のオブジェクトで MUST あります。 `verifiableCredential` [object] 以下の形式のオブジェクトのいずれか。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。 Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。または、エンベロープされた検証可能なクレデンシャルを検証可能な提示内の verifiableCredential プロパティに関連付けるために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] エンベロープされた検証可能なクレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] これは、エンベロープ化セキュリティ方式を使用して保護された検証可能なクレデンシャルを表す "data:" スキーム URL [RFC2397] で MUST あります。 `type` [string] これは EnvelopedVerifiableCredential で MUST あります。
400	次のいずれかの理由により、要求を処理できませんでした: - 提供された 'issuer' の値が想定される構成と一致しません。 - Bad Request となる別の条件。

クレデンシャルが正常に発行されました!

content-type: application/json

以下の形式のオブジェクト:

IssueCredentialResponse [object]

検証可能なクレデンシャルの正常な要求から返される形式。これは以下の形式のオブジェクトで MUST あります。

verifiableCredential [object]

以下の形式のオブジェクトのいずれか。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。 Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

または、エンベロープされた検証可能なクレデンシャルを検証可能な提示内の verifiableCredential プロパティに関連付けるために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。

@context [array]: エンベロープされた検証可能なクレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。
id [string]: これは、エンベロープ化セキュリティ方式を使用して保護された検証可能なクレデンシャルを表す "data:" スキーム URL [RFC2397] で MUST あります。
type [string]: これは EnvelopedVerifiableCredential で MUST あります。

400 次のいずれかの理由により、要求を処理できませんでした: - 提供された 'issuer' の値が想定される構成と一致しません。 - Bad Request となる別の条件。

ユースケースが、発行者インスタンスに対して、提供された credential に複数の証明を付加することを要求する場合、そのインスタンスは /credentials/issue エンドポイントへの 1 回の呼び出しに対する応答として、それらすべての証明を付加しなければ MUST なりません。

提供された credential がすでに 1 つ以上の証明を含んでいる場合、その挙動は発行者インスタンスの構成によって決定されます。発行インスタンスは、以下のいずれかの方法で既存の証明を処理するよう構成される SHOULD です。

証明セット: 呼び出し元によって提供された既存の証明のリストに新しい証明を追加します。必要に応じて、既存の単一証明をまずリストに変換します。ここでは既存の証明への結合はなく、新しい証明は呼び出し元が以前に提供した証明と並列に存在します。
証明チェーン: 新しい証明を追加して、既存の証明チェーンを作成または拡張します。ここでは、証明は特定の順序でリンクされ、チェーン関係を確立するために previousProof プロパティを使用する可能性があります。
エラー処理: インスタンスが既存の証明を持たないクレデンシャルのみを受け入れるよう構成されている場合に、既存の proof 値を含む credential 値が提供されるとエラーを返します。

使用される具体的なアプローチは、発行者インスタンスの構成と、検証可能なクレデンシャルの想定ユースケースに依存します。

GET /credentials/{id} - ID によってクレデンシャルまたは検証可能なクレデンシャルを取得します。 credential.id が設定されていないが、関連付けられた credentialId 値を持つクレデンシャルを取得するには、代わりに credentialId を渡します。

/credentials/{id} エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
200	クレデンシャルが取得されました content-type: application/json 検証可能なクレデンシャルの正常な要求から返される形式。これは以下の形式のオブジェクトで MUST あります。 `verifiableCredential` [object] 以下の形式のオブジェクトのいずれか。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。 Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。または、エンベロープされた検証可能なクレデンシャルを検証可能な提示内の verifiableCredential プロパティに関連付けるために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] エンベロープされた検証可能なクレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] これは、エンベロープ化セキュリティ方式を使用して保護された検証可能なクレデンシャルを表す "data:" スキーム URL [RFC2397] で MUST あります。 `type` [string] これは EnvelopedVerifiableCredential で MUST あります。
400	Bad Request
401	認可されていません
404	クレデンシャルが見つかりません
410	Gone! ここにデータはありません
418	私はティーポットです - 両当事者間で事前に取り決められたシナリオ以外では返しては MUST なりません

発行者サービスまたは保持者サービスは、発行済みの検証可能なクレデンシャルを長期間保存する場合があります。これが行われる場合、そのような検証可能なクレデンシャルを削除できることが有用な場合があります。たとえば、発行者は、忘れられる権利などの規制上の要件により、そうする必要がある場合があります。システムから検証可能なクレデンシャルを削除することに関連する追加の考慮事項については、 Section B.3 削除を参照してください。

DELETE /credentials/{id} - ID によってクレデンシャルまたは検証可能なクレデンシャルを削除します。 credential.id が設定されていないが、関連付けられた credentialId 値を持つクレデンシャルを削除するには、代わりに credentialId を渡します。

/credentials/{id} エンドポイントは、DELETE を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
202	クレデンシャルが削除されました - ソフト削除と処理時間が想定されるため、これは既定で 202 です
400	Bad Request
401	認可されていません
404	クレデンシャルが見つかりません
410	Gone! ここにデータはありません

Verifiable Credential を検証するために、以下の API が定義されています。

エンドポイント	説明
POST /credentials/verify	verifiableCredential を検証し、応答本文で verificationResult を返します。
POST /presentations/verify	Presentation と、それに含まれるすべての Verifiable Credentials を検証し、詳細な検証結果を返します。
POST /challenges	このエンドポイントに空の本文を渡すと、チャレンジ文字列を作成し、応答本文で返します。

このエンドポイントは、検証可能なクレデンシャルを検証するために使用されます。

注記: クレデンシャルを検証するメディア型

application/vc 以外のメディア型、たとえば application/mdoc、application/vc+sd-jwt、 application/vcb;barcode-format=qr_code、または application/vcb;barcode-format=pdf417 のクレデンシャルを検証するには、要求で EnvelopedVerifiableCredential を提供できます。

POST /credentials/verify - verifiableCredential を検証し、応答本文で verificationResult を返します。

/credentials/verify エンドポイントは、POST を受信する際に以下のいずれかのスキーマを使用します。

プロパティ説明

プロパティ	説明
`verifiableCredential` [object]	以下の形式のオブジェクト: `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
`options` [object]	クレデンシャルがどのように検証されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。 `returnResults` [boolean] 個々の証明、ステータス、スキーマの検証など、応答で実行された各検証ステップの結果を含めます。 `returnProblemDetails` [boolean] 応答に ProblemDetails エラーと警告を含めます。 `returnCredential` [boolean] 検証済みクレデンシャルを応答で返すべきかどうか。true の場合、検証済みクレデンシャルは検証された形式で返されるべきです。 false または未提供の場合、検証済みクレデンシャルは返されるべきではありません。

verifiableCredential [object]

以下の形式のオブジェクト:

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

options [object]

クレデンシャルがどのように検証されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。

returnResults [boolean]: 個々の証明、ステータス、スキーマの検証など、応答で実行された各検証ステップの結果を含めます。
returnProblemDetails [boolean]: 応答に ProblemDetails エラーと警告を含めます。
returnCredential [boolean]: 検証済みクレデンシャルを応答で返すべきかどうか。true の場合、検証済みクレデンシャルは検証された形式で返されるべきです。 false または未提供の場合、検証済みクレデンシャルは返されるべきではありません。

あるいは、/credentials/verify エンドポイントは以下のスキーマも使用できます。

プロパティ説明

プロパティ	説明
`verifiableCredential` [object]	エンベロープされた検証可能なクレデンシャルを、検証可能な提示内の verifiableCredential プロパティに関連付けるために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] エンベロープされた検証可能なクレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] これは、エンベロープ化セキュリティ方式を使用して保護された検証可能なクレデンシャルを表す "data:" スキーム URL [RFC2397] で MUST あります。 `type` [string] これは EnvelopedVerifiableCredential で MUST あります。
`options` [object]	クレデンシャルがどのように検証されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。 `returnResults` [boolean] 個々の証明、ステータス、スキーマの検証など、応答で実行された各検証ステップの結果を含めます。 `returnProblemDetails` [boolean] 応答に ProblemDetails エラーと警告を含めます。 `returnCredential` [boolean] 検証済みクレデンシャルを応答で返すべきかどうか。true の場合、検証済みクレデンシャルは検証された形式で返されるべきです。 false または未提供の場合、検証済みクレデンシャルは返されるべきではありません。

verifiableCredential [object]

エンベロープされた検証可能なクレデンシャルを、検証可能な提示内の verifiableCredential プロパティに関連付けるために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。

@context [array]: エンベロープされた検証可能なクレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。
id [string]: これは、エンベロープ化セキュリティ方式を使用して保護された検証可能なクレデンシャルを表す "data:" スキーム URL [RFC2397] で MUST あります。
type [string]: これは EnvelopedVerifiableCredential で MUST あります。

options [object]

クレデンシャルがどのように検証されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。

returnResults [boolean]: 個々の証明、ステータス、スキーマの検証など、応答で実行された各検証ステップの結果を含めます。
returnProblemDetails [boolean]: 応答に ProblemDetails エラーと警告を含めます。
returnCredential [boolean]: 検証済みクレデンシャルを応答で返すべきかどうか。true の場合、検証済みクレデンシャルは検証された形式で返されるべきです。 false または未提供の場合、検証済みクレデンシャルは返されるべきではありません。

/credentials/verify エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答本文

200

応答	本文
200	Verifiable Credential が正常に検証されました! content-type: application/json VerifiableCredential に対する検証プロセスの結果を報告するオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] VerifiableCredential の全体的な検証アサーション。検証プロセス中にエラーが検出されなかった場合は `true` に設定され、それ以外の場合は `false` に設定されます。エラー、警告、検証ステップに関する詳細なガイダンスについては、エラー処理の節を参照してください。 `credential` [object] オブジェクト `problemDetails` [array] ProblemDetails オブジェクトで構成される配列。 `problemDetails` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `type` [string] 問題の種類を識別する URL。 `title` [string] 問題に対する短く具体的な人間可読文字列。 `detail` [string] 問題に対するより長い人間可読文字列。 `results` [object] より詳細な出力として含められる検証結果。キーは Verifiable Credential Data Model のプロパティにマップされます。これは以下の形式のオブジェクトで MUST あります。 `validFrom` [object] VerifiableCredential に存在する場合、validFrom プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 検証結果。 `input` [string] validFrom の値。 `validUntil` [object] VerifiableCredential に存在する場合、validUntil プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 検証結果。 `input` [string] validUntil の値。 `credentialSchema` [array] credentialSchema オブジェクトがある場合、それらを検証した結果。 `credentialSchema` 配列内の各項目は、 credentialSchema オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] credentialSchema オブジェクトを検証した結果。 `input` [object] オブジェクト `credentialStatus` [array] credentialStatus オブジェクトがある場合、それらを検証した結果。 `credentialStatus` 配列内の各項目は、 credentialStatus オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `value` [integer] ステータス項目に関連付けられた特定のステータス値。 `verified` [boolean] credentialStatus オブジェクトを検証した結果。 `input` [object] オブジェクト `proof` [array] proof オブジェクトがある場合、それらを検証した結果。 `proof` 配列内の各項目は、proof オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] proof オブジェクトを検証した結果。 `input` [object] オブジェクト
400	無効な入力です!

Verifiable Credential が正常に検証されました!

content-type: application/json

VerifiableCredential に対する検証プロセスの結果を報告するオブジェクト。これは以下の形式のオブジェクトで MUST あります。

verified [boolean]

VerifiableCredential の全体的な検証アサーション。検証プロセス中にエラーが検出されなかった場合は true に設定され、それ以外の場合は false に設定されます。エラー、警告、検証ステップに関する詳細なガイダンスについては、エラー処理の節を参照してください。

credential [object]

オブジェクト

problemDetails [array]

ProblemDetails オブジェクトで構成される配列。 problemDetails 配列内の各項目は以下の形式のオブジェクトで MUST あります。

type [string]: 問題の種類を識別する URL。
title [string]: 問題に対する短く具体的な人間可読文字列。
detail [string]: 問題に対するより長い人間可読文字列。

results [object]

より詳細な出力として含められる検証結果。キーは Verifiable Credential Data Model のプロパティにマップされます。これは以下の形式のオブジェクトで MUST あります。

validFrom [object]

VerifiableCredential に存在する場合、validFrom プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。

verified [boolean]: 検証結果。
input [string]: validFrom の値。

validUntil [object]

VerifiableCredential に存在する場合、validUntil プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。

verified [boolean]: 検証結果。
input [string]: validUntil の値。

credentialSchema [array]

credentialSchema オブジェクトがある場合、それらを検証した結果。 credentialSchema 配列内の各項目は、 credentialSchema オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。

verified [boolean]: credentialSchema オブジェクトを検証した結果。
input [object]: オブジェクト

credentialStatus [array]

credentialStatus オブジェクトがある場合、それらを検証した結果。 credentialStatus 配列内の各項目は、 credentialStatus オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。

value [integer]: ステータス項目に関連付けられた特定のステータス値。
verified [boolean]: credentialStatus オブジェクトを検証した結果。
input [object]: オブジェクト

proof [array]

proof オブジェクトがある場合、それらを検証した結果。 proof 配列内の各項目は、proof オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。

verified [boolean]: proof オブジェクトを検証した結果。
input [object]: オブジェクト

400 無効な入力です!

このエンドポイントは、検証可能な提示と、既定ではその中に含まれるすべての検証可能なクレデンシャルを検証するために使用されます。

検証プロセスには以下が含まれます。

提示自体の証明の検証（domain と challenge の検証を含む）
含まれる各検証可能なクレデンシャルの証明、ステータス、および有効期間の検証
提示内の holder が、提示の証明で使用された検証メソッドと一致することの確認

ビジネスルールの検証（クレデンシャル主体が提示保持者と一致することの検証、または誰がどのクレデンシャルを提示できるかに関する認可ポリシーなど）は、この検証エンドポイントの範囲外であり、呼び出し元アプリケーションによって実行されるべきです。

POST /presentations/verify - Presentation と、それに含まれるすべての Verifiable Credentials を検証し、詳細な検証結果を返します。

/presentations/verify エンドポイントは、POST を受信する際に以下のいずれかのスキーマを使用します。

プロパティ説明

プロパティ	説明
`verifiablePresentation` [object]	以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は、以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
`options` [object]	提示がどのように検証されるかを指定するためのオプション。実装は、検証動作を制御するために追加のプロパティでこのオブジェクトを MAY 拡張できます。一般的な拡張には、含まれるクレデンシャルの検証を無効にするオプション（たとえばデバッグ用、または提示レベルの検証のみが必要な場合）、ステータス確認、有効期間検証、証明検証、スキーマ検証などのクレデンシャル側面の検証に対する細かな制御、および提示内の特定のクレデンシャルに対する選択的な検証制御が含まれる場合があります。クレデンシャル検証が無効化または制限される場合、この API は合成可能です。個々のクレデンシャルは /credentials/verify エンドポイントを使用して個別に検証できます。これは以下の形式のオブジェクトで MUST あります。 `challenge` [string] 証明の要求当事者によって提供されるチャレンジ。たとえば、 `6e62f66e-67de-11eb-b490-ef3eeefa55f2`。 `domain` [string] 証明の意図された有効ドメイン。たとえば、 `website.example`。 `returnPresentation` [boolean] 検証済み提示を返すかどうか。true の場合、検証済み提示は MUST 返されます。false または未提供の場合、検証済み提示は MUST NOT 返されません。

verifiablePresentation [object]

以下の形式のオブジェクト:

@context [array]

提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

提示の ID。

type [array]

提示の JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

holder [object]

オブジェクト

verifiableCredential [array]

Verifiable Credentials。verifiableCredential 配列内の各項目は、以下の形式のオブジェクトで MUST あります。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

proof [object]

W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
challenge [string]: 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。
domain [string]: 証明の使用を特定の対象に制限するための証明のドメイン。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

options [object]

提示がどのように検証されるかを指定するためのオプション。実装は、検証動作を制御するために追加のプロパティでこのオブジェクトを MAY 拡張できます。一般的な拡張には、含まれるクレデンシャルの検証を無効にするオプション（たとえばデバッグ用、または提示レベルの検証のみが必要な場合）、ステータス確認、有効期間検証、証明検証、スキーマ検証などのクレデンシャル側面の検証に対する細かな制御、および提示内の特定のクレデンシャルに対する選択的な検証制御が含まれる場合があります。クレデンシャル検証が無効化または制限される場合、この API は合成可能です。個々のクレデンシャルは /credentials/verify エンドポイントを使用して個別に検証できます。これは以下の形式のオブジェクトで MUST あります。

challenge [string]: 証明の要求当事者によって提供されるチャレンジ。たとえば、 6e62f66e-67de-11eb-b490-ef3eeefa55f2。
domain [string]: 証明の意図された有効ドメイン。たとえば、 website.example。
returnPresentation [boolean]: 検証済み提示を返すかどうか。true の場合、検証済み提示は MUST 返されます。false または未提供の場合、検証済み提示は MUST NOT 返されません。

あるいは、/presentations/verify エンドポイントは以下のスキーマも使用できます。

プロパティ説明

プロパティ	説明
`presentation` [object]	証明を持たない JSON-LD Verifiable Presentation。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は、以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。

presentation [object]

証明を持たない JSON-LD Verifiable Presentation。これは以下の形式のオブジェクトで MUST あります。

@context [array]

提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

提示の ID。

type [array]

提示の JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

holder [object]

オブジェクト

verifiableCredential [array]

Verifiable Credentials。verifiableCredential 配列内の各項目は、以下の形式のオブジェクトで MUST あります。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

プロパティ説明

プロパティ	説明
`verifiablePresentation` [object]	エンベロープされた検証可能な提示を表現するために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] エンベロープされた検証可能な提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] これは、エンベロープ化セキュリティ方式を使用して保護された検証可能な提示を表す "data:" スキーム URL [RFC2397] で MUST あります。 `type` [string] これは EnvelopedVerifiablePresentation で MUST あります。
`options` [object]	提示がどのように検証されるかを指定するためのオプション。実装は、検証動作を制御するために追加のプロパティでこのオブジェクトを MAY 拡張できます。一般的な拡張には、含まれるクレデンシャルの検証を無効にするオプション（たとえばデバッグ用、または提示レベルの検証のみが必要な場合）、ステータス確認、有効期間検証、証明検証、スキーマ検証などのクレデンシャル側面の検証に対する細かな制御、および提示内の特定のクレデンシャルに対する選択的な検証制御が含まれる場合があります。クレデンシャル検証が無効化または制限される場合、この API は合成可能です。個々のクレデンシャルは /credentials/verify エンドポイントを使用して個別に検証できます。これは以下の形式のオブジェクトで MUST あります。 `challenge` [string] 証明の要求当事者によって提供されるチャレンジ。たとえば、 `6e62f66e-67de-11eb-b490-ef3eeefa55f2`。 `domain` [string] 証明の意図された有効ドメイン。たとえば、 `website.example`。 `returnPresentation` [boolean] 検証済み提示を返すかどうか。true の場合、検証済み提示は MUST 返されます。false または未提供の場合、検証済み提示は MUST NOT 返されません。

verifiablePresentation [object]

エンベロープされた検証可能な提示を表現するために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。

@context [array]: エンベロープされた検証可能な提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。
id [string]: これは、エンベロープ化セキュリティ方式を使用して保護された検証可能な提示を表す "data:" スキーム URL [RFC2397] で MUST あります。
type [string]: これは EnvelopedVerifiablePresentation で MUST あります。

options [object]

challenge [string]: 証明の要求当事者によって提供されるチャレンジ。たとえば、 6e62f66e-67de-11eb-b490-ef3eeefa55f2。
domain [string]: 証明の意図された有効ドメイン。たとえば、 website.example。
returnPresentation [boolean]: 検証済み提示を返すかどうか。true の場合、検証済み提示は MUST 返されます。false または未提供の場合、検証済み提示は MUST NOT 返されません。

/presentations/verify エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
200	検証プロセスが正常に完了しました。応答本文には、提示とそれに含まれるクレデンシャルが検証に合格したか失敗したかを示す詳細な結果が含まれます。 <code>200</code> ステータスは、提示および／またはクレデンシャルが有効または無効と判定されたかどうかに関係なく、検証プロセス自体が成功したことを示します。 content-type: application/json VerifiablePresentation に対する検証プロセスの結果を報告するオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] VerifiablePresentation の全体的な検証アサーション。 VerifiablePresentation と、確認されたすべての VerifiableCredentials が検証に合格した場合は `true` に設定され、それ以外の場合は `false` に設定されます。エラーと警告、および検証と妥当性確認のステップに関する詳細なガイダンスについては、エラー処理の節を参照してください。 `verifiablePresentation` [object] オブジェクト `problemDetails` [array] 提示レベル全体の問題に対する ProblemDetails オブジェクトで構成される配列。 `problemDetails` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `type` [string] 問題の種類を識別する URL。 `title` [string] 問題に対する短く具体的な人間可読文字列。 `detail` [string] 問題に対するより長い人間可読文字列。 `results` [object] 既定では、VerifiablePresentation と、その中に含まれるすべての VerifiableCredentials の両方に対する詳細な検証結果。キーは、妥当性確認の対象となる Verifiable Credential Data Model のプロパティにマップされます。これは以下の形式のオブジェクトで MUST あります。 `presentation` [object] VerifiablePresentation 自体（その中に含まれる VerifiableCredentials ではない）に固有の検証結果。これは以下の形式のオブジェクトで MUST あります。 `challenge` [object] 検証オプションで提供されている場合、提供されたすべての証明にわたってセキュリティ・チャレンジを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 提供されたすべての証明にわたってセキュリティ・チャレンジを検証した結果。 `input` [string] チャレンジ入力文字列。 `domain` [object] 検証オプションで提供されている場合、提供されたすべての証明にわたってセキュリティ・ドメインを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 提供されたすべての証明にわたってセキュリティ・ドメインを検証した結果。 `input` [string] セキュリティ・ドメイン入力文字列。 `holder` [object] holder がある場合、それを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] holder を検証した結果。 `input` [string] holder 入力文字列。 `proof` [array] proof オブジェクトがある場合、それらを検証した結果。 `proof` 配列内の各項目は、proof オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] proof オブジェクトを検証した結果。 `input` [object] オブジェクト `problemDetails` [array] この証明に固有の問題。 `problemDetails` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `type` [string] 問題の種類を識別する URL。 `title` [string] 問題に対する短く具体的な人間可読文字列。 `detail` [string] 問題に対するより長い人間可読文字列。 `credentials` [array] VerifiablePresentation 内の各 VerifiableCredential に対する詳細な検証結果。`credentials` 配列内の各項目は、 VerifiableCredential に対する検証プロセスの結果を報告するオブジェクトで MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] VerifiableCredential の全体的な検証アサーション。検証プロセス中にエラーが検出されなかった場合は `true` に設定され、それ以外の場合は `false` に設定されます。エラー、警告、検証ステップに関する詳細なガイダンスについては、エラー処理の節を参照してください。 `credential` [object] オブジェクト `problemDetails` [array] ProblemDetails オブジェクトで構成される配列。 `problemDetails` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `type` [string] 問題の種類を識別する URL。 `title` [string] 問題に対する短く具体的な人間可読文字列。 `detail` [string] 問題に対するより長い人間可読文字列。 `results` [object] より詳細な出力として含められる検証結果。キーは Verifiable Credential Data Model のプロパティにマップされます。これは以下の形式のオブジェクトで MUST あります。 `validFrom` [object] VerifiableCredential に存在する場合、 validFrom プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 検証結果。 `input` [string] validFrom の値。 `validUntil` [object] VerifiableCredential に存在する場合、 validUntil プロパティを検証した結果。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] 検証結果。 `input` [string] validUntil の値。 `credentialSchema` [array] credentialSchema オブジェクトがある場合、それらを検証した結果。`credentialSchema` 配列内の各項目は、credentialSchema オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] credentialSchema オブジェクトを検証した結果。 `input` [object] オブジェクト `credentialStatus` [array] credentialStatus オブジェクトがある場合、それらを検証した結果。`credentialStatus` 配列内の各項目は、credentialStatus オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `value` [integer] ステータス項目に関連付けられた特定のステータス値。 `verified` [boolean] credentialStatus オブジェクトを検証した結果。 `input` [object] オブジェクト `proof` [array] proof オブジェクトがある場合、それらを検証した結果。 `proof` 配列内の各項目は、 proof オブジェクトを検証した結果で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `verified` [boolean] proof オブジェクトを検証した結果。 `input` [object] オブジェクト
400	検証プロセスの実行を妨げた、無効または不正な形式の入力。これは、検証失敗ではなく、要求の形式、構造、またはパラメーターに関する問題を示します。
413	ペイロードが大きすぎます
429	要求レート制限を超過しました。

POST /challenges - このエンドポイントに空の本文を渡すと、チャレンジ文字列を作成し、応答本文で返します。

/challenges エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
200	チャレンジが作成されました content-type: application/json challenge を含むオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `challenge` [string] チャレンジ値
400	無効または不正な形式の入力

インスタンスは、検証中に使用するためのチャレンジを作成し、そのチャレンジが options.challenge として検証エンドポイントに渡された回数を追跡すべきです。

検証可能なクレデンシャルおよび分散型識別子ベースの認証を扱う場合、ある当事者が別の当事者からデータを要求する必要がしばしばあります。この節では、それらの要求の一般的な形式について説明し、具体的な検証可能な提示要求形式も提供します。

検証可能な提示要求とは、検証者が保持者に対して提示を求める要求です。1 つ以上のクレデンシャルを検証可能な提示で包んだものを要求するために、検証者は、保持者から受け取りたい 1 つ以上のクレデンシャルを記述する JSON 要求を構築します。要求の一般的な形式は次のようになります。

例 1: 検証可能な提示要求の一般形式

{
  // one or more requests for verifiable credentials
  "query": [{
    "type": "QueryByExample",
    // query details specific to QueryByExample...
  }],
  // The target security domain, such as a website domain, to include in
  // the verifiable presentation
  "domain": "domain.example",

  // The random challenge string to include in the verifiable presentation
  "challenge": "f63cb0d2-760e-11f0-a2b1-67febb854a5f"
}

query プロパティは、提示内のデータに対する要求のための主要な拡張ポイント・メカニズムとして機能します。この文書は共通のクエリ・メカニズム（Section 3.4.2 例によるクエリを参照）を定義しますが、すべての query オブジェクトは以下の形式です。

query: 検証者によって要求される情報を指定する REQUIRED プロパティ。値は 1 つ以上のマップで MUST あり、各マップは、関連付けられた文字列値を持つ type プロパティを MUST 定義します。
domain: 検証者が保持者に対して提示要求中に提供する OPTIONAL な文字列。保持者は、そのデータが、やり取りしている Web サイトのドメインなどのドメインに関連付けられていることを確認し、関連付けられている場合は、そのデータを検証可能な提示に含めます。domain は、保持者が検証可能な提示を特定の検証者に限定することを保証し、検証者をリプレイ攻撃から保護するために使用されます。
challenge: 特定の提示要求中に、検証者から保持者に提供される、OPTIONAL で一意の文字列。保持者は、このデータを検証可能な提示に含めて検証者に渡し、検証者をリプレイ攻撃から保護します。

"query by example" クレデンシャル・クエリ形式は、特定のビジネスプロセスを可能にするために、開発者が 1 つ以上の検証可能なクレデンシャルから必要な主張を容易に要求できるように設計されています。このクエリでは、検証者が信頼する 1 つ以上の発行者など、その他の情報も指定できます。

QueryByExample クエリ内の credentialQuery プロパティは単一のオブジェクトです。複数のクエリを組み合わせるための論理 "AND" および "OR" 操作は、 Section 3.4.5 クエリ内の論理演算で説明されているように、クエリレベルの group プロパティを通じて処理されます。同じ group 値を持つ複数のクエリは "AND" 操作として処理され、異なる、または欠落している group 値を持つクエリは "OR" 操作として処理されます。

例 2: Query By Example クエリ

{
  "query": [{
    "type": "QueryByExample",
    "credentialQuery": {
      // (Optional) Reason for requesting this credential that
      // may be shown to a user by their software
      "reason": "We need to know if you are an alumni of this school.",
      // (Optional) An example of the credential being requested
      "example": {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://www.w3.org/ns/credentials/examples/v2"
        ],
        "type": "ExampleAlumniCredential",
        // (Optional) Select credential based on credential subject type
        "credentialSubject": {
          "type": "Alumni"
        }
      },
      // (Optional) Specify credentials from particular acceptedIssuers or
      // delegates of the authority
      "acceptedIssuers": [{
        "issuer": "did:web:authority.example"
      }]
    }
  }],
  "challenge": "3182bdea-63d9-11ea-b6de-3b7c1404d57f",
  "domain": "reunion.example"
}

credentialQuery オブジェクトは、以下のプロパティをサポートします。

プロパティ	説明
reason	クレデンシャルが要求されている理由について、人間可読な説明を提供する OPTIONAL な文字列。これは、保持者に対して、そのソフトウェアによって MAY 表示されます。
example	要求されているクレデンシャルの例を提供する OPTIONAL なオブジェクト。必要な主張を示すために、その `@context`、`type`、および任意で `credentialSubject` フィールドを含みます。
acceptedIssuers	検証者が、検証可能なクレデンシャルの発行者として認識し受け入れるエンティティを識別する、項目または項目を含むリストの OPTIONAL な配列。各項目は、1) 受信した検証可能なクレデンシャルの `issuer` プロパティ内の発行者を識別する [URL]、または 2) 受信した検証可能なクレデンシャルの `issuer` プロパティ内の発行者を識別する [URL] を値とする `id` プロパティを含むオブジェクト、または 3) `type` プロパティが `RecognizedEntityCredential` に設定され、`id` プロパティが Recognized Entities v1.0 仕様で定義されるそのようなクレデンシャルを指す [URL] 値を持つオブジェクトに関連付けられた `recognizedIn` プロパティを含むオブジェクトで MUST あります。このリストには、検証者が受け入れ可能とする認識済み発行者が含まれます。有効な例の値には以下が含まれます。 `did:web:red-issuer.example` `https://blue-issuer.example/` `{"id": "did:web:green-issuer.example"}` `{"recognizedIn": {"id": "https://url.example/list.vc", "type": "RecognizedEntityCredential"}}`
acceptedCryptosuites	検証者がどの暗号証明スイートを受け入れるかを指定する OPTIONAL な配列。各要素は、Data Integrity 暗号スイート名、またはレガシー用の `Ed25519Signature2020` を参照する `cryptosuite` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用され、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、エンベロープされたクレデンシャルにのみ適用される `acceptedEnvelopes` とは独立して MAY 使用できます。有効な例の値には以下が含まれます。 `[{"cryptosuite": "eddsa-rdfc-2022"}, {"cryptosuite": "ecdsa-rdfc-2019"}]` `[{"cryptosuite": "bbs-2023"}, {"cryptosuite": "ecdsa-sd-2023"}]`
acceptedEnvelopes	検証者がどのエンベロープ形式を受け入れるかを指定する OPTIONAL な配列。各要素は、エンベロープ用のメディア型を参照する `mediaType` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用され、メディア型として解釈されます）。これにより、保持者は、既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される `acceptedCryptosuites` とは独立して MAY 使用できます。有効な例の値には以下が含まれます。 `[{"mediaType": "application/jwt"}]` `[{"mediaType": "application/vc+sd-jwt"}]`

QueryByExample の JSON Schema は、ソフトウェア・システムへの統合用に別ファイルで提供されています。

以下の例は、受け入れ可能な暗号スイートとエンベロープ形式を指定する QueryByExample を示し、保持者が適切な証明メカニズムを選択できるようにします。

例 3: 受け入れ可能な暗号スイートとエンベロープを持つ Query By Example

{
  "query": [{
    "type": "QueryByExample",
    "credentialQuery": {
      "reason": "Please present your PermanentResidentCard to complete the verification process.",
      "example": {
        "@context": [
          "https://www.w3.org/ns/credentials/v2",
          "https://w3id.org/citizenship/v3"
        ],
        "type": ["PermanentResidentCard"],
        "credentialSubject": {
          "birthCountry": ""
        }
      },
      "acceptedCryptosuites": [
        {"cryptosuite": "eddsa-rdfc-2022"},
        {"cryptosuite": "ecdsa-rdfc-2019"},
        {"cryptosuite": "bbs-2023"},
        {"cryptosuite": "ecdsa-sd-2023"}
      ],
      "acceptedEnvelopes": [
        {"mediaType": "application/jwt"},
        {"mediaType": "application/vc+sd-jwt"}
      ]
    }
  }],
  "challenge": "9876fedc-ba98-7654-3210-fedcba987654",
  "domain": "immigration.example"
}

上記の例では、検証者は、一覧表示された暗号スイートのいずれかで保護されたクレデンシャルを受け入れることを示しています。 bbs-2023 と ecdsa-sd-2023 を含めることで、検証者は選択的開示証明が受け入れ可能であることを示し、保持者がクレデンシャル全体ではなく birthCountry フィールドのみを開示できるようにします。 acceptedEnvelopes プロパティは、JWT ベースのエンベロープ形式も受け入れ可能であることを示します。

注記: Query By Example を使用した選択的開示

Query By Example に含まれる任意のフィールドは必須フィールドです。つまり、選択的開示を可能にするために Query By Example を使用する場合、要求者は、そのユースケースに不要なフィールドをクエリに含めないよう注意する必要があります。Query By Example には「任意」のフィールドを示す方法はありません。したがって、要求されているものを超える情報を応答が明らかにしないようにすることは、クエリに応答するウォレット次第です。注記: 検証可能なクレデンシャルの一部の保護メカニズムは選択的開示を許可しません。このような場合、要求された情報を送信するために、要求されていない情報も送信しなければならないことがあります。デジタル・ウォレットは、どの情報が共有されるかをユーザーに通知することが期待されています。期待される値について何も述べずにフィールドを要求するには、要求者は要求内にそのフィールドを含め、値を空文字列のままにできます。たとえば、要求者が名を必要とする場合、任意の "credentialSubject" オブジェクトに単一のフィールド "firstName": "" を含めることができます。これにより、ウォレットは、他のフィールドを含める期待なしに、要求されたクレデンシャルの firstName のみで応答できます。_これは、ウォレットがクエリへの応答に追加フィールドを含めて過剰共有することを防ぐものではありません。_ 選択的開示暗号スイートが受け入れ可能であることを示すために、検証者は、 acceptedCryptosuites 配列に bbs-2023 または ecdsa-sd-2023 などの暗号スイートを含める SHOULD です。

この節では、検証者が、保持者に対して Decentralized Identifier ベースの認証 [DID-CORE] の実行を要求する方法を定義します。最も単純な形式では、認証プロトコルは検証者によるチャレンジと、保持者による応答で構成されます。

例 4: DID 認証要求

{
  "query": [{
    "type": "DIDAuthentication",
    "acceptedMethods": [{"method": "example"}]
  }],
  "challenge": "99612b24-63d9-11ea-b99f-4f66f3e4f81a",
  "domain": "example.com"
}

上記の DID Authentication 要求は、検証者が、提供されたチャレンジに対するデジタル署名を生成することで、保持者に DID に対する制御を証明してほしいことを指定します。保持者は次の応答を提供して応答する場合があります。

例 5: DID 認証応答

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": "VerifiablePresentation",
  "holder": "did:example:12345",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verificationMethod": "did:example:12345#key-1",
    "challenge": "99612b24-63d9-11ea-b99f-4f66f3e4f81a",
    "domain": "example.com",
    "created": "2024-02-25T14:58:42Z",
    "proofPurpose": "authentication",
    "proofValue": "z3FXQjecWufY46...UAUL5n2Brbx"
  }
}

DID Authentication クエリ形式は、検証者が、保持者に特定の方法で認証するよう要求できるようにします。DID Authentication クエリは、以下の形式で MUST あります。

プロパティ	説明
type	`DIDAuthentication` に設定されて MUST いる REQUIRED な文字列値。
acceptedMethods	検証者が、一覧にある任意の DID Method を受け入れることを表すオブジェクトの任意の配列。配列内の各オブジェクトは、 DID Method 名を値とする `method` というプロパティを MUST 含み、DID Method に固有のその他のプロパティを MAY 含みます。有効な例の値には以下が含まれます。 `[{"method": "key"}]` `[{"method": "key"}, {"method": "web"}]`
acceptedCryptosuites	この検証者に提出される暗号証明を生成する際に、保持者がその中から MUST 選択する暗号スイートを伝える任意のオブジェクト配列。配列内の各オブジェクトは、Data Integrity 暗号スイート名（またはレガシー用の `Ed25519Signature2020`）を値とする `cryptosuite` というプロパティを MUST 含み、暗号スイートに固有のその他のプロパティを MAY 含みます。有効な例の値には以下が含まれます。 `[{"cryptosuite": "eddsa-rdfc-2022"}]` `[{"cryptosuite": "ecdsa-rdfc-2019"}, {"cryptosuite": "bbs-2023"}]`

以下の例は、検証者が、 Credential Handler API (CHAPI) などの確立済み通信チャネル上で認証するために、保持者に DID Web メソッドと Data Integrity ECDSA 暗号スイートを使用してほしいことを示します。

例 6: did:web と ecdsa-rdfc-2019 を使用する DID 認証要求

{
  "query": [{
    "type": "DIDAuthentication",
    "acceptedMethods": [{"method": "key"}],
    "acceptedCryptosuites": [{"cryptosuite": "ecdsa-rdfc-2019"}]
  }],
  "challenge": "99612b24-63d9-11ea-b99f-4f66f3e4f81a",
  "domain": "example.com"
}

次の例では、検証者は、保持者に、 DID Key または DID Web メソッドのいずれかを、標準の EdDSA Data Integrity 暗号スイートとともに使用してほしいこと、任意で Data Integrity BBS 証明を実行できることを示す暗号証明を含めること、そして別の通信チャネル、この場合は Verifiable Credential API HTTP エンドポイントを使用して認証してほしいことを示しています。

例 7: 複雑な DID 認証要求

{
  "query": [{
    "type": "DIDAuthentication",
    "acceptedMethods": [{"method": "key"}, {"method": "web"}],
    "acceptedCryptosuites": [{"cryptosuite": "ecdsa-rdfc-2019"}]
  }, {
    "type": "DIDAuthentication",
    "required": false,
    "acceptedMethods": [{"method": "key"}, {"method": "web"}],
    "acceptedCryptosuites": [{"cryptosuite": "bbs-2023"}]
  }],
  "challenge": "zLEwtBYgQVNR4tyeo",
  "domain": "didauth.example"
}

DID Authentication 応答形式は、保持者が検証者によって要求された情報を提供できるようにします。DID Authentication 応答は、以下の形式の検証可能な提示で MUST あります。

プロパティ	説明
type	`VerifiablePresentation` に設定されて MUST いる REQUIRED な文字列値。
holder	DID Authentication クエリで要求された型の特定の DID に設定されて MUST いる REQUIRED な文字列値。
proof	DID Authentication クエリで要求された 1 つ以上の特定のデジタル証明型で MUST ある REQUIRED な値。各 proof オブジェクトは、DID Authentication クエリで提供された `domain` 値と `challenge` 値を MUST 含みます。保持者実装は、検証者によって指定された `domain` が、現在の通信チャネルで使用されるドメインと一致することを MUST 保証します。

保持者実装が、 verifier によって提供された domain を現在の通信チャネルで使用されるドメインと照合することは極めて重要です。保持者がこれを行わない場合、不正な検証者は、そのメッセージを自分のものではないドメインにリプレイできるようになります。たとえば、evil.example ドメインから動作する不正な検証者が、あなたの銀行からチャレンジを取得し、yourbank.example の domain 値を指定し、その後あなたの応答を銀行にリプレイして、あなたの金融口座へのアクセスを取得する可能性があります。実装が検証可能な提示を生成する際に適切なドメインが使用されることを保証する限り、この攻撃は軽減されます。

以下の例は、単純な DID Authentication 応答を示します。

例 8: did:key を使用する DID 認証応答

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": "VerifiablePresentation",
  "holder": "did:example:12345",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verificationMethod": "did:example:12345#key-1",
    "challenge": "99612b24-63d9-11ea-b99f-4f66f3e4f81a",
    "domain": "example.com",
    "created": "2024-02-25T14:58:42Z",
    "proofPurpose": "authentication",
    "proofValue": "z3FXQjecWufY46...UAUL5n2Brbx"
  }
}

課題 2

Authorization Capability のクエリと応答は、現時点では標準化されない可能性があります。この例は、検証可能なクレデンシャルおよび mDL/mdoc だけが照会可能なクレデンシャルの種類ではないことを示すために提供されています。

このクエリ型は、Verifiable Presentation 内で Authorization Capabilities または "zcaps" を求める要求に含まれます。

例 9: Authorization Capability Request クエリ

{
  "query": [{
    "type": "AuthorizationCapabilityQuery",
    "capabilityQuery": [{
      "referenceId": "a-memorable-name",
      "allowedAction": ["read", "write"],
      "controller": "did:example:1234",
      "invocationTarget": {
        "type": "urn:edv:documents"
      }
    }, {
      "referenceId": "another-memorable-name",
      "allowedAction": "sign",
      "controller": "did:example:1234",
      "invocationTarget": {
        "type": "Multikey",
        "proofPurpose": "assertionMethod"
      }
    }],
    challenge: "111112b24-63d9-11ea-b99f-4f66f3e4f81a"
  }]
}

Verifiable Presentation Requests では、情報の構造化と取得は論理演算の使用に依存します。 "AND" および "OR" 演算は、目的のデータへの経路を定義する上で重要な役割を果たします。

要求構造の最上位レベルでは、各クエリの group プロパティが同じ値に設定されている場合、異なる種類のクエリは "AND" 演算として処理されることが期待されます。

この例では、group フラグが certification に設定された 2 つのクエリがあります。これは "AND" 演算となり、要求を満たすにはこれら両方の条件を満たす必要があることを示します。

例 10: トップレベル・クエリを使用して複数のクレデンシャルを一度に要求する

{
  "query": [{
    "type": "QueryByExample",
    "group": "certification",
    // query details ...
  },
  // "AND"
  {
    "type": "DigitalCredentialQueryLanguage",
    "group": "certification",
    // query details ...
  }]
}

特定のクエリ型内では、group を指定しないか、互いに異なる group 値を指定することで、"OR" 演算を適用できます。

例 11: いずれかが一致すれば成功する代替クレデンシャルのクエリ

{
  "query": [{
    "type": "QueryByExample",
    "group": "college-degree",
    // query details ...
  },
  // "OR"
  {
    "type": "DigitalCredentialQueryLanguage",
    "group": "job-experience",
    // query details ...
  }]
}

Verifiable Credential を提示するために、以下の API が定義されています。

エンドポイント	説明
POST /credentials/derive	クレデンシャルを導出し、それを応答本文で返します。
GET /presentations	提示または検証可能な提示の一覧を取得します
POST /presentations	提示を作成し、それを応答本文で返します。
GET /presentations	提示または検証可能な提示の一覧を取得します
POST /presentations	提示を作成し、それを応答本文で返します。
GET /presentations/{id}	ID によって提示または検証可能な提示を取得します
DELETE /presentations/{id}	ID によって提示または検証可能な提示を削除します
POST /exchanges/	エラー: API エンドポイントが定義されていません - /exchanges/
POST /exchanges/{exchangeId}	エラー: API エンドポイントが定義されていません - /exchanges/{exchangeId}

URL パス値 exchange-id はサーバーにとって意味を持ちますが、クライアントにとっては不透明です。一部のサーバー実装がたまたま人間可読な値を使用する場合があっても、クライアントは人間可読な値に意味を割り当てないよう強く推奨されます。

POST /credentials/derive - クレデンシャルを導出し、それを応答本文で返します。

/credentials/derive エンドポイントは、POST を受信する際に以下のスキーマを使用します。

プロパティ説明

プロパティ	説明
`verifiableCredential` [object]	以下の形式のオブジェクト: `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
`options` [object]	導出されたクレデンシャルがどのように作成されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。 `selectivePointers` [array] 選択的に開示される情報を指定する JSON ポインターの配列。 `selectivePointers` 配列内の各項目は文字列で MUST あります。

verifiableCredential [object]

以下の形式のオブジェクト:

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

options [object]

導出されたクレデンシャルがどのように作成されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。

selectivePointers [array]: 選択的に開示される情報を指定する JSON ポインターの配列。 selectivePointers 配列内の各項目は文字列で MUST あります。

/credentials/derive エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答本文

201

応答	本文
201	クレデンシャルが正常に導出されました。 content-type: application/json 以下の形式のオブジェクト: `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
400	無効な要求

クレデンシャルが正常に導出されました。

content-type: application/json

以下の形式のオブジェクト:

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

400 無効な要求

注記: 提示のメディア型

application/vp 以外のメディア型、たとえば application/vp+jwt で提示を作成するために、応答で EnvelopedVerifiablePresentation を返すことができます。

POST /presentations - 提示を作成し、それを応答本文で返します。

/presentations エンドポイントは、POST を受信する際に以下のスキーマを使用します。

プロパティ説明

プロパティ	説明
`presentation` [object]	証明を持たない JSON-LD Verifiable Presentation。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は、以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
`options` [object]	DataIntegrityProof がどのように作成されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。 `type` [string] 証明の型。既定値は 'DataIntegrityProof'。 `cryptosuite` [string] 証明の暗号スイート。 `verificationMethod` [string] 証明に使用される verificationMethod の URI。省略された場合、既定の検証メソッドが使用されます。 `proofPurpose` [string] 証明の目的。既定値は 'assertionMethod'。 `created` [string] 証明の日付と時刻（最大精度は秒）。既定値は現在のシステム時刻。 `challenge` [string] 証明の要求当事者によって提供されるチャレンジ。例: 6e62f66e-67de-11eb-b490-ef3eeefa55f2 `domain` [string] 証明の意図された有効ドメイン。例: website.example

presentation [object]

証明を持たない JSON-LD Verifiable Presentation。これは以下の形式のオブジェクトで MUST あります。

@context [array]

提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

提示の ID。

type [array]

提示の JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

holder [object]

オブジェクト

verifiableCredential [array]

Verifiable Credentials。verifiableCredential 配列内の各項目は、以下の形式のオブジェクトで MUST あります。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

options [object]

DataIntegrityProof がどのように作成されるかを指定するためのオプション。これは以下の形式のオブジェクトで MUST あります。

type [string]: 証明の型。既定値は 'DataIntegrityProof'。
cryptosuite [string]: 証明の暗号スイート。
verificationMethod [string]: 証明に使用される verificationMethod の URI。省略された場合、既定の検証メソッドが使用されます。
proofPurpose [string]: 証明の目的。既定値は 'assertionMethod'。
created [string]: 証明の日付と時刻（最大精度は秒）。既定値は現在のシステム時刻。
challenge [string]: 証明の要求当事者によって提供されるチャレンジ。例: 6e62f66e-67de-11eb-b490-ef3eeefa55f2
domain [string]: 証明の意図された有効ドメイン。例: website.example

/presentations エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答本文

201

応答	本文
201	提示が正常に作成されました! content-type: application/json 以下の形式のオブジェクト: `verifiablePresentation` [object] 以下の形式のオブジェクトのいずれか。 `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。または、エンベロープされた検証可能な提示を表現するために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] エンベロープされた検証可能な提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] これは、エンベロープ化セキュリティ方式を使用して保護された検証可能な提示を表す "data:" スキーム URL [RFC2397] で MUST あります。 `type` [string] これは EnvelopedVerifiablePresentation で MUST あります。
400	無効な入力です!

提示が正常に作成されました!

content-type: application/json

以下の形式のオブジェクト:

verifiablePresentation [object]

以下の形式のオブジェクトのいずれか。

@context [array]

提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

提示の ID。

type [array]

提示の JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

holder [object]

オブジェクト

verifiableCredential [array]

Verifiable Credentials。verifiableCredential 配列内の各項目は以下の形式のオブジェクトで MUST あります。

@context [array]

クレデンシャルの JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか。

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

proof [object]

W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
challenge [string]: 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。
domain [string]: 証明の使用を特定の対象に制限するための証明のドメイン。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

または、エンベロープされた検証可能な提示を表現するために使用されるオブジェクト。これは以下の形式のオブジェクトで MUST あります。

@context [array]: エンベロープされた検証可能な提示の JSON-LD コンテキスト。 @context 配列内の各項目は文字列で MUST あります。
id [string]: これは、エンベロープ化セキュリティ方式を使用して保護された検証可能な提示を表す "data:" スキーム URL [RFC2397] で MUST あります。
type [string]: これは EnvelopedVerifiablePresentation で MUST あります。

400 無効な入力です!

GET /presentations - 提示または検証可能な提示の一覧を取得します

/presentations エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
200	提示が取得されました content-type: application/json 配列内の各項目は、証明を持たない JSON-LD Verifiable Presentation で MUST あります。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。または以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
400	Bad Request
401	認可されていません
410	Gone! ここにデータはありません

GET /presentations/{id} - ID によって提示または検証可能な提示を取得します

/presentations/{id} エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
200	クレデンシャルが取得されました content-type: application/json 証明を持たない JSON-LD Verifiable Presentation。これは以下の形式のオブジェクトで MUST あります。 `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。または以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
400	Bad Request
401	認可されていません
404	提示が見つかりません
410	Gone! ここにデータはありません

DELETE /presentations/{id} - ID によって提示または検証可能な提示を削除します

/presentations/{id} エンドポイントは、DELETE を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
202	提示が削除されました - ソフト削除と処理時間が想定されるため、これは既定で 202 です
400	Bad Request
401	認可されていません
404	提示が見つかりません
410	Gone! ここにデータはありません

ワークフローは、信頼境界をまたいで二者間で検証可能なクレデンシャルを交換するための、特定の一連のステップを定義します。各ステップには、検証可能なクレデンシャルの発行、検証、送信、および／または提示が関与する可能性があります。ワークフローは、線形なステップ列と、分岐ロジックや反復ステップを含むより複雑なパターンの両方をサポートするよう設計されており、関係する当事者間の高度なインタラクションを可能にします。 VC API ワークフローの例には、以下が含まれますが、これらに限定されません。

コーディネーター Web サイトにログインした従業員に、従業員メンバーシップ・クレデンシャルを発行する。
運転免許証クレデンシャルの提示を受け取った後、車両所有権クレデンシャルを発行する。
永住者クレデンシャルの提示を検証する。
新しく発行された 1 つ以上の単回使用の年齢証明クレデンシャルを受け取る。

ワークフロー・インスタンスは、たとえばコーディネーター Web サイトで使用するために、管理者によって作成されることが期待されます。ワークフロー・インスタンスは、ワークフロー・サービスの /workflows エンドポイントに HTTP POST を実行することで作成されます。 HTTP 要求本文には、ワークフロー・インスタンスの構成が含まれます。これには、ワークフローを定義するステップに関する情報や、検証可能なクレデンシャルを発行するために使用されるクレデンシャル・テンプレートが含まれますが、これらに限定されません。ワークフローを定義するステップもテンプレートである場合があり、追加の柔軟性を可能にします。ワークフローが検証可能なクレデンシャルの発行、または提示もしくはクレデンシャルの検証を伴う場合、ワークフロー・インスタンス構成には、1 つ以上の発行者サービスおよび／または検証サービスを使用するための認可ケイパビリティを含めることができます。

ワークフロー・インスタンスが存在すると、交換と呼ばれる特定のワークフロー・インタラクションを作成および照会する認可を、コーディネーターに与えることができます。

交換は、指定されたワークフローに基づく特定のインタラクションを表します。このインタラクションは、交換クライアントとワークフロー・サービスの間で行われます。交換は一時的なものであることが期待され、インタラクションが完了するまでの間だけ存在します。ワークフロー・サービスは、各交換について、その交換が保留中、アクティブ、または完了済みであるか、ワークフロー内の現在のステップ、ワークフロー固有の変数とデータ、および交換の実行中に受信された検証可能な提示とクレデンシャルなどの状態情報を保存します。実装者は、 Section 3.6.3 交換の作成で定義される予約済み変数に加えて、実装で望む任意の変数を自由に使用できます。ワークフロー内のステップ数に技術的な制限はありませんが、実装者はバグを防ぐために、既定の最大ステップ数を強制したい場合があります。

発行者、検証者、または保持者コーディネーターは、交換を作成する責任を負います。コーディネーターは、ワークフロー・サービス上で、選択したワークフローの /exchanges サブパスに HTTP POST を実行することで交換を作成します。 HTTP 要求本文には、交換の有効期限日時と、特定の交換についてワークフローのテンプレートに入力するために使用される任意の変数が含まれます。要求本文には、この API 以外の追加プロトコルを使用して交換を実行できるようにする構成オプションを含めることもできます。交換が作成されると、交換を識別し、それとのインタラクションを可能にする交換 URL がコーディネーターに返されます。

交換 URL は、交換クライアントが交換を開始できるように、そのクライアントに渡されます。交換 URL はコーディネーターに渡され、その後コーディネーターが交換クライアントに提供しますが、実際の交換は交換クライアントとワークフロー・サービスの間で実行されることに注意してください。交換 URL を交換クライアントに提供した後、コーディネーターは関与しません。明確にすると、コーディネーターは、交換自体を実行する必要があるユースケースでは、依然として自身の交換クライアントを使用できます。

交換を開始するには、交換 URL 以外の認可は必要ありません。ワークフロー・サービスの実装によっては、交換 URL はケイパビリティ URL（つまり、URL は推測不可能な秘密であり、その URL を与えられた者だけが交換を開始できる）である場合もあります。交換の基になるワークフローが、交換 URL の保有以外に追加の認可を必要とする場合、それは交換の開始時ではなく、交換中に取得されます。

交換 URL は、交換が進行するにつれて現在の状態を照会し、ワークフロー・サービスが保存した交換に関連する情報を取得するために、コーディネーターによって使用することもできます。この方法で交換を照会するには、コーディネーターが持つことが期待され、交換クライアントは持たない追加の認可が必要です。

交換 URL がコーディネーターから交換クライアントへどのように送信されるかは、この仕様の範囲外です。交換 URL をクライアントと共有する既知の仕組みには、 Credential Handler API（別名 CHAPI）、QR コード、またはユニバーサルリンクが含まれます。

交換は、この API の交換プロトコルに加えて、他のプロトコルを使用しても実行可能であるように設計されています。たとえば、交換は OID4VCI、OID4VP、DIDComm、および交換プロトコルのいずれでも実行可能である可能性があります。サポートされるプロトコルは、交換の基になるワークフローの複雑さと、交換が作成されたときにコーディネーターが提供したオプションに依存します。

交換クライアントは、交換 URL を受け取った方法と互換性のあるプロトコルを使用して、交換を開始することが期待されます。たとえば、この API プロトコルを使用すべきであることを示すプロトコル識別子とともに、交換 URL が CHAPI 経由で提供されている場合があります。あるいは、 OID4VCI クレデンシャル・オファー内の "credential_issuer" として、または OID4VP 認可要求の "client_id" として交換 URL が含まれ、それぞれ OID4VCI または OID4VP を使用すべきであることを示す場合があります。この節では、交換クライアントがこの API を使用して交換とやり取りする方法に焦点を当てます。 OID4VCI、OID4VP、DIDComm などの他のプロトコルと交換を組み合わせる方法については、付録 TBD を参照してください。

この API プロトコルを使用して実行される交換には、HTTP 上で要求本文および応答本文として送信されるメッセージが関与します。各メッセージは、以下のプロパティと値を 0 個以上含む単純な JSON オブジェクトで構成されます。

redirectUrl: 別の場所でインタラクションを継続するために使用できる URL。このユースケースの 1 つは、交換が完了した後に、交換クライアントのユーザーをコーディネーター Web サイトへ戻すことです。
verifiablePresentation: Verifiable Presentation。これは、交換の一方の当事者が他方の当事者へ情報を提供するために使用されます。後者がそれを要求したためである場合も、前者が単にそれを提供している場合もあります。
verifiablePresentationRequest: Verifiable Presentation Request。これは、交換の一方の当事者が他方の当事者から情報を要求するために使用されます。

カスタムのプロパティと値も含まれる場合がありますが、それらを認識しない実装ではエラーを引き起こすことが期待されます。

この API プロトコルを使用して交換を開始するには、交換クライアントは JSON オブジェクトを要求本文として送信する HTTP POST を実行します。最も単純な場合、クライアントが交換に対して独自の制約を持たない場合、すなわち他方の当事者から要求するものが何もない場合、 JSON オブジェクトは空（{}）です。ワークフロー・サービスは、応答本文で自身の JSON オブジェクトを返します。

その応答オブジェクトが空の場合、交換は完了しており、交換クライアントから要求されるものも、交換クライアントへ提供されるものもありません。オブジェクトに verifiablePresentationRequest が含まれる場合、交換はまだ完了しておらず、関連付けられた検証可能な提示要求の内容で指定される追加情報が要求されています。オブジェクトに verifiablePresentation が含まれる場合、交換クライアントを操作する保持者に発行された検証可能なクレデンシャルや、交換クライアントの要求に基づく交換サーバーの運用者に関する情報を含む検証可能なクレデンシャルなど、何らかの情報が提供されています。オブジェクトに redirectUrl が含まれる場合、交換は完了しており、ワークフロー・サービスは、クライアントが別の形式でインタラクションを継続するために別の場所へ進むことを推奨しています。

多くの検証可能なクレデンシャルのユースケースは、これらの基本プリミティブを使用して実装できます。交換のいずれの当事者も、検証可能な提示を要求し、信頼を確立するため、および／または認可ケイパビリティを取得するために必要となる 1 つ以上の検証可能なクレデンシャルを提供できます。また、いずれの当事者も、自身が保持する、または自身が発行したクレデンシャルを提示できます。特定のワークフローは、特定の提示とクレデンシャルを期待し、期待される情報の流れからの逸脱を拒否するよう構成できます。ワークフロー・サービスが特定のメッセージを受け入れられないと判断した場合、 4xx HTTP ステータス・メッセージと、そのエラーに関する情報を表す JSON オブジェクトで応答することにより、エラーを発生させます。

交換の設計アプローチは階層化されています。これは、最小限の通信メッセージ層と、ほとんどのユースケースを上位層の特定の検証可能な提示要求および検証可能なクレデンシャルを介して実装できるようにする一連のプリミティブを提供することを目的としています。特定の検証可能な提示要求と検証可能なクレデンシャルを使用するワークフローと交換の例については、後続の付録を参照してください。

注記: ワークフロー・ステップとクレデンシャルの例

ステップとクレデンシャル・テンプレートの最小限の実用例、およびいくつかのより複雑なワークフロー・テンプレートは、付録ワークフロー・ステップとテンプレートの例にあります。

交換との特定のインタラクションは短命であることが期待されますが、より長い、または複数段階のインタラクションを可能にするために他の仕組みを使用できます。他のインタラクションの仕組みの例には、SMS、メール、Web 通知、または電話が含まれます。このアプローチにより、デジタル・ウォレットの実装が簡素化され、この API 内で再発明することなく既存の仕組みを再利用できます。Web またはネイティブ・プラットフォームは、アプリケーション（Web ブラウザーなど）または他のプラットフォーム機能を通じて追加のインタラクションを可能にすることが期待されます。たとえば、非同期発行では、保持者がクレデンシャルを要求しますが、処理を待ちます。このような場合、システム・コンポーネント（発行者コーディネーターなど）は、この API の外部の仕組みを使用して、クレデンシャルの収集準備ができたときに保持者へ通知します。

信頼境界をまたぐ必要があるクレデンシャルのユースケースでワークフローと交換を使用するために、以下の API が定義されています。

エンドポイント	説明
POST /workflows	新しいワークフローを作成し、応答ヘッダーでワークフロー・メタデータの場所を返します。
GET /workflows/{localWorkflowId}	既存のワークフローの構成を取得し、応答本文で返します。
POST /workflows/{localWorkflowId}/exchanges	新しい交換を作成し、応答ヘッダーで交換メタデータの場所を返します。
GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}	既存の交換の状態を取得し、応答本文で返します。
POST /workflows/{localWorkflowId}/exchanges/{localExchangeId}	交換に参加します。空の本文を POST すると、交換を開始するか、次のステップを完了するために交換が期待しているものを返します。Verifiable Presentation Request を POST すると、 4xx エラー、または以下のいずれか、すなわちクライアントの要求に適合する Verifiable Presentation または Verifiable Presentation Request が返されます。 Verifiable Presentation が送信される場合、交換を継続するために追加の Verifiable Presentation Request も送信される場合があります。

ワークフローおよび交換 API において、"local" ID は、サービス・インスタンスに対してローカルな ID を指します。言い換えると、exchangeId または workflowId は完全修飾 URL を指す一方、 localExchangeId または localWorkflowId は URL パス内の特定の要素を指します。

POST /workflows - 新しいワークフローを作成し、応答ヘッダーでワークフロー・メタデータの場所を返します。

/workflows エンドポイントは、POST を受信する際に以下のスキーマを使用します。

プロパティ	説明
`id` [string]	作成されるワークフローに使用される ID。ID を渡すことは OPTIONAL です。
`initialStep` [string]	上記の集合のうち、交換が開始されるステップ。initialStep を渡すことは REQUIRED です。
`controller` [string]	インスタンスのルート・コントローラーを指定する OPTIONAL なプロパティ。これは、オブジェクト・ケイパビリティに依存する Authorization Capabilities (ZCAPs) のような認可メカニズムをサポートするシステムで使用できます。この値は、`authorization` プロパティと組み合わせて使用し、他の認可メカニズムを同時に許可できます。
`authorization` [object]	OAuth2 構成など、エンドポイントの認可スキーム情報を指定する OPTIONAL なプロパティ。これは以下の形式のオブジェクトで MUST あります。 `oauth2` [object] OAuth2 構成。これは以下の形式のオブジェクトで MUST あります。 `issuerConfigUrl` [string] OAuth2 発行者構成 URL。
`credentialTemplates` [array]	各項目が以下の形式のオブジェクトで MUST ある配列。 `id` [string] テンプレートの ID。 `type` [string] テンプレートの型。 `template` [string] テンプレートそのもの。
`steps` [object]	ワークフロー上で交換を完了するために必要な 1 つ以上のステップ。 steps オブジェクトを渡すことは REQUIRED です。キーは 1 つ以上のステップ名であり、各 STEP_NAME はステップの名前（`request-employee-id` など）に置き換えられ、値はステップ構成です。これは以下の形式のオブジェクトで MUST あります。 `STEP_NAME` [object] テンプレートが使用されない場合に含めるステップ・データのいずれか。これは以下の形式のオブジェクトで MUST あります。 `createChallenge` [boolean] 交換が、zcap を持つ VCALM 検証者サービスを介してチャレンジ管理を処理するよう指示する任意のステップ指令。 `verifiablePresentationRequest` [object] Verifiable Presentation Request。これは以下の形式のオブジェクトで MUST あります。 `query` [array] 要求者によって送信される 1 つ以上のクエリの集合。 `query` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `type` [array] クエリの型。`type` 配列内の各項目は文字列で MUST あります。 `credentialQuery` [object] QueryByExample クエリの場合、クレデンシャル要求の詳細を指定します。これは以下の形式のオブジェクトで MUST あります。 `reason` [string] クレデンシャルが要求されている理由についての人間可読な説明。 `example` [object] オブジェクト `acceptedIssuers` [array] 要求されたクレデンシャルに対して受け入れられる発行者。 `acceptedIssuers` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `issuer` [string] `acceptedCryptosuites` [array] 検証者が受け入れる暗号証明スイート。各要素は、Data Integrity 暗号スイート名、またはレガシー用の `Ed25519Signature2020` を参照する `cryptosuite` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用され、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、エンベロープされたクレデンシャルにのみ適用される `acceptedEnvelopes` とは独立して MAY 使用できます。 `acceptedCryptosuites` 配列内の各項目は undefined: で MUST あります `acceptedEnvelopes` [array] 検証者が受け入れるエンベロープ形式。各要素は、エンベロープ用のメディア型を参照する `mediaType` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用され、メディア型として解釈されます）。これにより、保持者は既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される `acceptedCryptosuites` とは独立して MAY 使用できます。 `acceptedEnvelopes` 配列内の各項目は undefined: で MUST あります `challenge` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるチャレンジ。通常、Verifiable Presentation 応答に含められることが期待されます。 `domain` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるドメイン。通常、Verifiable Presentation 応答に含められることが期待されます。 `interact` [array] サーバーがサポートするインタラクション・メカニズムのリスト。 `interact` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `service` [object] Verifiable Presentation Request への応答を受信できる、サーバーがサポートするサービス。これは以下の形式のオブジェクトで MUST あります。 `type` [array] サービスの型。`type` 配列内の各項目は文字列で MUST あります。 `serviceEndpoint` [string] Verifiable Presentation Request に応答する目的で、サービスとやり取りするために利用できる URL。 `verifiablePresentation` [object] 以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります。 `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか。 `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります。 `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `redirectUrl` [string] 別の場所でインタラクションを継続するために使用できる、クライアントへ送信する URL。redirectUrl を渡すことは OPTIONAL です。 `callback` [object] このステップの実行後に呼び出されるコールバック。これは以下の形式のオブジェクトで MUST あります。 `url` [string] コールバック・データを受信する URL。 `issueRequests` [array] `issueRequests` 配列内の各項目は { "required": [ "credentialTemplateId" ] } または { "required": [ "credentialTemplateIndex" ] } で MUST あります。 `presentationSchema` 提示に対して実行される妥当性確認を記述する JSON Schema のいずれか。これは以下の形式のオブジェクトで MUST あります。 `type` [string] 値は `JsonSchema` で MUST あります。 `jsonSchema` [object] オブジェクトまたは、現在のステップで提示を妥当性確認するときに使用する代替の提示スキーマ形式。特定の提示スキーマ型には追加プロパティが期待されますが、この仕様の範囲外です。これは以下の形式のオブジェクトで MUST あります。 `type` [string] 提示を妥当性確認するときに使用する提示スキーマ・メカニズムの型。 `verifyPresentationResponseSchema` 提示の検証結果に対して実行される妥当性確認を記述する JSON Schema のいずれか。これは以下の形式のオブジェクトで MUST あります。 `type` [string] 値は `JsonSchema` で MUST あります。 `jsonSchema` [object] オブジェクトまたは、現在のステップで提示を検証した結果に使用する代替の提示スキーマ形式。特定の提示スキーマ型には追加プロパティが期待されますが、この仕様の範囲外です。これは以下の形式のオブジェクトで MUST あります。 `type` [string] 提示の検証結果を妥当性確認するときに使用する提示スキーマ・メカニズムの型。 `nextStep` [string] シーケンス内の次のステップ名。nextStep を渡すことは OPTIONAL です。このフィールドは最終ステップ構成には存在しては MUST NOT なりません。 `openId` [object] 以下のいずれか { "required": [ "createAuthorizationRequest" ], "not": { "required": [ "authorizationRequest" ] } } または { "required": [ "authorizationRequest" ], "not": { "required": [ "createAuthorizationRequest" ] } } または以下の形式のオブジェクト: `clientProfiles` [object] オブジェクトまたは以下の形式のオブジェクト: `stepTemplate` [object] ワークフロー・ステップのテンプレート。これか他のステップ・データのいずれかが存在しなければなりませんが、両方の集合が存在してはなりません。これは以下の形式のオブジェクトで MUST あります。 `type` [string] テンプレートの型。 `template` [string] ステップ・テンプレート。

/workflows エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります。

応答	本文
201	ワークフローが正常に作成されました（データあり）
204	ワークフローが正常に作成されました（データなし）
400	無効な入力
401	認可されていません
500	内部エラー

ワークフローには、ステップ、クレデンシャル・テンプレート、および認可に関する情報を含めることができます。場合によっては、ワークフローがその構成内の異なる箇所（通常はクレデンシャル・テンプレート内）で予約済みの results 変数を参照することもあります。この変数は、交換の過程を通じてワークフロー・サービスがクライアントから受信するデータを保持します。以下は、DID Authentication ステップとクレデンシャル配信ステップを含む基本的なワークフロー構成です。

issueRequests 配列を含むステップには、1 つ以上の発行要求オブジェクトが含まれます。各発行要求オブジェクトは、使用するクレデンシャル・テンプレートを、その識別子（credentialTemplateId）またはワークフローの credentialTemplates 配列内のインデックス（credentialTemplateIndex）のいずれかで識別します。発行要求オブジェクトは、クレデンシャル・テンプレートを評価するときに使用される値を提供するために、variables プロパティを MAY 含めることもできます。既定では、各発行要求の結果は、同じステップで交換クライアントに送信される検証可能な提示に含まれます。発行要求オブジェクトは、任意の result プロパティを MAY 含めることができ、その値は、交換の variables オブジェクト内のトップレベル変数の名前、または交換の variables オブジェクト内の任意の変数への JSON ポインターのいずれかで MUST あり、発行要求の結果を保存する場所を識別します。これにより、後続のステップが保存された結果を参照できる、または交換が終了し、交換状態にアクセスできる当事者が、その結果を別の交換やその他の仕組みで使用するために取得できるため、より大きな合成性が可能になります。

例 12: 基本的なワークフロー

{
  "id": "9fd3bc6d-4a04-4b3d-a983-3482d0586626",
  "initialStep": "didAuthRequest",
  "steps": {
    "didAuthRequest": {
      "createChallenge": true,
      "verifiablePresentationRequest": {
        "query": {
          "type": "DIDAuthentication",
          "acceptedMethods": [
            {
              "method": "key"
            },
            {
              "method": "web"
            }
          ],
          "acceptedCryptosuites": [
            {
              "cryptosuite": "eddsa-rdfc-2022"
            },
            {
              "cryptosuite": "ed25519-2020"
            }
          ]
        },
        "domain": "https://issuer.example.com"
      },
      "nextStep": "credentialDelivery"
    },
    "credentialDelivery": {
      "issueRequests": [
        {
          "credentialTemplateId": "caffb919-053a-4bfa-beba-80567904f842",
          "variables": "sampleAchievementCredential"
        }
      ]
    }
  },
  "credentialTemplates": [
    {
      "id": "caffb919-053a-4bfa-beba-80567904f842",
      "type": "jsonata",
      "template": "{
        \"credential\": {
          \"@context\": [
            \"https://www.w3.org/ns/credentials/v2\",
            \"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json\",
            \"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json\"
          ],
          \"id\": sampleAchievementCredential.id,
          \"type\": [\"VerifiableCredential\", \"AchievementCredential\"],
          \"issuer\": {
            \"type\": [\"Profile\"],
            \"name\": \"Example Issuer\",
            \"image\": {
              \"type\": \"Image\",
              \"id\": \"https://issuer.example.com/logo.png\"
            }
          },
          \"awardedDate\": sampleAchievementCredential.awardedDate,
          \"validFrom\": sampleAchievementCredential.validFrom,
          \"name\": \"Sample Achievement\",
          \"credentialSubject\": {
            \"id\": results.didAuthRequest.verifiablePresentation.holder,
            \"type\": \"AchievementSubject\",
            \"name\": sampleAchievementCredential.credentialSubject.name,
            \"achievement\": {
              \"id\": sampleAchievementCredential.credentialSubject.achievement.id,
              \"type\": [\"Achievement\"],
              \"achievementType\": sampleAchievementCredential.credentialSubject.achievement.achievementType,
              \"name\": sampleAchievementCredential.credentialSubject.achievement.name,
              \"description\": sampleAchievementCredential.credentialSubject.achievement.description,
              \"alignment\": sampleAchievementCredential.credentialSubject.achievement.alignment
            }
          }
        }
      }"
    }
  ],
  "controller": "did:web:issuer.example.com"
}

ステップは、そのステップで使用される検証可能な提示を明示的に表現するために、verifiablePresentation を MAY 含めることができます。この提示は、交換内の他の変数を介して構成でき、そのステップ中に（issueRequests に従って）発行される可能性のある追加の検証可能なクレデンシャルで拡張することもできます。これは、特定の検証可能な提示のバージョンが必要なユースケース、特定のサブタイプの検証可能な提示が必要なユースケース、または特定の検証可能な提示の内容が必要なユースケースをサポートします。これには、ワークフロー・ステップで配信されるべき、以前に帯域外で発行された検証可能なクレデンシャルも含まれます。

ステップは、別の場所でインタラクションを継続するために使用できる URL をクライアントへ送信することを指定するために、redirectUrl を MAY 含めることができます。このユースケースの 1 つは、交換が完了した後に、交換クライアントのユーザーをコーディネーター Web サイトへ戻すことです。別のユースケースは、クライアントが Web ブラウザーへ移動することを要求せずに、サーバーが継続中のインタラクション中にカスタム・ビジネスルールを実装できるようにするインタラクション URLを返すことです。たとえば、最初の交換がユーザーから情報を要求し、その後 redirectUrl を介してインタラクション URLを返す場合があります。クライアント（たとえばデジタル・ウォレット）は、それがインタラクション URL （たとえば URL が ?iuv=1 を使用する）であると判断して取得でき、その結果、インタラクション・サーバーはカスタム・ビジネスロジックを実行し、その後インタラクションを継続するための別の交換を含むプロトコル・オブジェクトを返します。

一部のワークフローでは、その 1 つ以上のステップでカスタム変数を参照する必要があります。この場合、コーディネーターは交換を作成するときに、その変数に適切な値を提供する必要があります。以下は、テンプレート化された DID Authentication ステップを持つワークフロー構成の例です（didAuthRequest ステップで参照されている verifiablePresentationRequest 変数と callbackUrl 変数に注意してください）。

例 13: テンプレート化されたワークフロー

{
  "id": "9fd3bc6d-4a04-4b3d-a983-3482d0586626",
  "initialStep": "didAuthRequest",
  "steps": {
    "didAuthRequest": {
      "stepTemplate": {
        "type": "jsonata",
        "template": "{
          "createChallenge": true,
          "verifiablePresentationRequest": verifiablePresentationRequest,
          "callback": {
            "url": callbackUrl
          },
          "nextStep": "credentialDelivery"
        }"
      }
    },
    "credentialDelivery": {
      "issueRequests": [
        {
          "credentialTemplateId": "caffb919-053a-4bfa-beba-80567904f842",
          "variables": "sampleAchievementCredential"
        }
      ]
    }
  },
  "credentialTemplates": [
    {
      "id": "caffb919-053a-4bfa-beba-80567904f842",
      "type": "jsonata",
      "template": "{
        \"credential\": {
          \"@context\": [
            \"https://www.w3.org/ns/credentials/v2\",
            \"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json\",
            \"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json\"
          ],
          \"id\": sampleAchievementCredential.id,
          \"type\": [\"VerifiableCredential\", \"AchievementCredential\"],
          \"issuer\": {
            \"type\": [\"Profile\"],
            \"name\": \"Example Issuer\",
            \"image\": {
              \"type\": \"Image\",
              \"id\": \"https://issuer.example.com/logo.png\"
            }
          },
          \"awardedDate\": sampleAchievementCredential.awardedDate,
          \"validFrom\": sampleAchievementCredential.validFrom,
          \"name\": \"Sample Achievement\",
          \"credentialSubject\": {
            \"id\": results.didAuthRequest.verifiablePresentation.holder,
            \"type\": \"AchievementSubject\",
            \"name\": sampleAchievementCredential.credentialSubject.name,
            \"achievement\": {
              \"id\": sampleAchievementCredential.credentialSubject.achievement.id,
              \"type\": [\"Achievement\"],
              \"achievementType\": sampleAchievementCredential.credentialSubject.achievement.achievementType,
              \"name\": sampleAchievementCredential.credentialSubject.achievement.name,
              \"description\": sampleAchievementCredential.credentialSubject.achievement.description,
              \"alignment\": sampleAchievementCredential.credentialSubject.achievement.alignment
            }
          }
        }
      }"
    }
  ],
  "controller": "did:web:issuer.example.com"
}

openId オプション、特に createAuthorizationRequest と authorizationRequest の値については、開発者が OID4VP Authorization Request がどのようなものか理解しやすいように、以下の例を提供します。

例 14: OID4VP Authorization Request

{
  "response_type": "vp_token",
  "presentation_definition": {
    "id": "f1bd224a-0fed-469a-b64a-dad7cf63fd98",
    "input_descriptors": [
      {
        "id": "77d50c71-95ef-442c-a372-f32e17634fab",
        "constraints": {
          "fields": [
            {
              "path": [
                "$['@context']"
              ],
              "filter": {
                "type": "array",
                "contains": {
                  "type": "string",
                  "const": "https://www.w3.org/ns/credentials/v2"
                }
              }
            },
            {
              "path": [
                "$['type']"
              ],
              "filter": {
                "type": "array",
                "contains": {
                  "type": "string",
                  "const": "VerifiableCredential"
                }
              }
            },
            {
              "path": [
                "$['credentialSubject']['name']"
              ],
              "filter": {
                "type": "string"
              }
            }
          ]
        },
        "purpose": "We require a name credential to display your name when you post messages."
      }
    ]
  },
  "response_mode": "direct_post",
  "client_metadata": {
    "vp_formats_supported": {
      "ldp_vc": {
        "proof_type_values": [
          "DataIntegrityProof",
          "Ed25519Signature2020"
        ],
        "cryptosuite_values": [
          "ecdsa-rdfc-2019",
          "eddsa-rdfc-2022"
        ]
      }
    },
    "vp_formats": {
      "jwt_vp": {
        "alg": [
          "EdDSA",
          "Ed25519",
          "ES256",
          "ES384"
        ]
      },
      "jwt_vp_json": {
        "alg": [
          "EdDSA",
          "Ed25519",
          "ES256",
          "ES384"
        ]
      },
      "di_vp": {
        "proof_type": [
          "ecdsa-rdfc-2019",
          "eddsa-rdfc-2022",
          "Ed25519Signature2020"
        ]
      },
      "ldp_vp": {
        "proof_type": [
          "ecdsa-rdfc-2019",
          "eddsa-rdfc-2022",
          "Ed25519Signature2020"
        ]
      }
    }
  },
  "client_id": "https://some.example/workflows/z1A7ojitBF3pGpVzW17MgU7zm/exchanges/z1ACKwiBiXmuGjpKAdKMpBZXB/openid/client/authorization/response",
  "client_id_scheme": "redirect_uri",
  "response_uri": "https://some.example/workflows/z1A7ojitBF3pGpVzW17MgU7zm/exchanges/z1ACKwiBiXmuGjpKAdKMpBZXB/openid/client/authorization/response",
  "nonce": "z1ACKwiBiXmuGjpKAdKMpBZXB"
}

GET /workflows/{localWorkflowId} - 既存のワークフローの構成を取得し、応答本文で返します。

/workflows/{localWorkflowId} エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
200	ワークフロー構成が取得されました! content-type: application/json ワークフローに関する情報を含むオブジェクト。これは以下の形式のオブジェクトで MUST あります: `id` [string] 作成されるワークフローに使用される ID。ID を渡すことは OPTIONAL です。 `initialStep` [string] 上記の集合のうち、交換が開始されるステップ。intialStep を渡すことは REQUIRED です。 `controller` [string] インスタンスのコントローラー。controller を渡すことは OPTIONAL です。 `authorization` [object] 認可スキーム情報（例: OAuth2 構成）。 authorization を渡すことは OPTIONAL です。これは以下の形式のオブジェクトで MUST あります: `oauth2` [object] OAuth2 構成。これは以下の形式のオブジェクトで MUST あります: `issuerConfigUrl` [string] OAuth2 発行者構成 URL。 `credentialTemplates` [array] クレデンシャル発行用の 1 つ以上のテンプレート。 `template` 文字列は、クレデンシャル・テンプレートを保持する `credential` フィールドと、（任意で）重要なクレデンシャル発行パラメーターを保持する `options` フィールドを含むオブジェクトにレンダリングされるべきです（これは `POST /credentials/issue` に送信される要求本文の形式です）。`credentialTemplates` を渡すことは OPTIONAL です。 `credentialTemplates` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `type` [string] テンプレートの型。 `template` [string] テンプレートそのもの。 `steps` [object] ワークフロー上で交換を完了するために必要な 1 つ以上のステップ。キーは 1 つ以上のステップ名であり、各 STEP_NAME はステップの名前（`request-employee-id` など）に置き換えられ、値はステップ構成です。これは以下の形式のオブジェクトで MUST あります: `STEP_NAME` [object] テンプレートが使用されない場合に含めるステップ・データのいずれか。これは以下の形式のオブジェクトで MUST あります: `createChallenge` [boolean] 交換が、zcap を持つ VCALM 検証者サービスを介してチャレンジ管理を処理するよう指示する任意のステップ指令。 `verifiablePresentationRequest` [object] Verifiable Presentation Request。これは以下の形式のオブジェクトで MUST あります: `query` [array] 要求者によって送信される 1 つ以上のクエリの集合。 `query` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `type` [array] クエリの型。 `type` 配列内の各項目は文字列で MUST あります。 `credentialQuery` [object] QueryByExample クエリの場合、クレデンシャル要求の詳細を指定します。これは以下の形式のオブジェクトで MUST あります: `reason` [string] クレデンシャルが要求されている理由についての人間可読な説明。 `example` [object] オブジェクト `acceptedIssuers` [array] 要求されたクレデンシャルに対して受け入れられる発行者。 `acceptedIssuers` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `issuer` [string] `acceptedCryptosuites` [array] 検証者が受け入れる暗号証明スイート。各要素は、Data Integrity 暗号スイート名またはレガシー用の `Ed25519Signature2020` を参照する `cryptosuite` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、 `acceptedEnvelopes` とは独立して MAY 使用できます。 `acceptedEnvelopes` は、エンベロープされたクレデンシャルにのみ適用されます。 `acceptedCryptosuites` 配列内の各項目は undefined: で MUST あります。 `acceptedEnvelopes` [array] 検証者が受け入れるエンベロープ形式。各要素は、エンベロープ用のメディア型を参照する `mediaType` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、メディア型として解釈されます）。これにより、保持者は既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される `acceptedCryptosuites` とは独立して MAY 使用できます。 `acceptedEnvelopes` 配列内の各項目は undefined: で MUST あります。 `challenge` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるチャレンジ。通常、Verifiable Presentation 応答に含められることが期待されます。 `domain` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるドメイン。通常、Verifiable Presentation 応答に含められることが期待されます。 `interact` [array] サーバーがサポートするインタラクション・メカニズムのリスト。 `interact` 配列内の各項目は以下の形式のオブジェクトで MUST あります: `service` [object] Verifiable Presentation Request への応答を受信できる、サーバーがサポートするサービス。これは以下の形式のオブジェクトで MUST あります: `type` [array] サービスの型。 `type` 配列内の各項目は文字列で MUST あります。 `serviceEndpoint` [string] Verifiable Presentation Request に応答する目的でサービスとやり取りするために利用できる URL。 `verifiablePresentation` [object] 以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。 `type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。 `verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります: `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。 Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。 `type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか: `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、 challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `redirectUrl` [string] 別の場所でインタラクションを継続するために使用できる、クライアントへ送信する URL。 redirectUrl を渡すことは OPTIONAL です。 `callback` [object] このステップの実行後に呼び出されるコールバック。これは以下の形式のオブジェクトで MUST あります: `url` [string] コールバック・データを受信する URL。 `issueRequests` [array] `issueRequests` 配列内の各項目は MUST { "required": [ "credentialTemplateId" ] } または { "required": [ "credentialTemplateIndex" ] } `presentationSchema` 提示に対して実行される妥当性確認を記述する JSON Schema のいずれか。これは以下の形式のオブジェクトで MUST あります: `type` [string] 値は `JsonSchema` で MUST あります。 `jsonSchema` [object] オブジェクトまたは、現在のステップで提示を妥当性確認するときに使用する代替の提示スキーマ形式。特定の提示スキーマ型には追加プロパティが期待されますが、この仕様の範囲外です。これは以下の形式のオブジェクトで MUST あります: `type` [string] 提示を妥当性確認するときに使用する提示スキーマ・メカニズムの型。 `verifyPresentationResponseSchema` 提示の検証結果に対して実行される妥当性確認を記述する JSON Schema のいずれか。これは以下の形式のオブジェクトで MUST あります: `type` [string] 値は `JsonSchema` で MUST あります。 `jsonSchema` [object] オブジェクトまたは、現在のステップで提示を検証した結果に使用する代替の提示スキーマ形式。特定の提示スキーマ型には追加プロパティが期待されますが、この仕様の範囲外です。これは以下の形式のオブジェクトで MUST あります: `type` [string] 提示の検証結果を妥当性確認するときに使用する提示スキーマ・メカニズムの型。 `nextStep` [string] シーケンス内の次のステップ名。 nextStep を渡すことは OPTIONAL です。このフィールドは最終ステップ構成に存在しては MUST NOT なりません。 `openId` [object] 以下のいずれか { "required": [ "createAuthorizationRequest" ], "not": { "required": [ "authorizationRequest" ] } } または { "required": [ "authorizationRequest" ], "not": { "required": [ "createAuthorizationRequest" ] } } または以下の形式のオブジェクト: `clientProfiles` [object] オブジェクトまたは以下の形式のオブジェクト: `stepTemplate` [object] ワークフロー・ステップのテンプレート。これか他のステップ・データのいずれかが存在しなければなりませんが、両方の集合が存在してはなりません。これは以下の形式のオブジェクトで MUST あります: `type` [string] テンプレートの型。 `template` [string] ステップ・テンプレート。
400	無効な入力
401	認可されていません
500	内部エラー

交換には expires プロパティが関連付けられており、交換の有効期限日時を示します。これは /workflows/{localWorkflowId}/exchanges エンドポイントを使用して作成されます。これは、そのような交換に関連付けられたチャレンジの有効期間に影響します。チャレンジが交換に結び付けられている場合、そのチャレンジは交換の expires プロパティで参照される日時に有効でなくなります。

POST /workflows/{localWorkflowId}/exchanges - 新しい交換を作成し、応答ヘッダーで交換メタデータの場所を返します。

/workflows/{localWorkflowId}/exchanges エンドポイントは、POST を受信する際に以下のスキーマを使用します:

プロパティ説明

expires [string] 交換が期限切れになる日時（XML Schema dateTimeStamp として表現される）。

variables [object] オブジェクト

プロパティ	説明
`expires` [string]	交換が期限切れになる日時（XML Schema dateTimeStamp として表現される）。
`variables` [object]	オブジェクト
`openId` [object]	{ "required": [ "createAuthorizationRequest" ], "not": { "required": [ "authorizationRequest" ] } } または { "required": [ "authorizationRequest" ], "not": { "required": [ "createAuthorizationRequest" ] } } または以下の形式のオブジェクト: `clientProfiles` [object] オブジェクト

openId [object]

{
  "required": [
    "createAuthorizationRequest"
  ],
  "not": {
    "required": [
      "authorizationRequest"
    ]
  }
}

または

{
  "required": [
    "authorizationRequest"
  ],
  "not": {
    "required": [
      "createAuthorizationRequest"
    ]
  }
}

または以下の形式のオブジェクト:

clientProfiles [object]: オブジェクト

/workflows/{localWorkflowId}/exchanges エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
201	交換が正常に作成されました（データあり）
204	交換が正常に作成されました（データなし）
400	無効な入力
401	認可されていません
500	内部エラー

このエンドポイントは、クライアントが、交換がサポートするすべてのプロトコルをその交換に照会するための仕組みを提供します。単一の交換は、デジタル・ウォレットへの検証可能なクレデンシャルの発行など、交換の目標を達成できる多くのプロトコルをサポートできます。

GET /workflows/{localWorkflowId}/exchanges/{localExchangeId}/protocols - 特定の交換とやり取りするためにサポートされるプロトコルを取得します。

/workflows/{localWorkflowId}/exchanges/{localExchangeId}/protocols エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
200	交換が理解するプロトコル。 content-type: application/json 特定の交換を実行するために使用できるプロトコルに関する情報を含むオブジェクト。これは以下の形式のオブジェクトで MUST あります: `protocols` [object] 特定の交換を実行するために使用できる 1 つ以上のプロトコルを含むオブジェクト。これは以下の形式のオブジェクトで MUST あります: `interact` [string] 人間が関与する交換フロー中に使用できる URL。詳細については、interact URL 形式の節を参照してください。 `vcapi` [string] VCALM 交換を開始するときに使用する URL。 `OID4VP` [string] OID4VP 提示を開始するときに使用する URL。 `OID4VCI` [string] OID4VCI 発行を開始するときに使用する URL。
400	無効な入力
401	認可されていません
500	内部エラー

このエンドポイントはまた、Web サイト運営者が、HTTPS ドメインを通じてその信頼を委任することで、サービス・プロバイダーなどの第三者に交換を実行する権限を委任できるようにします。たとえば、Web サイト brand.example は、プロトコル一覧で saas.example ドメインを使用することにより、交換の運用をパートナー saas.example に委任できます。

これにより、クライアントは brand.example への信頼に基づいて、 Web サイトが Web ページをレンダリングするために他のドメインのリソースへリンクするのと同じ方法で、交換の運用を第三者に委任できます。

サーバーは、交換メッセージに referenceId プロパティを含めても MAY かまいません。クライアントが referenceId を受信した場合、次にサーバーへ送るメッセージに同じ referenceId を含める SHOULD です。これはデバッグに役立ち、遅延した可能性のある、または順序が乱れたメッセージが正しい要求に関連付けられることを保証します。 referenceId の値は urn:uuid: 値である SHOULD です。

POST /workflows/{localWorkflowId}/exchanges/{localExchangeId} - 交換に参加します。空の本文を POST すると、交換を開始するか、次のステップを完了するために交換が期待しているものを返します。Verifiable Presentation Request を POST すると、4xx エラー、または以下のいずれか、すなわちクライアントの要求に適合する Verifiable Presentation または Verifiable Presentation Request が返されます。Verifiable Presentation が送信される場合、交換を継続するために追加の Verifiable Presentation Request も送信される場合があります。

/workflows/{localWorkflowId}/exchanges/{localExchangeId} エンドポイントは、POST を受信する際に以下のいずれかのスキーマを使用します:

プロパティ	説明

あるいは、/workflows/{localWorkflowId}/exchanges/{localExchangeId} エンドポイントは、以下のスキーマも使用できます:

プロパティ説明

プロパティ	説明
`verifiablePresentationRequest` [object]	Verifiable Presentation Request。これは以下の形式のオブジェクトで MUST あります: `query` [array] 要求者によって送信される 1 つ以上のクエリの集合。 `query` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `type` [array] クエリの型。`type` 配列内の各項目は文字列で MUST あります。 `credentialQuery` [object] QueryByExample クエリの場合、クレデンシャル要求の詳細を指定します。これは以下の形式のオブジェクトで MUST あります: `reason` [string] クレデンシャルが要求されている理由についての人間可読な説明。 `example` [object] オブジェクト `acceptedIssuers` [array] 要求されたクレデンシャルに対して受け入れられる発行者。 `acceptedIssuers` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `issuer` [string] `acceptedCryptosuites` [array] 検証者が受け入れる暗号証明スイート。各要素は、 Data Integrity 暗号スイート名、またはレガシー用の `Ed25519Signature2020` を参照する `cryptosuite` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、エンベロープされたクレデンシャルにのみ適用される `acceptedEnvelopes` とは独立して MAY 使用できます。 `acceptedCryptosuites` 配列内の各項目は undefined: で MUST あります。 `acceptedEnvelopes` [array] 検証者が受け入れるエンベロープ形式。各要素は、エンベロープ用のメディア型を参照する `mediaType` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、メディア型として解釈されます）。これにより、保持者は既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される `acceptedCryptosuites` とは独立して MAY 使用できます。 `acceptedEnvelopes` 配列内の各項目は undefined: で MUST あります。 `challenge` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるチャレンジ。通常、Verifiable Presentation 応答に含められることが期待されます。 `domain` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるドメイン。通常、Verifiable Presentation 応答に含められることが期待されます。 `interact` [array] サーバーがサポートするインタラクション・メカニズムのリスト。 `interact` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `service` [object] Verifiable Presentation Request への応答を受信できる、サーバーがサポートするサービス。これは以下の形式のオブジェクトで MUST あります: `type` [array] サービスの型。`type` 配列内の各項目は文字列で MUST あります。 `serviceEndpoint` [string] Verifiable Presentation Request に応答する目的で、サービスとやり取りするために利用できる URL。
`referenceId` [string]	サーバーが以前に referenceId を送信した場合、クライアントはデバッグとメッセージ相関を支援するために、ここにそれを含めるべきです（SHOULD）。値は urn:uuid 値であるべきです（SHOULD）。

verifiablePresentationRequest [object]

Verifiable Presentation Request。これは以下の形式のオブジェクトで MUST あります:

query [array]

要求者によって送信される 1 つ以上のクエリの集合。 query 配列内の各項目は、以下の形式のオブジェクトで MUST あります:

type [array]

クエリの型。type 配列内の各項目は文字列で MUST あります。

credentialQuery [object]

QueryByExample クエリの場合、クレデンシャル要求の詳細を指定します。これは以下の形式のオブジェクトで MUST あります:

reason [string]

クレデンシャルが要求されている理由についての人間可読な説明。

example [object]

オブジェクト

acceptedIssuers [array]

要求されたクレデンシャルに対して受け入れられる発行者。 acceptedIssuers 配列内の各項目は、以下の形式のオブジェクトで MUST あります:

issuer [string]

acceptedCryptosuites [array]

検証者が受け入れる暗号証明スイート。各要素は、 Data Integrity 暗号スイート名、またはレガシー用の Ed25519Signature2020 を参照する cryptosuite プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、エンベロープされたクレデンシャルにのみ適用される acceptedEnvelopes とは独立して MAY 使用できます。 acceptedCryptosuites 配列内の各項目は undefined: で MUST あります。

acceptedEnvelopes [array]

検証者が受け入れるエンベロープ形式。各要素は、エンベロープ用のメディア型を参照する mediaType プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、メディア型として解釈されます）。これにより、保持者は既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される acceptedCryptosuites とは独立して MAY 使用できます。 acceptedEnvelopes 配列内の各項目は undefined: で MUST あります。

challenge [string]

リプレイ攻撃を防止することを意図して、要求者によって提供されるチャレンジ。通常、Verifiable Presentation 応答に含められることが期待されます。

domain [string]

リプレイ攻撃を防止することを意図して、要求者によって提供されるドメイン。通常、Verifiable Presentation 応答に含められることが期待されます。

interact [array]

サーバーがサポートするインタラクション・メカニズムのリスト。 interact 配列内の各項目は、以下の形式のオブジェクトで MUST あります:

service [object]

Verifiable Presentation Request への応答を受信できる、サーバーがサポートするサービス。これは以下の形式のオブジェクトで MUST あります:

type [array]: サービスの型。type 配列内の各項目は文字列で MUST あります。
serviceEndpoint [string]: Verifiable Presentation Request に応答する目的で、サービスとやり取りするために利用できる URL。

referenceId [string] サーバーが以前に referenceId を送信した場合、クライアントはデバッグとメッセージ相関を支援するために、ここにそれを含めるべきです（SHOULD）。値は urn:uuid 値であるべきです（SHOULD）。

プロパティ説明

プロパティ	説明
`verifiablePresentation` [object]	以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。`@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `@context` [array] クレデンシャルの JSON-LD コンテキスト。`@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか: `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。
`referenceId` [string]	サーバーが以前に referenceId を送信した場合、クライアントはデバッグとメッセージ相関を支援するために、ここにそれを含めるべきです（SHOULD）。値は urn:uuid 値であるべきです（SHOULD）。

verifiablePresentation [object]

以下の形式のオブジェクト:

@context [array]

提示の JSON-LD コンテキスト。@context 配列内の各項目は文字列で MUST あります。

id [string]

提示の ID。

type [array]

提示の JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

holder [object]

オブジェクト

verifiableCredential [array]

Verifiable Credentials。verifiableCredential 配列内の各項目は、以下の形式のオブジェクトで MUST あります:

@context [array]

クレデンシャルの JSON-LD コンテキスト。@context 配列内の各項目は文字列で MUST あります。

id [string]

クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。

type [array]

クレデンシャルの JSON-LD 型。type 配列内の各項目は文字列で MUST あります。

issuer [object]

文字列、または以下の形式のオブジェクトのいずれか:

id [string]: 発行者 ID。

validFrom [string]

validFrom の日付

validUntil [string]

validUntil の日付

credentialSubject [object]

オブジェクト

proof [object]

W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります:

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

proof [object]

W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります:

type [string]: Data Integrity Proof の型。
cryptosuite [string]: 暗号スイートの名前。
created [string]: 証明が作成された日付。
challenge [string]: 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。
domain [string]: 証明の使用を特定の対象に制限するための証明のドメイン。
nonce [string]: プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。
verificationMethod [string]: 証明を検証するために使用される検証メソッド。
proofPurpose [string]: verificationMethod とともに使用される証明の目的。
proofValue [string]: Linked Data 証明の値。

プロパティ	説明
`redirectUrl` [string]	クライアントは、別の関連する交換について、そのインタラクション URL から開始するクライアントになるようサーバーを招くため、redirectUrl としてインタラクション URL をサーバーへ送信しても MAY かまいません。サーバーはこの redirectUrl と関与しても MAY かまいません。
`referenceId` [string]	サーバーが以前に referenceId を送信した場合、クライアントはデバッグとメッセージ相関を支援するために、ここにそれを含めるべきです（SHOULD）。値は urn:uuid 値であるべきです（SHOULD）。

/workflows/{localWorkflowId}/exchanges/{localExchangeId} エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
200	交換が進行しました。 content-type: application/json 以下の形式のオブジェクト: `verifiablePresentationRequest` [object] Verifiable Presentation Request。これは以下の形式のオブジェクトで MUST あります: `query` [array] 要求者によって送信される 1 つ以上のクエリの集合。 `query` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `type` [array] クエリの型。`type` 配列内の各項目は文字列で MUST あります。 `credentialQuery` [object] QueryByExample クエリの場合、クレデンシャル要求の詳細を指定します。これは以下の形式のオブジェクトで MUST あります: `reason` [string] クレデンシャルが要求されている理由についての人間可読な説明。 `example` [object] オブジェクト `acceptedIssuers` [array] 要求されたクレデンシャルに対して受け入れられる発行者。 `acceptedIssuers` 配列内の各項目は以下の形式のオブジェクトで MUST あります: `issuer` [string] `acceptedCryptosuites` [array] 検証者が受け入れる暗号証明スイート。各要素は、 Data Integrity 暗号スイート名、またはレガシー用の `Ed25519Signature2020` を参照する `cryptosuite` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、暗号スイート名として解釈されます）。これにより、保持者は適切な証明形式を選択できます。このプロパティは、エンベロープされたクレデンシャルにのみ適用される `acceptedEnvelopes` とは独立して MAY 使用できます。 `acceptedCryptosuites` 配列内の各項目は undefined: で MUST あります。 `acceptedEnvelopes` [array] 検証者が受け入れるエンベロープ形式。各要素は、エンベロープ用のメディア型を参照する `mediaType` プロパティを持つオブジェクトで SHOULD あります（後方互換性のため、文字列値も MAY 使用でき、メディア型として解釈されます）。これにより、保持者は既定の Data Integrity 形式以外の形式でクレデンシャルを提供できます。このプロパティは、受け入れ可能な暗号スイートで署名された JSON-LD クレデンシャルにのみ適用される `acceptedCryptosuites` とは独立して MAY 使用できます。 `acceptedEnvelopes` 配列内の各項目は undefined: で MUST あります。 `challenge` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるチャレンジ。通常、Verifiable Presentation 応答に含められることが期待されます。 `domain` [string] リプレイ攻撃を防止することを意図して、要求者によって提供されるドメイン。通常、Verifiable Presentation 応答に含められることが期待されます。 `interact` [array] サーバーがサポートするインタラクション・メカニズムのリスト。 `interact` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `service` [object] Verifiable Presentation Request への応答を受信できる、サーバーがサポートするサービス。これは以下の形式のオブジェクトで MUST あります: `type` [array] サービスの型。`type` 配列内の各項目は文字列で MUST あります。 `serviceEndpoint` [string] Verifiable Presentation Request に応答する目的で、サービスとやり取りするために利用できる URL。 `referenceId` [string] 交換メッセージを相関させるための任意の識別子。サーバーはこの値を含めても MAY かまいません。存在する場合、クライアントは次のメッセージにそれを含める SHOULD です。値は urn:uuid 値である SHOULD です。または以下の形式のオブジェクト: `verifiablePresentation` [object] 以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。`@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。`verifiableCredential` 配列内の各項目は以下の形式のオブジェクトで MUST あります: `@context` [array] クレデンシャルの JSON-LD コンテキスト。`@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。`type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか: `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `referenceId` [string] 交換メッセージを相関させるための任意の識別子。サーバーはこの値を含めても MAY かまいません。存在する場合、クライアントは次のメッセージにそれを含める SHOULD です。値は urn:uuid 値である SHOULD です。以下の形式のオブジェクト: `redirectUrl` [string] 交換がクライアントをリダイレクトしたい URL。 `referenceId` [string] 交換メッセージを相関させるための任意の識別子。サーバーはこの値を含めても MAY かまいません。存在する場合、クライアントは次のメッセージがあれば、それに含める SHOULD です。値は urn:uuid 値である SHOULD です。交換を終了することをサーバーが望んでいることを示す、交換継続プロパティを持たない空のオブジェクト。これは以下の形式のオブジェクトで MUST あります: `referenceId` [string] 交換メッセージを相関させるための任意の識別子。サーバーはこの値を含めても MAY かまいません。存在する場合、送信する次のメッセージがあれば、クライアントはその次のメッセージにそれを含める SHOULD です。値は urn:uuid 値である SHOULD です。
400	無効な入力
401	認可されていません
500	内部エラー

GET /workflows/{localWorkflowId}/exchanges/{localExchangeId} - 既存の交換の状態を取得し、応答本文で返します。

/workflows/{localWorkflowId}/exchanges/{localExchangeId} エンドポイントは、GET を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
200	交換構成が取得されました! content-type: application/json アクティブな交換に関する情報を含むオブジェクト。指定された交換に送信する VP も redirectUrl もない場合、これは空のオブジェクトになることがあります。これは以下の形式のオブジェクトで MUST あります: `id` [string] 交換を識別するローカル交換 ID。 `sequence` [integer] 交換のシーケンス番号。作成時に 0 に設定されます。 `expires` [string] 交換が期限切れになる日時（XML Schema dateTimeStamp として表現される）。 `step` [string] 交換内の現在のステップ。 `state` [string] 交換の状態（"pending" \| "active" \| "complete" \| "invalid"）。作成時に "pending" に設定されます。 `lastError` [object] 以下の形式のオブジェクト: `type` [string] 問題の型を識別する URL。 `title` [string] 問題に関する短いが具体的な人間可読文字列。 `detail` [string] 問題に関するより長い人間可読文字列。 `variables` [object] 交換に必要な変数。これは以下の形式のオブジェクトで MUST あります: `results` [object] 交換の各ステップからの結果。これは以下の形式のオブジェクトで MUST あります: `STEP_NAME` [object] 交換のステップからの結果。これは以下の形式のオブジェクトで MUST あります: `verifiablePresentation` [object] 以下の形式のオブジェクト: `@context` [array] 提示の JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] 提示の ID。 `type` [array] 提示の JSON-LD 型。 `type` 配列内の各項目は文字列で MUST あります。 `holder` [object] オブジェクト `verifiableCredential` [array] Verifiable Credentials。 `verifiableCredential` 配列内の各項目は、以下の形式のオブジェクトで MUST あります: `@context` [array] クレデンシャルの JSON-LD コンテキスト。 `@context` 配列内の各項目は文字列で MUST あります。 `id` [string] クレデンシャルの ID。このプロパティは空で MAY あります。 Verifiable Credential は有効であるために id プロパティを必要とせず、 id プロパティを設定できないユースケースがあるため、発行者は、提供されていない場合に id プロパティを自動生成すべきではありません。 `type` [array] クレデンシャルの JSON-LD 型。 `type` 配列内の各項目は文字列で MUST あります。 `issuer` [object] 文字列、または以下の形式のオブジェクトのいずれか: `id` [string] 発行者 ID。 `validFrom` [string] validFrom の日付 `validUntil` [string] validUntil の日付 `credentialSubject` [object] オブジェクト `proof` [object] W3C VC Data Integrity 仕様で定義される Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `proof` [object] W3C VC Data Integrity 仕様で定義される、 challenge と domain を含む Data Integrity Proof。これは以下の形式のオブジェクトで MUST あります: `type` [string] Data Integrity Proof の型。 `cryptosuite` [string] 暗号スイートの名前。 `created` [string] 証明が作成された日付。 `challenge` [string] 認証証明のリプレイ攻撃を軽減するために検証者が選択した値。 `domain` [string] 証明の使用を特定の対象に制限するための証明のドメイン。 `nonce` [string] プライバシー目的で証明値をランダム化するために、証明の作成者が選択した値。 `verificationMethod` [string] 証明を検証するために使用される検証メソッド。 `proofPurpose` [string] verificationMethod とともに使用される証明の目的。 `proofValue` [string] Linked Data 証明の値。 `openId` [object] OID4VCI/OID4VP 保持者インタラクションからの結果。これは以下の形式のオブジェクトで MUST あります: `clientProfileId` [object] オブジェクト `authorizationResponse` [object] オブジェクト `presentationSubmission` [object] オブジェクト `inviteRequest` [object] 招待要求からの結果。これは以下の形式のオブジェクトで MUST あります: `inviteResponse` [object] 保持者をリダイレクトする場所を示す、招待要求への応答。これは以下の形式のオブジェクトで MUST あります: `url` [string] 交換を進めるべき URL。 `purpose` [string] インタラクションの説明。 `referenceId` [string] 招待要求の一意な ID。
400	無効な入力
401	認可されていません
500	内部エラー

POST /callbacks/{localCallbackId} - 交換ステップが実行されたときに通知を受けられる、任意のケイパビリティ URL（すなわち、推測が実行困難な URL）になり得るコールバック。この URL は、認可トークン、定期的なトークン更新、またはクライアント登録を必要とせずに、 URL が共有された当事者だけが使用できることを保証するため、ケイパビリティ URL である SHOULD です。提案された "localCallbackId" を含む URL 形式を使用する場合、 "localCallbackId" 値は、完全なコールバック URL をケイパビリティ URL として扱えることを保証するために、少なくとも 128 ビットのランダム情報を表現しなければなりません。また、交換ごとに新しいケイパビリティ URL を作成し、その交換でのみ使用することも推奨されます。

/callbacks/{localCallbackId} エンドポイントは、POST を受信する際に以下のスキーマを使用します:

プロパティ説明

プロパティ	説明
`event` [object]	コールバックに関連付けられたイベント情報。これは以下の形式のオブジェクトで MUST あります: `data` [object] コールバックに関連付けられたイベントデータ。これは以下の形式のオブジェクトで MUST あります: `exchangeId` [string] 交換の現在の状態を取得するために使用できる、交換状態への URL。

event [object]

コールバックに関連付けられたイベント情報。これは以下の形式のオブジェクトで MUST あります:

data [object]

コールバックに関連付けられたイベントデータ。これは以下の形式のオブジェクトで MUST あります:

exchangeId [string]: 交換の現在の状態を取得するために使用できる、交換状態への URL。

/callbacks/{localCallbackId} エンドポイントは、POST を受信する際に以下のいずれかの応答となる可能性があります:

応答	本文
200	コールバック・データを受信しました。
400	コールバック・データは受信されませんでした。

この仕様の API により、非仲介型（自動化された、マシン間）または仲介型（人間が関与する）交換を実行できます。これらの交換は、保持者コーディネーターによって開始され、交換を実装する任意のコーディネーターによって応答されます。フローは以下のステップで構成されます:

保持者コーディネーターが受信側コーディネーターに連絡し、特定の交換の開始を要求します。
受信側コーディネーターは、保持者コーディネーターを認証および／または認可するために、何らかの提示要求で応答し、交換内の次のホップを URL として提供します。
保持者コーディネーターは、提示要求を満たす情報を含む Verifiable Presentation で受信側コーディネーターに応答します。
受信側コーディネーターは、新しく発行された Verifiable Credentials を含む Verifiable Presentation、または上記ステップ 2 で表現されたさらなる提示要求で応答します。

保持者コーディネーターは、実際に交換を開始する前に、特定のエンドポイント上で保持者コーディネーターがコーディネーターのプロトコル要件をサポートするかどうかを判断するために、コーディネーターの交換発見エンドポイントを呼び出しても MAY かまいません。

上記で概説したステップの図を以下に示します:

注記

上記の一般的な交換は、完全に自動化された方法、人間によって仲介される方法、または一部は自動化されるが特定の段階で人間の介入が必要となるハイブリッドな方法で実行できます。上記の 2 番目のステップは、次のステップが自動化されているか、個人の介入を必要とするかについての指針を提供するために使用されます。

以下の図は、保持者コーディネーターが Verifiable Presentation Request で開始し、続行する前に受信側コーディネーターからのクレデンシャルを要求する交換を示しています:

図 5 保持者が続行する前に発行者/検証者からクレデンシャルを要求する、クライアント開始型の交換。

以下の図は、保持者コーディネーターがサーバーの最初の要求を受信した後に反対要求を送信する交換を示しています:

図 6 保持者がサーバーの最初の要求を受信した後に発行者/検証者からクレデンシャルを要求する、交換中の反対要求。

以下の例は、交換クライアントが、受け入れる暗号証明形式とエンベロープ型を指定する verifiablePresentationRequest を用いて交換を開始することを示します。 credentialQuery プロパティが存在しない場合、交換クライアントは、指定された形式に一致する、ワークフロー・サービスからの任意のクレデンシャルを受け入れます。

例 15: 受け入れ形式を伴うクライアント開始型交換

{
  "verifiablePresentationRequest": {
    "query": [{
      "type": "QueryByExample",
      "credentialQuery": {
        "acceptedCryptosuites": [
          {"cryptosuite": "eddsa-rdfc-2022"},
          {"cryptosuite": "ecdsa-rdfc-2019"},
          {"cryptosuite": "bbs-2023"}
        ],
        "acceptedEnvelopes": [
          {"mediaType": "application/jwt"}
        ]
      }
    }]
  }
}

以下の例は、交換クライアントが後続の要求を満たす前に、ワークフロー・サービスからクレデンシャルを要求することを示します。このシナリオでは、交換クライアントは、個人情報を共有する前に、サーバー運用者が登録済み事業者であることの証明を要求します。

例 16: 続行前にサーバー・クレデンシャルを要求するクライアント

{
  "verifiablePresentationRequest": {
    "query": [{
      "type": "QueryByExample",
      "credentialQuery": {
        "reason": "Please present your BusinessRegistrationCredential to complete the verification process.",
        "example": {
          "@context": [
            "https://www.w3.org/ns/credentials/v2"
          ],
          "type": ["BusinessRegistrationCredential"]
        },
        "acceptedCryptosuites": [
          {"cryptosuite": "eddsa-rdfc-2022"}
        ]
      }
    }]
  }
}

ある実装が、それとのインタラクションをどのように開始するかを別の実装へ伝達できることは有用です。このブートストラップ処理は、 インタラクションを開始すると呼ばれ、各実装がどのプロトコルをサポートするか、およびその実装との特定のインタラクションをどのように開始するかを伝達します。

注記: インタラクションは、アプリケーション、ユースケース、プロトコルに依存しません

この文書にはいくつかのインタラクション仕様が含まれていますが、一般的なアプローチは、ユースケース、アプリケーション、およびプロトコルに依存しません。このアプローチは、Web ブラウザー、QR コード（光学媒体）、または NFC（無線媒体）などの任意の伝送媒体を通じて、特定のプロトコルへブートストラップすることを望む 2 つ以上のアプリケーションをペアリングするために使用できます。そのプロトコルがこの API を含む必要はありません。

以下のシーケンス図は、発行者がインタラクション URL を生成し、QR コードを使用してそれを保持者と共有し、 vcapi プロトコルで進行することを概説しています:

以下のシーケンス図は、検証者がインタラクション URL を生成し、QR コードを使用してそれを保持者と共有し、 vcapi プロトコルで進行することを概説しています:

以下のシーケンス図は、保持者がインタラクション URL を生成し、 QR コードを使用してそれを検証者と共有し、 inviteRequest プロトコルで進行することを概説しています:

インタラクション URL の形式は、 URL Standard の構文に適合しなければ MUST ならず、インタラクション URL のバージョン番号を符号化する iuv クエリパラメーターを含まなければならず、この API のこのバージョンを使用する場合、その値は 1 でなければ MUST なりません。インタラクション URL は、インタラクション固有の識別子を含む HTTPS URL であるべき SHOULD です。URL は不透明であるべきであり、受信側システムによって取得される前に URL 構文処理を必要とすべきでは SHOULD ありません。そのような URL の例を以下に示します:

例 17: インタラクション URL

https://app.example/interactions/z8n38Dp7a?iuv=1

長いプロトコル固有情報を URL に符号化するプロトコルは、ソフトウェア・ライブラリによって URL の最大許容長に課される制限の影響を受けます。執筆時点では、推奨される URL 長の上限はおよそ 2,000 文字です。実装者は、Section 3.7.4 インタラクション・プロトコル応答で定義される、インタラクション URL に対する GET 要求への応答で表現できる情報を、インタラクション URL のクエリパラメーターに入れるべきでは SHOULD NOT ありません。

注記: インタラクション URL はワークフロー・サービスではなくコーディネーター上に存在します

コーディネーターは、消費側ソフトウェアによって（iuv クエリパラメーターを除き）不透明なものと見なされることが期待されるため、自身の Web オリジン上の任意の場所にインタラクション URL を配置する自由があります。ただし、インタラクション URL がコーディネーター上でホストされ、ワークフロー・サービスでホストされないことが重要です。これにより、コーディネーターの Web オリジン（DNS ドメイン名）を、消費者にとって一貫した信頼シグナルとして使用でき、アクションを調整する可能性のあるビジネスルールを適用できます。

インタラクション QR コードは、 ISO18004:2024: QR Code Bar Code Symbology Specification に従って QR コードとして表現されたインタラクション URL でなければ MUST なりません。広範な相互運用性を確保するために、インタラクション URL の長さは可能な限り短いべきであり SHOULD、400 英数字を超えるべきではなく SHOULD NOT、4,296 英数字を超えては MUST NOT なりません。インタラクション QR コードの例は以下で確認できます:

インタラクション URL を符号化している、
黒と白の点で埋められた正方形の画像 — 図 10 `https://app.example/interactions/z8n38Dp7a?iuv=1` のインタラクション QR コード

インタラクション URL を処理できるアプリケーションを呼び出せることは有用です。この節では、この目的のために interaction: プロトコル・スキーム形式を定義します。プロトコル・スキームの形式は、以下の構文に適合しなければ MUST なりません:

インタラクション・プロトコル・スキーム
scheme = "interaction:" interaction-url interaction-url = URL

interaction-url は、URL Standard に適合し、その URL にあるリソースを取得するとインタラクション・プロトコル応答となる任意の URL です。

例 18: インタラクション・スキーム URL の例

interaction:https://app.example/interactions/z8n38Dp7a?iuv=1

インタラクション URL を取得すると、リモート・システムとのインタラクションを開始する方法に関する指示が得られます。

インタラクション URL が application/json の Accept ヘッダーを使用して取得される場合、 protocols map を含む単一の JSON オブジェクトが返されなければ MUST ならず、各 key はプロトコル識別子であり、各 value はインタラクションを開始するために使用できる URL です。たとえば、 https://app.example/interactions/z8n38Dp7a?iuv=1 インタラクション URL に対して HTTP GET を実行すると、以下のいずれかの応答となる場合があります:

例 19: 指定されたインタラクションでサポートされるプロトコルのリスト。inviteRequest は使用中のワークフロー・サービスによって生成されます。

{
  "protocols": {
    "inviteRequest": "https://saas.example/workflows/123/exchanges/987/invite-request/response",
    "vcapi": "https://saas.example/workflows/123/exchanges/987",
    "OID4VP": "openid4vp://?client_id=https%3A%2F%2Fapp.example%2Fworkflows%2F123%2Fexchanges%2F987%2Fopenid%2Fclient%2Fauthorization%2Fresponse&request_uri=https%3A%2F%2Fapp.example%2Fworkflows%2F123%2Fexchanges%2F987%2Fopenid%2Fclient%2Fauthorization%2Frequest'"
  }
}

例 20: プロトコルのリストに inviteRequest オプションのみが含まれる退化ケース。

{
  "protocols": {
    "inviteRequest": "https://saas.example/interactions/123/invite-request/response"
  }
}

プロトコル応答により、交換プロトコルの取得節で説明されている委任メカニズムと同様に、HTTPS ドメイン信頼モデルを通じて、プロトコル実行を第三者サービス・プロバイダーに委任できます。たとえば、 Web サイト app.example は、プロトコルのリストに saas.example ドメインを含めることで、交換の運用をパートナー saas.example に委任できます。

インタラクション URL が認識されない Accept ヘッダーを使用して取得される場合、インタラクション URL の処理方法を理解する特定のソフトウェアを使用するよう人間に指示する説明を含む text/html 文書が返されなければ MUST なりません。

注記: 交換 URL へのマッピング

一部のコーディネーター実装は、プロトコル・エンドポイントを交換インスタンスのプロトコル・エンドポイントへのパススルーとして実装します。たとえば、 https://app.example/interactions/z8n38Dp7a?iuv=1 に対する GET は、 https://app.example/workflows/123/exchanges/987/protocols に対するパススルー GET となり、上記の応答を返すことがあります。この方法でインタラクション URL を実装すると、より容易な実装経路を提供できます。

inviteRequest インタラクション・プロトコルは、ローカル・システムがリモート・システムに対して、特定の URL を通じてリモート・システムへの招待を望んでいることを知らせるために使用されます。たとえば、個人がユースケース固有のインタラクションに参加できる Web サイトなどです。 inviteRequest インタラクション・プロトコルが選択された場合、ローカル・システムは HTTP POST を使用してデータを送信し、個人をどこへ送るべきかをリモート・システムに指示します。 POST データの例を 2 つ以下に示します。これらの例は、この仕様が "url" フィールドの形式についていかなる要件も述べていない一方で、このインタラクション・メカニズムの実装者に一意な ID を使用することを推奨している点を強調することを意図しています:

例 21: 店舗でチェックアウトするための招待要求への応答

{
  "url": "https://website.example/checkout/8372974",
  "purpose": "Checkout at ShopCo",
  "referenceId": "417bcaf2-14d9-11f0-99d7-9f094678517b"
}

例 22: オンラインフォームに入力するための招待要求への応答

{
  "url": "https://website.example/forms/7864165",
  "purpose": "Fill out online form",
  "referenceId": "d4a6e5b8-1715-4654-8e47-e68b311756d1"
}

vcapi インタラクション・プロトコルは、Section 3.6.5 交換への参加で説明されている、特定の交換を開始するために使用されます。

例 23: VC-API インタラクション・プロトコル要求

{
  "verifiablePresentationRequest": {
    "query": [{
      "type": "QueryByExample",
      "credentialQuery": {
        "reason": "Please provide your student ID.",
        "example": {
          "@context": [
            "https://www.w3.org/ns/credentials/v2",
            "https://www.w3.org/ns/credentials/examples/v2",
          ],
          "type": "StudentIdCredential",
          "credentialSubject": {
            "studentId": ""
          },
        },
        "trustedIssuer": [{
          "issuer": "did:web:university.example"
        }]
      }
    }],
    "challenge": "5e34826e-14da-11f0-98a5-8b1c0a196728",
    "domain": "university.example"
  }
}

実装が文書の処理中に異常を検出した場合、 ProblemDetails オブジェクトを使用して、その問題を他のソフトウェア・システムへ報告できます。これらのオブジェクトのインターフェイスは、データを符号化するために [RFC9457] に従います。ProblemDetails map は、以下のプロパティで構成されます:

type: type key は存在しなければ MUST ならず、その値は問題の型を識別する URL でなければ MUST なりません。
title: title key は、問題に関する短いが具体的な人間可読文字列を提供すべき SHOULD です。
detail: detail key は、問題に関するより長い人間可読文字列を提供すべき SHOULD です。

detail や instance などの key を活用して、エラーに関するより文脈的なフィードバックを提供することが推奨されます。ただし、セキュリティ上の懸念を意識し、機密情報を開示しないようにする必要があります。

この仕様では、以下の問題記述型を定義します:

https://www.w3.org/TR/vcalm#UNKNOWN_OPTION_PROVIDED: 実装が認識しないオプションが API 呼び出しに提供されました。

実装によって報告される可能性のある ProblemDetails のさらなるリストは、以下の仕様で確認できます:

第7.2節: Problem Details、Verifiable Credentials Data Model v2.0 仕様内。
第4.7節: Processing Errors、Verifiable Credential Data Integrity 1.0 仕様内。
第3.5節: Processing Errors、Bitstring Status List v1.0 仕様内。

例 24: ProblemDetails オブジェクトの例

{
  "type": "https://www.w3.org/TR/vc-data-model#CRYPTOGRAPHIC_SECURITY_ERROR",
  "status": 400,
  "title": "CRYPTOGRAPHIC_SECURITY_ERROR",
  "detail": "The cryptographic security mechanism couldn't be verified. This is likely due to a malformed proof or an invalid verificationMethod."
}

課題 3

上記の例の type URL は、VCDM v2.0 がグローバル標準になった後、将来的に機能するようになります。エラーが適切な場所にリンクすることを確実にするため、当面は https://www.w3.org/TR/vc-data-model のベース URL を www.w3.org/TR/vc-data-model-2.0 に置き換えることができます。

実装者は、本番環境におけるすべてのサーバー・エラーをサニタイズすることを強く推奨されます。そうしないと、情報漏えいにつながる可能性があります。

検証の実行中にエラーを発生させることは避け、代わりに検証結果に含める ProblemDetails オブジェクトを収集することが推奨されます。

この仕様は、検証エラーと検証警告の区別を定義します。エラーは、暗号、データモデル、および不正な形式のコンテキストに関連する ProblemDetails であり、回復不能です。警告は、ステータスと有効期間に関連する ProblemDetails であり、回復可能な場合があるか、または後続のアクションをアプリケーションの裁量に委ねる場合があります。

エラーが含まれる場合、VerificationResponse オブジェクトの verified プロパティは false に設定されなければ MUST ならず、エラーが含まれない場合は true に設定されなければ MUST なりません。

例 25: 警告とエラーを含む検証応答の例。

{
  "verified": false,
  "document": verifiableCredential,
  "mediaType": "application/vc",
  "controller": issuer,
  "controllerDocument": didDocument,
  "warnings": [ProblemDetails],
  "errors": [ProblemDetails]
}

プロパティ	説明
`credentialId` [string]	クレデンシャルを識別します（識別子は VC 自体に現れる必要はありません）。
`credentialStatus` [object]	更新する特定のステータスリスト・エントリーを識別します。これは以下の形式のオブジェクトでなければなりません（MUST）: `id` [string] `type` [string] `statusPurpose` [string] `statusListIndex` [string] `statusListCredential` [string]
`status` [boolean]	新しいステータスを指定します。
`indexAllocator` [string]	サービスが、どのインデックスが VC に使用／割り当てられているかを使用するためのもの。

プロパティ	説明
`statusPurpose` [string]	ステータスリストの目的（例: "revocation"、"suspension"）。これは、リストがどの種類のステータス情報を追跡するかを決定します。
`id` [string]	ステータスリストの任意の識別子。提供されない場合、サービスが生成します。
`options` [object]	オブジェクト

応答	本文
200	クレデンシャルのステータスが正常に更新されました
400	Bad Request
404	クレデンシャルが見つかりません

VCALM v1.0

ライフサイクル管理のための検証可能なクレデンシャル API

概要

この文書のステータス

1. はじめに

1.1 設計目標と根拠

HTTP API 設計ガイドライン

1.2 アーキテクチャの概要

1.3 適合性

1.4 用語

2. アーキテクチャ

2.1 コーディネーター

2.2 サービス

2.3 インスタンス

2.4 構成

ベース URL

認可

禁止された認可

OAuth 2.0

オプション

コンテンツのシリアライゼーション

ペイロードサイズ

3. HTTP API

3.1 コンポーネント概要

発行者コーディネーター

発行者サービス

検証者コーディネーター

検証者サービス

保持者コーディネーター

保持者サービス

ステータス・サービス

ワークフロー・サービス

3.2 発行

3.2.1 クレデンシャルの発行

3.2.2 特定のクレデンシャルの取得

3.2.3 特定の クレデンシャルの削除

3.3 検証

3.3.1 クレデンシャルの検証

3.3.2 提示の検証

3.3.3 チャレンジの作成

3.4 提示の要求

3.4.1 検証可能な 提示要求

3.4.2 例によるクエリ

3.4.3 DID 認証

3.4.3.1 DID 認証クエリ形式

3.4.3.2 DID 認証応答形式

3.4.4 認可 ケイパビリティ要求

3.4.5 クエリ内の論理演算

3.4.5.1 トップレベル クエリ（"AND" 演算）

3.4.5.2 ネストされたクエリ （"OR" 演算）

3.5 提示

3.5.1 クレデンシャルの導出

3.5.2 提示の作成

3.5.3 提示の取得

3.5.4 特定の 提示の取得

3.5.5 特定の 提示の削除

3.6 ワークフローと交換

3.6.1 ワークフローの作成

3.6.2 ワークフロー構成の取得

3.6.3 交換の作成

3.6.4 交換プロトコルの取得

3.6.5 交換への参加

3.6.6 交換状態の取得

3.6.7 交換ステップ・コールバック

3.6.8 交換の例

3.7 インタラクションの開始

3.7.1 インタラクション URL 形式

3.7.2 インタラクション QR コード形式

3.7.3 インタラクション・スキーム形式

3.7.4 インタラクション・プロトコル 応答

3.7.5 inviteRequest インタラクション・プロトコル

3.7.6 vcapi インタラクション・プロトコル

3.8 エラー処理

3.8.1 検証エラー と警告

A. プライバシーに関する考慮事項

A.1 委任

A.2 「Phoning Home」は 有害と見なされる

B. セキュリティに関する考慮事項

B.1 未知の証明型

B.2 インタラクション URL における HTTPS の使用

3.2.3 特定のクレデンシャルの削除

3.4.1 検証可能な提示要求

3.4.4 認可ケイパビリティ要求

3.4.5.1 トップレベルクエリ（"AND" 演算）

3.4.5.2 ネストされたクエリ（"OR" 演算）

3.5.4 特定の提示の取得

3.5.5 特定の提示の削除

3.7.4 インタラクション・プロトコル応答

3.7.5 `inviteRequest` インタラクション・プロトコル

3.7.6 `vcapi` インタラクション・プロトコル

3.8.1 検証エラーと警告

A.2 「Phoning Home」は有害と見なされる

D. ワークフロー・ステップとテンプレートの例

D.1 最小実用ステップおよびクレデンシャル・テンプレート

E. 他の仕様との関係