【注意】 このドキュメントは、W3CのVerifiable Credentials Data Model v1.1 W3C Recommendation 03 March 2022の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2023年1月31日
翻訳版も参照してください。
Copyright © 2022 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
資格証明は、我々の日常生活の一部となっています。運転免許証は自動車を運転する能力があることを言明するために用いられ、大学の学位は教育レベルを言明するために用いられ、政府発行のパスポートは国家間を移動することを可能にします。この仕様は、このような種類の資格証明を、暗号によって安全を確保し、プライバシーを尊重して、機械的に検証可能な方法でウェブで表現するメカニズムを提供します。
この項は、このドキュメントの公開時のステータスについて記述しています。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。
この仕様に関するコメントはいつでも歓迎しますが、この特定のバージョンのドキュメントに関するコメント期間は終了しており、ワーキンググループは現段階でこのバージョンの仕様に実質的な修正を加えることはありませんので、ご注意ください。課題は、GitHubに直接提出するか、public-vc-comments@w3.org (購読、アーカイブ)に送ってください。
ワーキンググループは、仕様の各規範的な機能に対して少なくとも2つの実装が存在することを示す実装のフィードバックを受け取っています。同グループ、は14の実装から報告を得ています。詳細は、テストスイートと実装報告書を参照してください。
このドキュメントは、検証可能な資格証明ワーキンググループ(Verifiable Credentials Working Group)が勧告トラックを用いて勧告として公開しました。
W3Cは、この仕様をウェブの標準として広く展開することを推奨します。
W3C勧告は、広範な合意形成の後、W3Cとそのメンバーの協賛を得、ワーキンググループのメンバーから、実装のためのロイヤルティ・フリーのライセンスを約束された仕様です。
このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
このドキュメントは、2021年11月2日のW3Cプロセス・ドキュメントによって管理されています。
この項は非規範的です。
資格証明は、我々の日常生活の一部となっています。運転免許証は自動車を運転する能力があることを言明するために用いられ、大学の学位は教育レベルを言明するために用いられ、政府発行のパスポートは国家間を移動することを可能にします。これらの資格証明は、物理的な世界で用いられる場合には我々に利益をもたらしますが、ウェブでの使用については、とらえどころのない状況が続いています。
現在、学歴、医療データ、金融取引情報など、第三者が検証した機械可読の個人情報をウェブで表現することは困難です。デジタルの資格証明をウェブ上で表現することが難しいため、物理的な世界において物理的な資格証明が我々に提供してくれるのと同じ利益をウェブを通じて受け取ることが困難になっています。
この仕様は、資格証明を、暗号によって安全を確保し、プライバシーを尊重して、機械的に検証可能な方法でウェブで表現するための標準的な方法を提供するものです。
検証可能な資格証明に関する概念に馴染みがない人のために、以下の項で概要を説明しています。
この項は非規範的です。
物理的な世界では、資格証明は次のもので構成されている場合があります。
検証可能な資格証明は、物理的な資格証明が表すものと同じ情報をすべて表すことができます。デジタル署名などの技術を追加することで、検証可能な資格証明は、その物理的な対応物よりも改ざんを防止し、より信頼できるものになります。
検証可能な資格証明の保有者は、検証可能なプレゼンテーションを生成し、その検証可能なプレゼンテーションを検証者と共有して、特定の特性を有する検証可能な資格証明を持っていることを証明できます。
検証可能な資格証明および検証可能なプレゼンテーションは、どちらも迅速に送信することができるため、離れた場所で信頼を確立しようとする場合に、物理的な対応物よりも便利です。
この仕様は、デジタル資格証明の表現の容易さを向上させることを試みる一方で、この目標と多くのプライバシー保全の目標とのバランスを取ることも試みています。デジタル情報の永続性、およびデジタル・データの様々な情報源を容易に収集し相関付けることができるということには、検証可能かつ容易に機械で読むことができる資格証明を用いるとプライバシーの懸念が悪化する恐れがあることが含まれます。このドキュメントでは、7. プライバシーに関する留意点でこれらの問題の多くについて概説し、対処を試みています。ゼロ知識証明など、プライバシーを強化する技術を使ってこのデータ・モデルを用いる方法の例も、このドキュメント全体を通して提供しています。
検証可能な資格証明および検証可能なプレゼンテーションという用語の「検証可能」 という語は、このドキュメントで定義しているように、検証者によって検証可能であるという資格証明またはプレゼンテーションの特性を意味します。資格証明の検証可能性は、そこにコード化されたクレームの真偽を評価できることを意味するものではありません。しかし、発行者は、evidenceプロパティーに値を含めることで、検証者が自身のビジネス・ロジックを適用し、必要なだけの真実性がクレームにあるかどうかを判断できるようにすることができます。
この項は非規範的です。
この項では、検証可能な資格証明が有用であると期待されるエコシステムにおける、中心的な関係者の役割とその関係性について説明します。役割は、多くの異なる方法で実装されうる抽象化です。役割の分離は、標準化の可能性が高いインターフェースとプロトコルを示唆します。この仕様では、次の役割を導入しています。
この項は非規範的です。
検証可能な資格証明ユースケース・ドキュメント[VC-USE-CASES]は、次のような有用と思われる多くの重要なトピックを概説しています。
ユースケース・ドキュメントを文書化し、分析した結果、この仕様について、次の望ましいエコシステムの特性が確認されました。
非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。
このドキュメントの「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである／する必要がある(SHOULD)」、というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。
適合ドキュメント(conforming document)は、この仕様の規範的なステートメントに準拠した、データ・モデルの具体的な表現です。具体的には、このドキュメントの4. 基本概念、5. 上級概念、および6. 構文の項のすべての関連する規範的なステートメントを実施しなければなりません(MUST)。適合ドキュメントのシリアル化フォーマットは、6. 構文の項に記述されているように、確定的、双方向的、およびロスレスでなければなりません(MUST)。適合ドキュメントは、そのような任意のシリアル化フォーマットで送信または保存できます(MAY)。
適合プロセッサ(conforming processor)は、ソフトウェアおよび/またはハードウェアとして実現される、適合ドキュメントを生成または利用するあらゆるアルゴリズムです。適合プロセッサは、非適合ドキュメントが利用されたときにエラーを出さなければなりません(MUST)。
この仕様は、発行者、保有者、検証者などのエコシステム内の役割の適合性に関して、規範的なステートメントを行いません。なぜなら、エコシステムの役割の適合性は、アプリケーション、ユースケース、および市場業界に極めて固有のものだからです。
デジタル証明のメカニズム(そのサブセットはデジタル署名である)は、検証可能な資格証明の保護を保証するために必要です。証明の構文に依存する可能性がある(例えば、鍵の保有者の証明に JSONウェブ・トークンの JSONウェブ署名を用いる)証明を有し、妥当性検証を行うことは、検証可能な資格証明を処理する上で不可欠な部分です。公開時点で、ワーキンググループのメンバーは、少なくとも次の3つの証明メカニズムを用いて検証可能な資格証明を実装していました。
実装者は、この仕様の公開日時点で、すべての証明メカニズムが標準化されているわけではないことに注意してください。このグループは、これらのメカニズムの一部と新しいメカニズムとが独立して成熟し、やがて標準化されることを期待しています。有効な証明メカニズムが複数存在することを考慮し、この仕様では単一のデジタル署名のメカニズムを標準化しません。この仕様の目標の1つは、現在および将来の様々なデジタル証明メカニズムで保護できるデータ・モデルを提供することです。この仕様への適合性は、特定の証明メカニズムの詳細に依存するものではなく、検証可能な資格証明が用いるメカニズムを明確に特定することが要求されます。
このドキュメントには、JSONおよびJSON-LDのコンテンツを含む例も含まれています。これらの例には、インライン・コメント(//)や、例の価値をほとんど高めることのない情報を示す省略記号(...)の使用など、無効なJSONである文字が含まれているものもあります。実装者がこの情報を有効なJSONやJSON-LDとして用いたい場合は、このコンテンツを削除するように注意してください。
この項は非規範的です。
この仕様では、次の用語を用いて概念を説明します。
did:example:123456abcdefです。この項は非規範的です。
以下の項では、この仕様の基礎を成すクレーム、資格証明、プレゼンテーションなどのコア・データ・モデルの概念について概説します。
この項は非規範的です。
クレームとは、サブジェクトに関するステートメントです。サブジェクトは、クレームを行うことができる対象となる事物です。クレームは、サブジェクト-プロパティー-値の関係で表されます。
上の図2で示しているクレームのデータ・モデルは強力で、多種多様なステートメントを表現できます。例えば、ある者が特定の大学を卒業したかどうかは、下の図3のように表現できます。
個々のクレームを結合して、サブジェクトに関する情報のグラフを表現できます。下の図4で示している例では、PatがSamを知っているというクレームと、Samが教授として雇われているというクレームを追加することで、前のクレームを拡張しています。
これまでに、クレームと情報のグラフの概念を紹介しました。クレームを信頼できるものにするためには、グラフにさらに情報を追加することが期待されます。
この項は非規範的です。
資格証明は、同じエンティティーが行う1つ以上のクレームの集合です。資格証明には、発行者、有効期限の日時、代表的な画像、検証を目的として用いる公開鍵、失効メカニズムなど、資格証明のプロパティーを記述するための識別子やメタデータも含まれる場合があります。メタデータは、発行者が署名している場合があります。検証可能な資格証明は、誰がそれを発行したかを暗号によって証明する、改ざんを防止するクレームとメタデータの集合です。
検証可能な資格証明の例としては、デジタル社員証、デジタル出生証明書、デジタル教育証明書などがあります。
多くの場合、資格証明の識別子は、資格証明の特定のインスタンスを識別するために用いられます。この識別子は、相関関係にも使用できます。相関関係を最小限に抑えたい保有者は、資格証明の識別子を明さない選択的開示スキームを用いることをお勧めします。
上の図5は、検証可能な資格証明の基本構成要素を表していますが、クレームが情報グラフに編成され、その後で検証可能な資格証明へと編成される方法の詳細を抽象化しています。下の図6は、検証可能な資格証明をより完全に描写したもので、通常、少なくとも2つの情報グラフで構成されます。最初のグラフは、検証可能な資格証明自体を表しており、資格証明メタデータとクレームが含まれています。2番目のグラフは、デジタル証明を表しており、これは通常、デジタル署名です。
この項は非規範的です。
プライバシーの強化は、この仕様の設計上の重要な特徴です。したがって、この技術を用いるエンティティーが、特定の状況に適した人物像(persona)の部分のみを表現できることが重要です。自身の人物像のサブセットを表現することを、検証可能なプレゼンテーションと呼びます。様々な人物像の例としては、職業上の人物像、オンライン・ゲーム上の人物像、家族としての人物像、匿名の人物像などがあります。
検証可能なプレゼンテーションは、1つ以上の検証可能な資格証明のデータを表し、データの原作者が検証可能な方法でパッケージ化されています。検証可能な資格証明が直接提示されれば、それは検証可能なプレゼンテーションになります。暗号によって検証できる検証可能な資格証明から派生したデータ・フォーマットだけれども、それ自体に検証可能な資格証明が含まれていないものも、検証可能なプレゼンテーションでありえます。
プレゼンテーション内のデータは多くの場合、同じサブジェクトに関するものですが、複数の発行者によって発行された可能性があります。この情報の集約は通常、人、組織、またはエンティティーの一面を表します。
上の図7は、検証可能なプレゼンテーションの構成要素を表していますが、検証可能な資格証明が情報グラフに編成され、その後に検証可能なプレゼンテーションへと編成される方法の詳細を抽象化しています。
下の図8は、検証可能なプレゼンテーションをより完全に描写したもので、通常、少なくとも4つの情報グラフで構成されています。このうち最初の情報グラフであるプレゼンテーション・グラフは、検証可能なプレゼンテーション自体を表しており、プレゼンテーション・メタデータが含まれています。プレゼンテーション・グラフ内のverifiableCredentialプロパティーは、1つ以上の検証可能な資格証明を参照し、それぞれが2番目の情報グラフの1つ、すなわち自己完結型の資格証明グラフであり、これには資格証明メタデータとクレームが含まれています。3番目の情報グラフである資格証明証明グラフは、資格証明グラフ証明を表し、これは通常、デジタル署名です。4番目の情報グラフであるプレゼンテーション証明グラフは、プレゼンテーション・グラフ証明を表し、これは通常、デジタル署名です。
この項は非規範的です。
以前の項では、グラフィカルな描写を用いて、クレーム、検証可能な証明、検証可能なプレゼンテーションの概念を紹介しました。この項では、この仕様でサポートしている具体的な構文の1つで表されるデータ・モデルのシンプルながらも完全なライフサイクルの具体例を提供します。検証可能な資格証明エコシステムにおける資格証明およびプレゼンテーションのライフサイクルは多くの場合、共通する道を進みます。
このライフサイクルについて説明するために、大学の卒業生割引を利用するという例を用います。下の例では、Patは、大学から卒業生の検証可能な資格証明を受け取り、その検証可能な資格証明をデジタル・ウォレットに保存します。
{
// 「issuer」や「alumniOf」など、用いる特別な用語を規定する
// コンテキストを設定
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
// 資格証明の識別子を指定
"id": "http://example.edu/credentials/1872",
// 資格証明の期待されるデータを宣言する資格証明の型
"type": ["VerifiableCredential", "AlumniCredential"],
// 資格証明を発行したエンティティー
"issuer": "https://example.edu/issuers/565049",
// 資格証明が発行された時刻
"issuanceDate": "2010-01-01T19:23:24Z",
// 資格証明のサブジェクトに関するクレーム
"credentialSubject": {
// 資格証明の唯一のサブジェクトの識別子
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
// 資格証明の唯一のサブジェクトに関する言明
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Universite",
"lang": "fr"
}]
}
},
// 資格証明の改ざんを防止するデジタル証明
// 詳細については、この項の最後の注を参照
"proof": {
// 署名の生成に用いられた暗号署名スイート
"type": "RsaSignature2018",
// 署名の作成日
"created": "2017-06-18T21:19:10Z",
// この証明の目的
"proofPurpose": "assertionMethod",
// 署名を検証できる公開鍵の識別子
"verificationMethod": "https://example.edu/issuers/565049#key-1",
// デジタル署名の値
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}
次に、Patは、卒業生割引を利用しようとします。検証者であるチケット販売システムは、「Example大学」の卒業生はスポーツ・イベントのシーズン・チケットの割引を受けられることを示します。Patは、携帯機器を用いて、シーズン・チケットの購入手続きを開始します。この手続きのステップでは、卒業生の検証可能な資格証明が要求され、この要求はPatのデジタル・ウォレットに転送されます。デジタル・ウォレットは、以前に発行された検証可能な資格証明を提供するかどうかをPatに尋ねます。Patは卒業生の検証可能な資格証明を選択し、その後、それは検証可能なプレゼンテーションとなります。その検証可能なプレゼンテーションは検証者に送信され、検証が行われます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
// 前の例で発行された検証可能な資格証明
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Universite",
"lang": "fr"
}]
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/565049#key-1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}],
// プレゼンテーションへのPatによる
// デジタル署名がリプレイ攻撃から守る
"proof": {
"type": "RsaSignature2018",
"created": "2018-09-14T21:19:10Z",
"proofPurpose": "authentication",
"verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
// 「challenge」と「domain」がリプレイ攻撃から保護する
"challenge": "1f44d55f-f161-4938-a659-f8026467f126",
"domain": "4jt78h47fh47",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
4vGHSrQyHUGlcTwLtjPAnKb78"
}
}
上記で用いたproofメカニズムについて理解を深めることに関心のある実装者は、4.7 証明(署名)の項や、データ完全性[DATA-INTEGRITY]、リンクト・データ暗号スイート・レジストリ[LDP-REGISTRY]、および JSONウェブ署名(JWS)エンコードされていないペイロード・オプション[RFC7797]の仕様を読むことで詳細を学ぶことができます。証明メカニズムの一覧は、検証可能な資格証明拡張レジストリ[VC-EXTENSION-REGISTRY]にあります。
この項では、このドキュメントで後述する5. 高度な概念に備えて、この仕様の基本概念をいくつか紹介します。
2つのソフトウェア・システムがデータ交換を行う必要がある場合、両方のシステムが理解できる用語を用いる必要があります。例えとして、2人の人間がどのようにコミュニケーションをとるかを考えてみましょう。2人は同じ言語を用い、彼らが使用する言葉はお互いに同じ意味でなければなりません。これは、会話の文脈(context of a conversation)と呼ばれることがあります。
検証可能な資格証明および検証可能なプレゼンテーションは、URI[RFC3986]で識別される多くの属性と値を備えています。しかし、このURIは長く、人間にはあまり分かりやすくない可能性があります。そのような場合には、短い形式の人間に分かりやすいエイリアスのほうが役立つ可能性があります。この仕様では、@contextプロパティーを用いて、そのような短い形式のエイリアスを、特定の検証可能な資格証明および検証可能なプレゼンテーションに必要なURIにマッピングします。
JSON-LDでは、@contextプロパティーを用いて、データ型情報、言語情報、変換規則などの他の詳細を伝えることもでき、これらは、この仕様のニーズを超えていますが、将来または関連する取り組みにおいて役に立つ可能性があります。詳細については、[JSON-LD]仕様の3.1: コンテキストの項を参照してください。
検証可能な資格証明および検証可能なプレゼンテーションには、@contextプロパティーを含まなければなりません(MUST)。
@contextプロパティーの値は、最初の項目がhttps://www.w3.org/2018/credentials/v1という値のURIである順序付き集合でなければなりません(MUST)。参考のために、ベース・コンテキストのコピーを付録B.1 ベース・コンテキストで提供しています。配列内のその後の項目は、コンテキスト情報を表し、URIまたはオブジェクトの任意の組み合わせで構成されなければなりません(MUST)。@context内の個々のURIは、逆参照すると、その@contextに関する機械可読情報を含むドキュメントになるものであることが推奨されます(RECOMMENDED)。この仕様では、@contextプロパティーの存在を必須としていますが、@contextプロパティーの値をJSON-LDを用いて処理することは必須としていません。これは、検証可能な資格証明がJWTとしてエンコードされている場合に用いられる可能性のあるものなど、プレーンなJSONライブラリを用いた処理をサポートするためです。すべてのライブラリまたはプロセッサは、@contextプロパティー内の値の順序が、特定のアプリケーションで期待されるものであることを保証しなければなりません(MUST)。JSON-LD をサポートするライブラリやプロセッサは、期待どおりに完全なJSON-LD処理を用いて@contextプロパティーを処理することができます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/58473",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Universite",
"lang": "fr"
}]
}
},
"proof": { ... }
}
上の例では、ベース・コンテキストURI(https://www.w3.org/2018/credentials/v1)を用いて、会話が検証可能な資格証明に関するものであることを確立しています。2番目のURI(https://www.w3.org/2018/credentials/examples/v1)は、会話が例に関するものであることを確立しています。
このドキュメントでは、例を示すという目的でコンテキストURIの例(https://www.w3.org/2018/credentials/examples/v1)を用いています。実装では、パイロット・システムや実稼働システムなど、他の目的でこのURIを用いないことが期待されます。
https://www.w3.org/2018/credentials/v1で利用できるデータは、更新されることのない静的なドキュメントであり、ダウンロードしてキャッシュすべきです(SHOULD)。検証可能な資格証明データ・モデルに関連する人間が読める語彙ドキュメントは、https://www.w3.org/2018/credentials/にあります。この概念は、5.3 拡張性の項でさらに展開しています。
人、製品、組織など、特定の事物についてのステートメントを表す場合、他の人が同じ事物についてステートメントを表すことができるように、何らかの識別子を用いると有用である場合が多くあります。この仕様では、そのような識別子のためにオプションのidプロパティーを定義しています。idプロパティーは、人、製品、組織などのオブジェクトを明確に参照するためのものです。idプロパティーを用いると、検証可能な資格証明で特定の事物に関するステートメントを表すことができるようになります。
idプロパティーが存在する場合、
idプロパティーは、その識別子によって識別される特定の事物に関するステートメントを表す際に、他者が用いることが期待される識別子を表さなければなりません(MUST)。idプロパティーには、複数の値があってはなりません(MUST NOT)。idプロパティーの値は、URIでなければなりません(MUST)。開発者は、仮名性が必要なシナリオでは識別子が有害である場合があることを覚えておくべきです。開発者は、そのようなシナリオを検討する場合には、7.3 識別子に基づく相関関係の項を注意深く読むことをお勧めします。また、7. プライバシーに関する留意点で説明している、プライバシーに関する懸念を生じさせる他の種類の相関関係メカニズムもあります。プライバシーが強い留意事項となる場合は、idプロパティーを省略することができます(MAY)。
idプロパティーの値は、1つのURIでなければなりません(MUST)。id内のURIは、逆参照すると、そのidに関する機械可読情報を含むドキュメントになるものであることが推奨されます(RECOMMENDED)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
上の例では、2種類の識別子を用いています。最初の識別子は、検証可能な資格証明に対するもので、HTTPベースのURLを用いています。2番目の識別子は、検証可能な資格証明のサブジェクト(クレームの対象)に対するもので、DIDとも呼ばれる分散型識別子を用いています。
このドキュメントで指定している種類のオブジェクトを処理するソフトウェア・システムは、型情報を用いて、提供された検証可能な資格証明または検証可能なプレゼンテーションが適切かどうかを判断します。この仕様では、型情報を表すためにtypeプロパティーを定義しています。
検証可能な資格証明および検証可能なプレゼンテーションには、typeプロパティーがなければなりません(MUST)。つまり、typeプロパティーがない資格証明またはプレゼンテーションは、検証可能ではないため、検証可能な資格証明でも検証可能なプレゼンテーションでもありません。
typeプロパティーの値は、1つ以上のURIであるか、(@contextプロパティーの解釈によって)URIにマッピングされていなければなりません(MUST)。複数のURIが提供されている場合、そのURIは順不同の集合として解釈されなければなりません(MUST)。開発者が使いやすいように、構文的に便利な機能を用いるべきです(SHOULD)。そのような便利な機能には、JSON-LDの用語が含まれるかもしれません。type内の個々のURIは、逆参照すると、そのtypeに関する機械可読情報を含むドキュメントになるものであることが推奨されます(RECOMMENDED)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
この仕様に関して、型を指定しなければならない(MUST)オブジェクトの一覧を次の表で示します。
| オブジェクト | 型 |
|---|---|
| 検証可能な資格証明オブジェクト (資格証明オブジェクトのサブクラス) |
VerifiableCredential、およびオプションでより具体的な検証可能な資格証明の型。例えば、"type": ["VerifiableCredential", "UniversityDegreeCredential"] |
| 資格証明オブジェクト | VerifiableCredential、およびオプションでより具体的な検証可能な資格証明の型。例えば、"type": ["VerifiableCredential", "UniversityDegreeCredential"] |
| 検証可能なプレゼンテーション・オブジェクト (プレゼンテーション・オブジェクトのサブクラス) |
VerifiablePresentation、およびオプションでより具体的な検証可能なプレゼンテーションの型。例えば、"type": ["VerifiablePresentation", "CredentialManagerPresentation"] |
| プレゼンテーション・オブジェクト | VerifiablePresentation、およびオプションでより具体的な検証可能なプレゼンテーションの型。例えば、"type": ["VerifiablePresentation", "CredentialManagerPresentation"] |
| 証明オブジェクト | 有効な証明の型。例えば、"type": "RsaSignature2018" |
| credentialStatus(資格証明ステータス)オブジェクト | 有効な資格証明ステータスの型。例えば、"type": "CredentialStatusList2017" |
| termsOfUse(使用条件)オブジェクト | 有効な使用条件の型。例えば、"type": "OdrlPolicy2017" |
| 証拠オブジェクト | 有効な証拠の型。例えば、"type": "DocumentVerification2018" |
検証可能な証明データ・モデルの型システムは、[JSON-LD]のものと同じであり、5.4項: 型の指定および8項: JSON-LD文法で詳細に説明しています。JSON-LDコンテキストを用いる場合(5.3項 拡張性を参照)、この仕様は、JSON-LDドキュメントをより容易に理解できるように@typeキーワードをtypeにエイリアスしています。アプリケーション開発者とドキュメント作成者は、JSON-LDの型システムの詳細を理解する必要はありませんが、相互運用可能な拡張性をサポートしたいこの仕様の実装者は理解する必要があります。
すべての資格証明、プレゼンテーション、およびカプセル化されたオブジェクトは、より狭い追加の型(例えば、UniversityDegreeCredentialなど)を指定するか、それに関連付けて、ソフトウェア・システムがこの追加情報を処理できるようにしなければなりません(MUST)。
この仕様が定義しているカプセル化されたオブジェクト(例えば、credentialSubject(資格証明サブジェクト)オブジェクトに関連付けられているオブジェクトやそこに深く入れ子にされているオブジェクト)を処理する場合、ソフトウェア・システムは階層内の上位にあるカプセル化されたオブジェクトで指定されている型情報を用いるべきです(SHOULD)。具体的には、資格証明などのカプセル化されたオブジェクトは、検証者がカプセル化されたオブジェクトの型に基づいて関連オブジェクトの内容を迅速に判断できるように、関連付けられているオブジェクトの型を伝えるべきです(SHOULD)。
例えば、UniversityDegreeCredential(大学の学位証明)というtypeを持つ資格証明オブジェクトは、credentialSubject(資格証明サブジェクト)プロパティーに関連付けられているオブジェクトに次のものに対する識別子が含まれていることを検証者に知らせます。
idプロパティー内のサブジェクト。typeプロパティー内の学位の型。nameプロパティー内の学位の称号。これにより、実装者は検証の目的で、typeプロパティーに関連付けられている値に依存することができます。型とそれに関連付けられているプロパティーの見込みは、少なくとも人間が読める仕様で、できればさらに機械可読表現でも文書化されるべきです。
この仕様で説明しているデータ・モデルで用いる型システムにより、複数の方法で型とデータを関連付けることができます。実装者と作成者は、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]の型付けに関する項を読むことをお勧めします。
検証可能な資格証明には、1つ以上のサブジェクトに関するクレームが含まれます。この仕様では、1つ以上のサブジェクトに関するクレームを表すためにcredentialSubject(資格証明サブジェクト)プロパティーを定義しています。
検証可能な資格証明には、credentialSubjectプロパティーがなければなりません(MUST)。
credentialSubjectプロパティーの値は、検証可能な資格証明のサブジェクトにそれぞれ関連する1つ以上のプロパティーを含むオブジェクトの集合として定義されます。個々のオブジェクトには、4.2項 識別子で説明しているように、idを含むことができます(MAY)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
検証可能な資格証明では、複数のサブジェクトに関する情報を表すことができます。次の例では、配偶者である2人のサブジェクトを指定しています。配列表記法を用いて、複数のサブジェクトをcredentialSubjectプロパティーと関連付けていることに注意してください。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "https://example.com/issuer/123",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Jayden Doe",
"spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"
}, {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Morgan Doe",
"spouse": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}]
}
この仕様では、検証可能な資格証明の発行者を表すためにプロパティーを定義しています。
検証可能な資格証明には、issuerプロパティーがなければなりません(MUST)。
issuerプロパティーの値は、URIまたはidプロパティーを含むオブジェクトでなければなりません(MUST)。issuerまたはそのid内のURIは、逆参照すると、資格証明で表された情報を検証するために使用できる発行者に関する機械可読情報を含むドキュメントになるものであることが推奨されます(RECOMMENDED)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
また、オブジェクトをissuerプロパティーに関連付けることで、発行者に関する付加的な情報を表すこともできます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Example University"
},
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
この仕様では、資格証明が有効になる日時を表すためにissuanceDateプロパティーを定義しています。
issuanceDateプロパティーがなければなりません(MUST)。issuanceDateプロパティーの値は、資格証明が有効になる日時を表す[XMLSCHEMA11-2]の結合型date-time文字列値でなければならず(MUST )、これは、将来の日時でありえます。この値は、credentialSubjectプロパティーに関連付けられている情報が有効になる最も早い時点を表すことに注意してください。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
この仕様の次のバージョンでは、validFromプロパティーを追加し、issuanceDateプロパティーを廃止して新しいissuedプロパティーを採用する予定です。両プロパティーの値の範囲は、[XMLSCHEMA11-2]の結合型date-time文字列のままであると予想されます。実装者は、validFromとissuedのプロパティーは予約されており、他の目的で用いないことをお勧めします。
資格証明またはプレゼンテーションが検証可能な資格証明または検証可能なプレゼンテーションである、つまり、検証可能であるためには、少なくとも1つの証明メカニズムとその証明を評価するために必要な詳細が表現されていなければなりません(MUST)。
この仕様では、外部証明と組み込み証明という2つのクラスの証明メカニズムを識別します。外部証明は、JSONウェブ・トークンなどの、このデータ・モデルの表現をラップするもので、これについては、6.3.1 JSONウェブ・トークンの項で詳細に説明しています。組み込み証明は、リンクト・データ署名などの、証明をデータに含む仕組みで、これについては、6.3.2 データ完全性証明の項で詳細に説明しています。
証明を組み込む場合、proofプロパティーを用いなければなりません(MUST)。
typeプロパティーを用いて含めなければなりません(MUST)。数学的証明に用いるメソッドは、用いる表現言語や技術によって異なるため、proofプロパティーの値として予期される名前-値の対の集合は、それに応じて変わります。例えば、証明のメカニズムにデジタル署名を用いる場合、proofプロパティーには、署名、署名エンティティーへの参照、署名日時の表現を含む名前-値の対が含まれていることが期待されます。次の例では、RSAデジタル署名を用いています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2021-11-13T18:19:39Z",
"verificationMethod": "https://example.edu/issuers/14#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdo
WhAfGFCF5bppETSTojQCrfFPP2oumHKtz"
}
}
1.4 適合性の項で説明したように、実行可能な証明メカニズムは複数あり、この仕様では、検証可能な資格証明で用いる単一の証明メカニズムを標準化することも、推奨することもしません。proofメカニズムの詳細については、データ完全性[DATA-INTEGRITY]、リンクト・データ暗号スイート・レジストリ[LDP-REGISTRY]、JSONウェブ署名(JWS)エンコードされていないペイロード・オプション[RFC7797]の仕様を参照してください。証明メカニズムの一覧は、検証可能な資格証明拡張レジストリ[VC-EXTENSION-REGISTRY]にあります。
この仕様では、資格証明の有効期限情報を表すためにexpirationDateプロパティーを定義しています。
expirationDateプロパティーの値は、資格証明が有効でなくなる日時を表す[XMLSCHEMA11-2]のdate-timeの文字列値でなければなりません(MUST)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"expirationDate": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
この仕様では、停止や失効の有無など、検証可能な資格証明の現在のステータスに関する情報を発見するために次のcredentialStatusプロパティーを定義しています。
credentialStatusプロパティーの値には次が含まれていなければなりません(MUST)。
資格証明ステータス情報の正確な内容は、特定のcredentialStatus型の定義によって決まり、実装が容易かどうか、プライバシーを強化するのかどうかなどの要因によって異なります。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"credentialStatus": {
"id": "https://example.edu/status/24",
"type": "CredentialStatusList2017"
}
}
ステータス・スキームのデータ・モデル、フォーマットおよびプロトコルの定義は、この仕様の範囲外です。検証可能な資格証明のステータス・チェックを実装したい実装者向けに、利用可能なステータ ス・スキームが含まれている検証可能な資格証明拡張レジストリ[VC-EXTENSION-REGISTRY]が存在しています。
プレゼンテーションは、資格証明を結合して提示するために使用できます(MAY)。これは、データの原作者を検証可能な方法でパッケージ化することができます。多くの場合、プレゼンテーション内のデータはすべて同じサブジェクトに関するものですが、データ内のサブジェクトや発行者の数に制限はありません。複数の検証可能な資格証明からの情報の集約は、検証可能なプレゼンテーションの典型的な使用方法です。
検証可能なプレゼンテーションは通常、次のプロパティーで構成されます。
idプロパティーはオプションであり、プレゼンテーションに一意な識別子を提供するために使用できます(MAY)。このプロパティーの使用に関する詳細については、4.2 識別子の項を参照してください。typeプロパティーは必須であり、VerifiablePresentation(検証可能なプレゼンテーション)などのプレゼンテーションの型を表します。このプロパティーの使用に関する詳細については、4.3 型の項を参照してください。verifiableCredentialプロパティーの値は、1つ以上の検証可能な資格証明、または暗号によって検証可能な形式の検証可能な資格証明から派生したデータから構築されなければなりません(MUST)。holderプロパティーの値は、プレゼンテーションを生成しているエンティティーのURIであることが期待されます。proofプロパティーの値は、プレゼンテーションが検証可能であることを保証します。このプロパティーの使用に関する詳細については、4.7 証明(署名)の項を参照してください。次の例は、検証可能な資格証明を組み込んだ検証可能なプレゼンテーションを示しています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
"type": ["VerifiablePresentation", "CredentialManagerPresentation"],
"verifiableCredential": [{ ... }],
"proof": [{ ... }]
}
上に示したverifiableCredentialプロパティーの内容は、この仕様で説明しているように、検証可能な資格証明です。データ完全性[DATA-INTEGRITY]仕様で記述されているように、proofプロパティーの内容は証明です。JWT証明メカニズムを用いた検証可能なプレゼンテーションの例は、6.3.1 JSONウェブ・トークンの項で示しています。
ゼロ知識暗号スキームの中には、検証可能な資格証明自体を明かすことなく、保有者が検証可能な資格証明からのクレームを保有していることを間接的に証明することができるものがあります。このスキームでは、検証可能な資格証明からのクレームを用いて提示される値を導き出すことができ、これは、検証者が発行者を信頼すればその値を信頼できるように、暗号によって言明されます。
例えば、date of birth(生年月日)というクレームを含む検証可能な資格証明を用いて、暗号によって検証可能な方法でover the age of 15(15歳以上)という提示された値を導き出す場合があります。つまり、検証者は、発行者を信頼すれば、派生した値を依然として信頼することができます。
検証可能な資格証明を直接組み込む代わりに派生データを含むZKPスタイルの検証可能なプレゼンテーションの例については、5.8 ゼロ知識証明の項を参照してください。
ゼロ知識証明を用いる選択的開示スキームは、このモデルで表現されたクレームを用いて、 そのクレームに関する追加のステートメントを証明することができます。例えば、サブジェクトの生年月日を指定するクレームを述語として用いて、サブジェクトの年齢が所定の範囲内にあることを証明し、したがって、サブジェクトの生年月日を実際に明かすことなく、サブジェクトが年齢に関する割引を受ける資格があることを証明することができます。保有者は、希望する検証可能なプレゼンテーションに適用できる任意の方法でクレームを柔軟に用いることができます。
この項では、4. 基本概念の項で紹介した概念に基づいて、検証可能な資格証明に関するより複雑なトピックについて説明します。
この項は非規範的です。
1.2 エコシステムの概要の項で検証可能な資格証明エコシステムの概要を説明しました。この項では、エコシステムがどのように機能すると想定されているかについて、より詳細に説明します。
検証可能な資格証明エコシステムにおける役割と情報の流れは、次のとおりです。
上記の動作の順序は固定されておらず、一部の動作は複数回実行される可能性があります。このような動作の繰り返しは、即時であるかもしれないし、後の時点であるかもしれません。
最も一般的な一連の動作は、次のように想定されています。
この仕様は、検証可能な資格証明または検証可能なプレゼンテーションを転送するためのプロトコルを定義していませんが、他の仕様がエンティティー間で転送する方法を指定していると仮定すると、この検証可能な資格証明データ・モデルを直接適用することができます。
また、この仕様は、承認の枠組みも、検証可能な資格証明または検証可能なプレゼンテーションを検証した後に、検証者が保持者、検証可能な資格証明の発行者、検証可能な資格証明の内容、および独自の方針を考慮して行う可能性がある決定についても定義していません。
特に、5.6 使用条件とC. サブジェクトと保有者の関係の項では、検証者が次の点についてどのように判断できるかを規定しています。
この項は非規範的です。
検証可能な資格証明の信頼モデルは次のとおりです。
この信頼モデルは、次の点を保証することにより、他の信頼モデルと差別化されます。
IDの提供者と証明書利用者との間の信頼を分離させることにより、より柔軟で動的な信頼モデルが構築され、市場競争と顧客の選択肢が増大します。
この信頼モデルが、ワーキンググループが調査した様々な脅威モデルとインタラクションを行う方法の詳細については、検証可能な資格証明ユースケース・ドキュメント[VC-USE-CASES]を参照してください。
この仕様で詳細に説明しているデータ・モデルは、従来の認証局の信頼モデルで提供されているような推移的な信頼モデルを意味するものではありません。検証可能な資格証明データ・モデルでは、検証者は発行者を直接信頼するか、しないかのいずれかです。検証可能な資格証明データ・モデルを用いて推移的な信頼モデルを構築することは可能ですが、実装者は、認証局システムで採用されている方法で信頼を広く委譲することによってもたらされるセキュリティの弱点について学ぶことをお勧めします。
検証可能な資格証明データ・モデルの目標の1つは、無許可のイノベーション(permissionless innovation)を可能にすることです。これを達成するには、データ・モデルを様々な方法で拡張できる必要があります。データ・モデルは次のことを行う必要があります。
このデータ・モデリングに対するアプローチはしばしば、開世界仮説と呼ばれ、任意のエンティティーが他の任意のエンティティーについて何でも言えることを意味します。このアプローチは、シンプルで予測可能なソフトウェア・システムの構築と矛盾するように見えますが、拡張性とプログラムの正確さのバランスをとることは、閉じたソフトウェア・システムよりも開世界仮説の方が常に困難です。
この項の残りの部分では、一連の例を通して、拡張性とプログラムの正確さの両方を達成する方法について説明します。
次に示す検証可能な資格証明から始めるとしましょう。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.com/credentials/4643",
"type": ["VerifiableCredential"],
"issuer": "https://example.com/issuers/14",
"issuanceDate": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
}
}
この検証可能な資格証明は、did:example:abcdef1234567に関連付けられているエンティティーがJane Doeという値を持つname(名前)を持っていることを示しています。
ここで、開発者が、検証可能な資格証明を拡張して社内の参照番号とJaneの好物という2つの追加情報を保存したいと考えていると仮定してみましょう。
最初に行うべきことは、次に示すような、2つの新しい用語を含むJSON-LDコンテキストを作成することです。
{
"@context": {
"referenceNumber": "https://example.com/vocab#referenceNumber",
"favoriteFood": "https://example.com/vocab#favoriteFood"
}
}
このJSON-LDコンテキストが作成された後、開発者はそれをどこかに公開し、検証可能な資格証明を処理する検証者がアクセスできるようにします。上記のJSON-LDコンテキストがhttps://example.com/contexts/mycontext.jsonldで公開されていると仮定すると、コンテキストを含めて、新しいプロパティーと資格証明の型を検証可能な資格証明に追加することで、この例を拡張することができます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://example.com/contexts/mycontext.jsonld"
],
"id": "http://example.com/credentials/4643",
"type": ["VerifiableCredential", "CustomExt12"],
"issuer": "https://example.com/issuers/14",
"issuanceDate": "2018-02-24T05:28:04Z",
"referenceNumber": 83294847,
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe",
"favoriteFood": "Papaya"
}
}
この例は、検証可能な資格証明データ・モデルを無許可かつ分散的な方法で拡張する方法を示しています。示しているメカニズムにより、この方法で作成された検証可能な資格証明が、名前空間の競合やセマンティックの曖昧さを防ぐメカニズムを提供することも保証されます。
このような動的な拡張性モデルは、実装の負担を増加させます。このようなシステムのために書かれたソフトウェアは、アプリケーションのリスク・プロファイルに基づいて、拡張機能を備えた検証可能な資格証明が受け入れられるかどうかを判断しなければなりません。アプリケーションによっては、特定の拡張機能しか受け入れないかもしれないし、高度に安全な環境ではいかなる拡張機能も受け入れないかもしれません。これらの決定は、これらのアプリケーションの開発者次第であり、特にこの仕様の領域ではありません。
開発者は、拡張JSON-LDコンテキストの可用性が高いことを保証することが望まれます。コンテキストを取得できない実装では、エラーが発生します。拡張JSON-LDコンテキストが常に利用可能であることを保証するための戦略には、コンテキストにコンテンツ・アドレス型(content-addressed)URLを用いること、コンテキスト・ドキュメントを実装にバンドルすること、またはコンテキストの積極的なキャッシュを可能とすることが含まれます。
実装者は、4.7 証明(署名)、4.9 ステータス、5.4 データ・スキーマ、5.5 リフレッシュ、5.6 使用条件、5.7 証拠の項など、この仕様の拡張ポイントに細心の注意を払うことをお勧めします。この仕様では、これらの拡張ポイントの具体的な実装については定義していませんが、検証可能な資格証明拡張レジストリ[VC-EXTENSION-REGISTRY]は、開発者がこれらの拡張ポイントから使用できる拡張の非公式かつ厳選された一覧を提供しています。
この仕様は、JSONの実装でJSON-LDプロセッサを用いる必要なく、「プレーンな」JSONとJSON-LDの構文が、セマンティック的に互換性があることを保証しています。これを達成するために、この仕様は、両方の構文に次の追加要件を課しています。
@context鍵を処理しなければならず(MUST)、予期される値が、処理される資格証明の型に対して予期される順序で存在することを保証します。資格証明で用いられる鍵(@contextに関連付けられている値を用いて定義される)は、「最初に定義されたものが優先される」メカニズムを用いて定義され、順序を変更すると、異なる鍵の定義が「優先される」ことになりえるため、順序は重要です。@protected機能について読むとよいでしょう。相互運用性を求める実装者が、@contextプロパティーの予期される値の順序を記述した人間が読めるドキュメントを公開することが期待されます。相互運用性を求めるJSON-LD実装者が、機械可読記述(つまり、通常のJSON-LDコンテキスト・ドキュメント)を@contextプロパティーで指定されているURLで公開することが期待されます。
上記の要件は、@contextメカニズムで定義されている用語について、JSONとJSON-LDの間のセマンティックな相互運用性を保証します。JSON-LDプロセッサは、提供された特定のメカニズムを用いて、すべての用語が正しく指定されていることを検証できますが、JSONベースのプロセッサは、同じ用語の集合を、それらが正しいことをテストせずに暗黙的に受け入れます。言い換えれば、データ交換が行われるコンテキストは、同じメカニズムを用いることでJSONとJSON-LDの両方に対して明示的に記述されます。JSONベースのプロセッサに関しては、JSON-LDの処理ライブラリを用いる必要なく、軽量な方法でこれを実現できます。
データ・スキーマは、あるデータのコレクションに対して特定の構造を強制する場合に有効です。この仕様で検討しているデータ・スキーマには、少なくとも次の2種類があります。
データ・スキーマが@contextプロパティーとは異なる目的を果たすことを理解することが重要で、それは、データ構造やデータ構文を強制することも、代替表現形式に対して任意のエンコーディングの定義を可能とすることもありません。
この仕様では、発行者が発行する検証可能な資格証明に含めることができるデータ・スキーマの表現のために次のプロパティーを定義しています。
credentialSchemaプロパティーの値は、提供されたデータが提供されたスキーマに準拠しているかどうかを判断するのに十分な情報を検証者に提供する1つ以上のデータ・スキーマでなければなりません(MUST)。各credentialSchemaは、そのtype(例えば、JsonSchemaValidator2018)と、スキーマ・ファイルを識別するURIでなければならない(MUST)idプロパティーを指定しなければなりません(MUST)。各データ・スキーマの正確な内容は、特定の型の定義によって決まります。credentialSchemaプロパティーは、型の定義にアノテーションを付与したり、それを語彙の特定のバージョンに固定する機会を提供します。検証可能な資格証明の作成者は、何らかの内容の完全性保護メカニズムに固定されているcredentialSchemaを用いて、その語彙の静的なバージョンを含めることができます。また、credentialSchemaプロパティーにより、資格証明の構文チェックを行ったり、JSONスキーマ[JSON-SCHEMA-2018]妥当性検証などの検証メカニズムを用いたりすることができます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"credentialSchema": {
"id": "https://example.org/examples/degree.json",
"type": "JsonSchemaValidator2018"
}
}
上の例では、発行者はcredentialSchemaを指定しており、これは、検証者が検証可能な資格証明が整形式になっているかどうかを判断するために使用できる[JSON-SCHEMA-2018]ファイルを指します。
JSONスキーマ[JSON-SCHEMA-2018]やその他のオプションの検証メカニズムとの連携については、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントを参照してください。
データ・スキーマは、ゼロ知識証明の実行に用いられるものなど、他のバイナリ形式へのマッピングを指定するために用いることもできます。ゼロ知識証明での credentialSchemaプロパティーの使用の詳細については、5.8 ゼロ知識証明の項を参照してください。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"credentialSchema": {
"id": "https://example.org/examples/degree.zkp",
"type": "ZkpExampleSchema2018"
},
"proof": { ... }
}
上の例では、発行者は、入力データをある形式に変換することができるゼロ知識パックされたバイナリ・データ形式を指すcredentialSchemaを指定しており、その形式は、検証可能な資格証明とともに提供される証明が有効かどうかを判断するために、検証者が使用できます。
システムにとって、有効期限切れの検証可能な資格証明を手動または自動でリフレッシュできるようにすることは有用です。有効期限切れの検証可能な資格証明の詳細については、4.8 有効期限の項を参照してください。この仕様では、refreshServiceプロパティーを定義し、発行者がリフレッシュ・サービスへのリンクを含めることができるようにしています。
発行者は、検証者または保有者(あるいはその両方)を対象とする場合は検証可能な資格証明内に、保有者のみを対象とする場合は検証可能なプレゼンテーション内に、リフレッシュ・サービスを要素として含めることができます。後者の場合、これによって保有者は、検証可能なプレゼンテーションを作成して検証者と共有する前に、検証可能な資格証明をリフレッシュすることができます。前者の場合、検証可能な資格証明内にリフレッシュ・サービスを含めると、保有者または検証者のいずれかが資格証明の将来の更新を実行できるようになります。
リフレッシュ・サービスは、資格証明の有効期限が切れたとき、または発行者が資格証明のステータス情報を公開しない場合にのみ用いることを想定しています。発行者は、公開情報が含まれていない、またはリフレッシュ・サービスが何らかの方法で保護されていない検証可能な資格証明にrefreshServiceプロパティーを含めないようにすることをお勧めします。
検証者が利用できるように、検証可能な資格証明にrefreshServiceプロパティーを配置すると、保有者の制御と同意を解除し、検証可能な資格証明を直接検証者に発行できるようになり、従って、保有者をバイパスできるようになります。
refreshServiceプロパティーの値は、受信者が検証可能な資格証明をリフレッシュできるように、受信者のソフトウェアに十分な情報を提供する1つ以上のリフレッシュ・サービスでなければなりません(MUST)。各refreshService値は、そのtype(例えば、ManualRefreshService2018)と、サービスのURIであるidを指定しなければなりません(MUST)。そのURIから機械可読情報を取得できる必要があることが期待されます。各リフレッシュ・サービスの正確な内容は、特定のrefreshService型の定義によって決まります。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"refreshService": {
"id": "https://example.edu/refresh/3732",
"type": "ManualRefreshService2018"
}
}
上の例では、発行者は、保有者や検証者をhttps://example.edu/refresh/3732に導くことで利用できる手動のrefreshServiceを指定しています。
使用条件は、発行者または保有者が、検証可能な資格証明または検証可能なプレゼンテーションが発行される条件を伝えるために利用できます。発行者は、自身の使用条件を検証可能な資格証明内に配置します。保有者は、自身の使用条件を検証可能なプレゼンテーション内に配置します。この仕様では、使用条件情報を表現するためにtermsOfUseプロパティーを定義しています。
termsOfUseプロパティーの値は、検証可能な資格証明または検証可能なプレゼンテーションを受け入れることにした場合に、実行が求められる行為(義務)、実行が認められない行為(禁止)、または実行が認められる行為(許可)を検証者に伝えます。
保有者でないサブジェクトが、自身の検証可能な資格証明にどのように使用条件を置くかを決定するためには、さらなる研究が必要です。1つの方法は、サブジェクトが発行者に依頼して、発行された検証可能な資格証明内に使用条件を置くことです。別の方法は、サブジェクトが検証可能な資格証明を保有者に委譲し、委譲された検証可能な資格証明に使用条件の制限を置くことでありえます。
termsOfUseプロパティーの値は、作成者が資格証明またはプレゼンテーションを発行した1つ以上の使用条件を指定しなければなりません(MUST)。受信者(保有者または検証者)に、指定された使用条件を順守する意思がない場合は、彼らはそれを自己責任で行い、記載されている使用条件に違反した場合は法的責任を負う可能性があります。個々のtermsOfUseの値は、例えば、IssuerPolicyなど、その型を指定しなければならず(MUST)、そのインスタンスidを指定することができます(MAY)。個々の使用条件の正確な内容は、特定のtermsOfUse型の定義によって決まります。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"termsOfUse": [{
"type": "IssuerPolicy",
"id": "http://example.com/policies/credential/4",
"profile": "http://example.com/profiles/credential",
"prohibition": [{
"assigner": "https://example.edu/issuers/14",
"assignee": "AllVerifiers",
"target": "http://example.edu/credentials/3732",
"action": ["Archival"]
}]
}]
}
上の例では、発行者(assigner(譲渡人))は、検証者(assignee(譲受人))がデータをアーカイブに保存することを禁止しています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1",
{
"@protected": true,
"VerifiablePresentationTermsOfUseExtension": {
"@id": "https://www.w3.org/2018/credentials/examples#VerifiablePresentationExtension",
"@context": {
"@protected": true,
"termsOfUse": {
"@id": "https://www.w3.org/2018/credentials#termsOfUse",
"@type": "@id"
}
}
}
}
],
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": ["VerifiablePresentation", "VerifiablePresentationTermsOfUseExtension"],
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": { ... }
}],
"termsOfUse": [{
"type": "HolderPolicy",
"id": "http://example.com/policies/credential/6",
"profile": "http://example.com/profiles/credential",
"prohibition": [{
"assigner": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"assignee": "https://wineonline.example.org/",
"target": "http://example.edu/credentials/3732",
"action": ["3rdPartyCorrelation"]
}]
}],
"proof": [ ... ]
}
警告: termsOfUseプロパティーは、VerifiablePresentationのスコープ付きコンテキスト内で不適切に定義されています。これはバージョン1のコンテキストでのバグであり、バージョン2のコンテキストで修正される予定です。それまでの間、この機能を使用したい実装者は、termsOfUseプロパティーを定義する追加の用語を用いて自身の検証可能なプレゼンテーションのコンテキストを拡張する必要があり、その後、それは、用語がJSON-LDプロセッサでセマンティック的に認識されるように、検証可能なプレゼンテーションの型プロパティーと一緒に使用できるようになります。
上の例では、サブジェクトでもある保有者(assigner)は、検証者(assignee、https://wineonline.example.org)に対して、第三者のサービスを用いて保有者またはサブジェクトを相関付けるために提供された情報を用いることを禁止する使用条件を表明しています。仮に、検証者が相関付けのために第三者のサービスを利用すれば、保有者がプレゼンテーションを作成した際の条件に違反することになります。
機密データの予期せぬ使用から市民を守るために、政府発行の検証可能な資格証明がこの機能を用いて、デジタル・ウォレットに対してその使用を同様の政府組織に制限するよう指示することが期待されます。同様に、民間企業が発行する検証可能な資格証明の中には、使用を組織内の部署内または営業時間内に制限するものがあると予想されます。実装者は、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントの該当する項で、急速に進化するこの機能の詳細について読まれることをお勧めします
発行者は、検証者に検証可能な資格証明のサポート情報を追加提供するために、証拠を含めることができます。これは、検証者が検証可能な資格証明のクレームに依拠する信頼を確立するために使用できます。
例えば、発行者は、資格証明を発行する前に、サブジェクトが提供した物理的なドキュメントをチェックしたり、一連のバックグラウンド・チェックを実行したりすることができます。特定のシナリオでは、この情報は、検証者が特定の資格証明に依存することに関連するリスクを判断する際に有用です。
この仕様では、証拠情報を表現するためにevidenceプロパティーを定義しています。
evidenceプロパティーの値は、発行者が収集した証拠が資格証明に依存するための信頼性要件を満たしているかどうかを検証者が判断するのに十分な情報を提供する1つ以上の証拠スキームでなければなりません(MUST)。各証拠スキームは、その型によって識別されます。idプロパティーはオプションですが、存在する場合は、この証拠のインスタンスに関する詳細情報がある場所を指すURLを含むべきです(SHOULD)。各証拠スキームの正確な内容は、特定のevidence型の定義によって決まります。資格証明および非資格証明データへの添付および参照が仕様でどのようにサポートされるかについての情報は、検証可能な資格証明実装ガイドライン [VC-IMP-GUIDE]ドキュメントを参照してください。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"evidence": [{
"id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
"type": ["DocumentVerification"],
"verifier": "https://example.edu/issuers/14",
"evidenceDocument": "DriversLicense",
"subjectPresence": "Physical",
"documentPresence": "Physical",
"licenseNumber": "123AB4567"
}],
"proof": { ... }
}
ゼロ知識証明は、エンティティーが別のエンティティーに対して、実際の値を開示することなく、特定の値を知っていることを証明できる暗号メソッドです。現実世界の例として、学位に含まれている身元やその他の個人を特定できる情報を明かすことなく、認定された大学から学位を授与されたことを証明することが挙げられます。
ゼロ知識証明メカニズムによって導入される重要な機能は、保有者が次のことを行う能力です。
この仕様は、ゼロ知識証明メカニズムを用いて選択的開示をサポートするデータ・モデルについて説明しています。以下の例は、どのようにデータ・モデルを用いて、ゼロ知識の検証可能な資格証明を発行、提示、および検証できるかを示しています。
保有者がゼロ知識の検証可能なプレゼンテーションを用いるには、保有者がプライバシーを強化した方法で検証者に情報を提示できるように、最初に発行された検証可能な資格証明から保有者が証明を導き出せる形で発行者が検証可能な資格証明を発行している必要があります。これは、保有者が、署名された値を明かすことなく、または特定の選択された値を明かすだけで、発行者の署名の妥当性を証明できることを意味します。標準的な慣行は、署名自体を明かすことなく、署名に関する知識を証明することによって行うというものです。検証可能な資格証明をゼロ知識証明システムで用いることにする場合、2つの要件があります。
proofプロパティーを用いたProof(証明)が含まれていなければなりません(MUST)。credentialSchemaプロパティーで定義し、すべての関係者がそれを用いてゼロ知識で様々な暗号操作を実行できるようにしなければなりません(MUST)。次の例は、ゼロ知識で検証可能な資格証明を用いるメソッドの1つを示しています。これは、Camenisch-Lysyanskaya署名[CL-SIGNATURES]を用いており、検証可能な資格証明の値の選択的開示の使用を通じて保有者とサブジェクトのプライバシーをサポートする形で、検証可能な資格証明のプレゼンテーションを可能にします。ゼロ知識証明に依存して属性を選択的に開示する他の一部の暗号システムも、同様に[LDP-REGISTRY]にあります。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSchema": {
"id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
"type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
},
"issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
"credentialSubject": {
"givenName": "Jane",
"familyName": "Doe",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts",
"college": "College of Engineering"
}
},
"proof": {
"type": "CLSignature2019",
"issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D",
"attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy",
"signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs",
"signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH"
}
}
上の例は、credentialSchemaプロパティーと、Camenisch-Lysyanskaya Zero-Knowledge Proofシステムで使用できる特定の証明を用いて、検証可能な資格証明の定義を提供しています。
次の例は、上記の検証可能な資格証明を利用して、プライバシーを保持した証明を持つ新たに派生した検証可能な資格証明を生成します。次に、派生した検証可能な資格証明が検証可能なプレゼンテーションに置かれるため、検証可能な資格証明は、保有者が意図したクレームと追加の資格証明のメタデータのみが開示されます。これを行うには、次のすべての要件が満たされることが期待されます。
proofプロパティーを含むべきです(SHOULD)。{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
"verifiableCredential": [
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSchema": {
"id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
"type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
},
"issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
"credentialSubject": {
"degreeType": "BachelorDegree",
"degreeSchool": "College of Engineering"
},
"proof": {
"type": "AnonCredDerivedCredentialv1",
"primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737",
"nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h"
}
}],
"proof": {
"type": "AnonCredPresentationProofv1",
"proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D"
}
}
資格証明の定義および証明の形式に関する重要な詳細は、このドキュメントの範囲外であるため、意図的に省略しています。この項の目的は、ゼロ知識証明システムをサポートするために、検証可能な資格証明および検証可能なプレゼンテーションを拡張したい実装者を案内することです。
エンティティーが、発行者が発行した資格証明に異議を唱えたい場合は、少なくとも次の異なる2つのケースを考慮すべきです。
addressプロパティーが正しくない、または古くなっているなど。DisputeCredentialを発行するメカニズムは、DisputeCredentialプロパティーのcredentialSubject識別子が異議を唱えられている資格証明の識別子であることを除いて、通常の資格証明と同じです。
例えば、https://example.org/credentials/245という識別子の資格証明に異議がある場合、
サブジェクトは以下に示す資格証明を発行し、異議が唱えられている資格証明とともに検証者に提示することができます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.com/credentials/123",
"type": ["VerifiableCredential", "DisputeCredential"],
"credentialSubject": {
"id": "http://example.com/credentials/245",
"currentStatus": "Disputed",
"statusReason": {
"value": "Address is out of date.",
"lang": "en"
},
},
"issuer": "https://example.com/people#me",
"issuanceDate": "2017-12-05T14:27:42Z",
"proof": { ... }
}
上記の検証可能な資格証明では、発行者は、異議が唱えられている検証可能な資格証明のアドレスが間違っているというクレームを行っています。
資格証明に識別子がない場合は、異議が唱えられている資格証明を識別するためにコンテンツ・アドレス型識別子を用いることができます。同様に、コンテンツ・アドレス型識別子は、個々のクレームを一意に識別するために使用できます。
この研究分野は急速に発展しており、他の資格証明の真偽に異議を唱える資格証明の公開に関心のある開発者は、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントの異議に関する項を読むことをお勧めします。
この項は非規範的です。
検証可能な資格証明は、サブジェクトを確実に識別するための手段となることを目的としています。ロール・ベース・アクセス制御(Role Based Access Control: RBAC)と属性ベース・アクセス制御(Attribute Based Access Control: ABAC)は、サブジェクトに資源へのアクセスを承認する手段としてこの識別に依存していると認識されていますが、この仕様はRBACやABACの完全な解決策を提供するものではありません。付随する承認フレームワークがなければ、承認は、この仕様の適切な使用方法ではありません。
ワーキンググループは、この仕様の作成中に承認のユースケースを検討し、この仕様の上に構築されるアーキテクチャ層としてその取組を進めています。
3. コア・データ・モデル、4. 基本概念、および 5. 高度な概念の項で説明したデータ・モデルは、検証可能な資格証明または検証可能なプレゼンテーションの正規の構造表現です。すべてのシリアル化は、そのデータ・モデルを特定のフォーマットで表現したものです。この項では、データ・モデルが JSON-LDおよびプレーンなJSONでどのように実現されるかを規定します。これら2つの構文に対する構文マッピングのみを提供していますが、アプリケーションとサービスは、データ・モデルを表現できる他のあらゆるデータ表現構文(XML、YAML、CBORなど)を使用できます。検証と妥当性検証の要件はデータ・モデルの観点から定義されるため、すべてのシリアル化構文は、処理、妥当性検証、または比較のためにデータ・モデルに確定的に変換されなければなりません。この仕様では、特定のシリアル化形式のサポートを要求しません。
この仕様におけるプロパティー値の期待されるアリティ(arity)、およびそれらの値を保持する結果のデータ型は、プロパティーによって異なる可能性があります。次のプロパティーは、存在する場合、1つの値として表されます。
idプロパティー(IDプロパティー)issuerプロパティー(発行者プロパティー)issuanceDateプロパティー(発行日プロパティー)expirationDateプロパティー(有効期限日プロパティー)その他のすべてのプロパティーは、存在する場合、1つの値または値の配列として表されます。
3. コア・データ・モデルの項で説明しているように、データ・モデルは、次のとおりにプロパティーの値をJSONの型にマッピングすることにより、JSON(JavaScript Object Notation)[RFC8259]でエンコードできます。
ここに挙げている変換は、互換性のない解釈を行う可能性があるため、データ・モデルへの確定的な変換を行うには、JSON形式の追加のプロファイリングが必要です。
[JSON-LD]は、リンクト・データをシリアル化するために用いられるJSONベースのフォーマットです。この構文は、すでにJSONを用いている展開済みのシステムに簡単に統合できるように設計されており、JSONから[JSON-LD]へのスムーズなアップグレード・パスを提供します。これは主に、ウェブ・ベースのプログラミング環境において、リンクト・データを用い、相互運用可能なウェブ・サービスを構築し、JSONベースのストレージ・エンジンにリンクト・データを保存するための方法となることを目的としています。
[JSON-LD]は、この仕様で説明しているデータ・モデルを拡張する際に有用です。データ・モデルのインスタンスは、@contextプロパティーを追加することで、JSON(6.1 JSONの項)でエンコードされるのと同じ方法で[JSON-LD]でエンコードされます。JSON-LDのコンテキストは[JSON-LD]仕様で詳細に説明されており、その使用方法を5.3 拡張性の項で詳細に説明しています。
複数のコンテキストを使用または組み合わせて、検証可能な資格証明に関する任意の情報を慣用的なJSONで表現できます(MAY)。https://www.w3.org/2018/credentials/v1で入手できるJSON-LDのコンテキストは、更新されることのない静的なドキュメントであるため、クライアント側にダウンロードし、キャッシュすることができます。検証可能な資格証明データ・モデルに関連する語彙ドキュメントは、https://www.w3.org/2018/credentialsにあります。
一般に、このドキュメントで説明しているデータ・モデルと構文は、開発者がサンプルをコピー・アンド・ペーストすることで、検証可能な資格証明をソフトウェア・システムに組み込むことができるように設計されています。このアプローチの設計目標は、異種のソフトウェア・システム集合間のグローバルな相互運用性を確保しつつ、参入障壁を低くすることです。この項では、これらのアプローチの一部について説明します。ほとんどの開発者はこれらに気づかない可能性が高いですが、その詳細は実装者の興味を引くでしょう。[JSON-LD]が提供する最も注目すべき糖衣構文は、次のとおりです。
@idと@typeのキーワードは、それぞれidとtypeにエイリアスされており、開発者はこの仕様を慣用的なJSONとして使用できます。verifiableCredentialとproofのプロパティーは、グラフ・コンテナとして扱われます。つまり、様々なエンティティーによって言明された一連のデータを分離するために用いられるメカニズムです。これにより、例えば、各発行者が提供するデータ・グラフと、検証可能な資格証明を提示する保有者が提供するデータ・グラフとの間の適切な暗号による分離が保証され、各グラフの情報の来歴が確実に保持されます。@protectedプロパティー機能は、この仕様が定義している用語を上書きできないようにするために用いられます。つまり、検証可能な資格証明または検証可能なプレゼンテーションの先頭で同じ@context宣言が行われている限り、データ・モデルのユーザーが理解しているすべての用語について、[JSON-LD]プロセッサを用いているかどうかに関係なく、相互運用性が保証されるということです。この仕様で説明しているデータ・モデルは、証明フォーマットに依存しないように設計されています。この仕様では、特定のデジタル証明または署名の形式を規範的に要求しません。データ・モデルは、資格証明またはプレゼンテーションの正規表現ですが、その証明メカニズムは、多くの場合、関係者間のドキュメントの伝送に用いられる構文に結び付けられています。そのため、各証明メカニズムは、証明の検証を、送信時のドキュメントの状態に対して計算するのか、変換された可能性のあるデータ・モデルに対して計算するのか、または別の形式に対して計算するのかを指定しなければなりません。公開時点で、少なくとも2つの証明フォーマットが実装者によって活発に利用されており、ワーキンググループは、これらの証明フォーマットがどのようなものであり、どのように用いられているかを文書化することが実装者にとって有益であると感じました。検証可能な資格証明を発行するために活発に利用されている現在の証明フォーマットを詳細に説明している項は次のとおりです
JSONウェブ・トークン(JWT)[RFC7519]は、2者間で転送されるクレームを表す手段として、現在でも広く使用されています。JWT用の検証可能な資格証明データ・モデルの表現を提供することで、既存のシステムとライブラリを1.2 エコシステムの概要の項で説明しているエコシステムに加えることができるようになります。JWTは、JSONウェブ署名(JWS)[RFC7515]またはJWE[RFC7516]に含まれるJSONオブジェクトとして、一連のクレームをエンコードします。この仕様では、JWEの使用については範囲外です。
この仕様は、検証可能な資格証明データ・モデルのJWTおよびJWSへのエンコード規則を定義しています。さらに、JWTに基づくシステムがこの仕様に準拠できるように、特定のJWT登録クレーム名と特定のJWS登録ヘッダー・パラメータ名をいつ、どのように用いるかの処理規則を定義しています。これらの特定のクレーム名とヘッダー・パラメータが存在する場合、重複を避けるために、標準的な検証可能な資格証明および検証可能なプレゼンテーションのそれぞれの同等の部分を省略することができます(MAY)。
この仕様では、2つの新しい登録済みクレーム名を導入しており、それには、JWTの明示的なエンコーディング規則が存在しない標準的な検証可能な資格証明および検証可能なプレゼンテーションの該当部分が含まれています。これらのオブジェクトは、次のようにJWTペイロードに含まれています。
vc: JWTの検証可能な資格証明に存在しなければならない(MUST)JSONオブジェクト。このオブジェクトには、この仕様に従った資格証明が含まれています。vp: JWTの検証可能なプレゼンテーションに存在しなければならない(MUST)JSONオブジェ クト。このオブジェクトには、この仕様に従ったプレゼンテーションが含まれています。検証可能な資格証明をJWTとしてエンコードするためには、この仕様で導入している特定のプロパティーは、次のいずれかでなければなりません(MUST)。
明示的な規則が指定されていなければ、プロパティーは標準的な資格証明と同じ方法でエンコードされ、JWTのvcクレームに追加されます。すべてのJWTと同様に、JWT構文で表される検証可能な資格証明のJWSベースの署名は、デコードまたは変換規則が適用される前に、ネットワーク上で提示されるリテラルJWT文字列値に対して計算が行われます。次の段落では、これらのエンコード規則について説明します。
JWSが存在する場合、デジタル署名は検証可能な資格証明の発行者を参照するか、検証可能なプレゼンテーションの場合は検証可能な資格証明の保有者を参照するかのいずれかです。JWSは、JWTのissが、含まれているJWTペイロードに署名したことを証明するため、 proofプロパティーは省略できます。
JWSが存在しない場合は、proofプロパティーを提供しなければなりません(MUST)。proofプロパティーは、作成者が発行者と異なる場合に必要となる、より複雑な証明やプルーフ・オブ・ワーク(Proof of Work)などのデジタル署名に基づかない証明を表すために使用できます。発行者は、JWSとproofプロパティーの両方を含めることができます(MAY)。下位互換性上の理由から、発行者は、JWSを用いてデジタル署名に基づく証明を表さなければなりません(MUST)。
この仕様のコンテキストでは、次の規則がJOSEヘッダーに適用されます。
algを設定しなければなりません(MUST)。選択した署名メソッドにproofプロパティーのみが必要な場合(つまり、そのメソッドにアルゴリズムの選択肢がない場合)、algヘッダーをnoneに設定しなければなりません(MUST)。kidを使用できます(MAY)。鍵の発見については、この仕様の範囲外です。例えば、kidはDIDドキュメント内の鍵を参照したり、またJWKS内の鍵の識別子になったりすることができます。typは、存在する場合、JWTに設定されなければなりません(MUST)。JWTプロセッサとの下位互換性のために、次の登録済みJWTクレーム名を、それぞれの標準的な検証可能な資格証明に対応するものの代わりに、またはそれに加えて、使用しなければなりません(MUST)。
expは、UNIXタイムスタンプ(NumericDate)としてエンコードされた、expirationDateプロパティーを表さなければなりません(MUST)。issは、検証可能な資格証明のissuerプロパティー、または検証可能なプレゼンテーションのholderプロパティーを表さなければなりません(MUST)nbfは、UNIXタイムスタンプ(NumericDate)としてエンコードされたissuanceDateを表わさなければなりません(MUST)。jtiは、検証可能な資格証明または検証可能なプレゼンテーションのidプロパティーを表わさなければなりません(MUST)。subは、credentialSubjectに含まれるidプロパティーを表さなければなりません(MUST)。
bearer credentialsとpresentationsには、subは存在しません。
audは、検証可能なプレゼンテーションの意図された利用者(つまり、提示する保有者が検証可能なプレゼンテーションを受信して検証することを意図した検証者)を表さなければ(つまり、 識別しなければ)なりません(MUST)。ここで指定していない他のJOSEヘッダー・パラメータおよびJWTクレーム名は、その使用が明示的に非推奨となっていなければ、使用できます。追加の検証可能な資格証明のクレームは、JWTのcredentialSubjectプロパティーに追加しなければなりません(MUST)。
ここで指定していないJOSEヘッダー・パラメータおよび/またはJWTクレーム名の使用に関する詳細については、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントを参照してください。
このバージョンの仕様では、高度な概念の項で概説している概念(例えば、refreshService、termsOfUse、evidence)に対するJWT固有のエンコーディング規則を定義していません。この概念は、何の変換もせずにそのままエンコードでき、vc JWTクレームに追加できます。
実装者は、JWTが複数のサブジェクトをエンコードできないため、複数のサブジェクトを含む検証可能な資格証明をエンコードできないことに注意してください。JWTは将来的に複数のサブジェクトをサポートする可能性があり、実装者は、複数サブジェクトのJWTクレーム名または入れ子のJSONウェブ・トークン仕様についてJSONウェブ・トークン・クレーム・レジストリを参照することをお勧めします。
JWTを標準的な資格証明またはプレゼンテーションにデコードするためには、次の変換を実行しなければなりません(MUST)。
vcまたはvpクレームの内容を新しいJSONオブジェクトに追加します。JWT固有のヘッダーとクレームを変換するには、次を実行しなければなりません(MUST)。
expが存在する場合、UNIXタイムスタンプを[XMLSCHEMA11-2]のdate-timeに変換しなければならず(MUST)、新しいJSONオブジェクトのcredentialSubjectのexpirationDateプロパティーの値を設定するために用いなければなりません(MUST)。issが存在する場合、その値は、新しい資格証明JSONオブジェクトのissuerプロパティーまたは新しいプレゼンテーションJSONオブジェクトのholderプロパティーを設定するために用いなければなりません(MUST)。nbfが存在する場合、UNIXタイムスタンプを[XMLSCHEMA11-2]のdate-timeに変換しなければならず(MUST)、新しいJSON オブジェクトのissuanceDateプロパティーの値を設定するために用いなれなければなりません(MUST)。subが存在する場合、その値は、新しい資格証明JSONオブジェクトのcredentialSubjectのidプロパティーの値を設定するために用いなければなりません(MUST)。jtiが存在する場合、その値は、新しいJSONオブジェクトのidプロパティーの値を設定するために用いなければなりません(MUST)。{
"alg": "RS256",
"typ": "JWT",
"kid": "did:example:abfe13f712120431c276e12ecab#keys-1"
}
上の例では、検証可能な資格証明はJWSデジタル署名に基づくproofを用いており、対応する検証鍵はkidヘッダー・パラメータを用いて取得できます。
{
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "http://example.edu/credentials/3732",
"iss": "https://example.com/keys/foo.jwk",
"nbf": 1541493724,
"iat": 1541493724,
"exp": 1573029723,
"nonce": "660!6345FSer",
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSubject": {
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
}
上の例では、JWTエンコーディングがjti属性を用いて一意な識別子を表すため、vcにはidプロパティーが含まれていません。sub属性は、credentialSubjectのidプロパティーで表される情報をエンコードします。nonceは、リプレイ攻撃を阻止するために追加されました。
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0
MzFjMjc2ZTEyZWNhYiNrZXlzLTEifQ.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxY
zI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzc
yI6Imh0dHBzOi8vZXhhbXBsZS5jb20va2V5cy9mb28uandrIiwibmJmIjoxNTQxNDkzNzI0LCJpYXQiO
jE1NDE0OTM3MjQsImV4cCI6MTU3MzAyOTcyMywibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY
29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd
3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjd
CI6eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IjxzcGFuIGxhbmc9J2ZyL
UNBJz5CYWNjYWxhdXLDqWF0IGVuIG11c2lxdWVzIG51bcOpcmlxdWVzPC9zcGFuPiJ9fX19.KLJo5GAy
BND3LDTn9H7FQokEsUEi8jKwXhGvoN3JtRa51xrNDgXDb0cq1UTYB-rK4Ft9YVmR1NI_ZOF8oGc_7wAp
8PHbF2HaWodQIoOBxxT-4WNqAxft7ET6lkH-4S6Ux3rSGAmczMohEEf8eCeN-jC8WekdPl6zKZQj0YPB
1rx6X0-xlFBs7cl6Wt8rfBP_tZ9YgVWrQmUWypSioc0MUyiphmyEbLZagTyPlUyflGlEdqrZAv6eSe6R
txJy6M1-lD7a5HTzanYTWBPAUHDZGyGKXdJw-W_x0IWChBzI8t3kpG253fg6V3tPgHeKXE94fz_QpYfg
--7kLsyBAfQGbg
{
"alg": "RS256",
"typ": "JWT",
"kid": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1"
}
上の例では、検証可能なプレゼンテーションは、JWSデジタル署名に基づくproofを用いており、対応する検証鍵はkidヘッダー・パラメータを用いて取得できます。
{
"iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
"aud": "did:example:4a57546973436f6f6c4a4a57573",
"nbf": 1541493724,
"iat": 1541493724,
"exp": 1573029723,
"nonce": "343s$FSFDa-",
"vp": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiablePresentation"],
// 文字列としてbase64urlでエンコードされたJWT
"verifiableCredential": ["..."]
}
}
上の例では、JWTエンコーディングがjti属性を用いて一意な識別子を表すため、vpにはidプロパティーが含まれていません。verifiableCredentialには、JWTコンパクト・シリアル化を用いた検証可能な資格証明の文字列配列が含まれます。nonceは、リプレイ攻撃を阻止するために追加されました。
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWJjI2tleTEifQ.e
yJpc3MiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJ1cm46d
XVpZDozOTc4MzQ0Zi04NTk2LTRjM2EtYTk3OC04ZmNhYmEzOTAzYzUiLCJhdWQiOiJkaWQ6ZXhhbXBsZ
To0YTU3NTQ2OTczNDM2ZjZmNmM0YTRhNTc1NzMiLCJuYmYiOjE1NDE0OTM3MjQsImlhdCI6MTU0MTQ5M
zcyNCwiZXhwIjoxNTczMDI5NzIzLCJub25jZSI6IjM0M3MkRlNGRGEtIiwidnAiOnsiQGNvbnRleHQiO
lsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCJodHRwczovL3d3dy53My5vc
mcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50Y
XRpb24iLCJDcmVkZW50aWFsTWFuYWdlclByZXNlbnRhdGlvbiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhb
CI6WyJleUpoYkdjaU9pSlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkltUnBaRHBsZUdGd
GNHeGxPbUZpWm1VeE0yWTNNVEl4TWpBME16RmpNamMyWlRFeVpXTmhZaU5yWlhsekxURWlmUS5leUp6Z
FdJaU9pSmthV1E2WlhoaGJYQnNaVHBsWW1abFlqRm1OekV5WldKak5tWXhZekkzTm1VeE1tVmpNakVpT
ENKcWRHa2lPaUpvZEhSd09pOHZaWGhoYlhCc1pTNWxaSFV2WTNKbFpHVnVkR2xoYkhNdk16Y3pNaUlzS
W1semN5STZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWpiMjB2YTJWNWN5OW1iMjh1YW5kcklpd2libUptS
WpveE5UUXhORGt6TnpJMExDSnBZWFFpT2pFMU5ERTBPVE0zTWpRc0ltVjRjQ0k2TVRVM016QXlPVGN5T
Xl3aWJtOXVZMlVpT2lJMk5qQWhOak0wTlVaVFpYSWlMQ0oyWXlJNmV5SkFZMjl1ZEdWNGRDSTZXeUpvZ
EhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZrWlc1MGFXRnNjeTkyTVNJc0ltaDBkSEJ6T
2k4dmQzZDNMbmN6TG05eVp5OHlNREU0TDJOeVpXUmxiblJwWVd4ekwyVjRZVzF3YkdWekwzWXhJbDBzS
W5SNWNHVWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSlZibWwyWlhKemFYUjVSR1ZuY
21WbFEzSmxaR1Z1ZEdsaGJDSmRMQ0pqY21Wa1pXNTBhV0ZzVTNWaWFtVmpkQ0k2ZXlKa1pXZHlaV1VpT
25zaWRIbHdaU0k2SWtKaFkyaGxiRzl5UkdWbmNtVmxJaXdpYm1GdFpTSTZJanh6Y0dGdUlHeGhibWM5S
jJaeUxVTkJKejVDWVdOallXeGhkWExEcVdGMElHVnVJRzExYzJseGRXVnpJRzUxYmNPcGNtbHhkV1Z6U
EM5emNHRnVQaUo5ZlgxOS5LTEpvNUdBeUJORDNMRFRuOUg3RlFva0VzVUVpOGpLd1hoR3ZvTjNKdFJhN
TF4ck5EZ1hEYjBjcTFVVFlCLXJLNEZ0OVlWbVIxTklfWk9GOG9HY183d0FwOFBIYkYySGFXb2RRSW9PQ
nh4VC00V05xQXhmdDdFVDZsa0gtNFM2VXgzclNHQW1jek1vaEVFZjhlQ2VOLWpDOFdla2RQbDZ6S1pRa
jBZUEIxcng2WDAteGxGQnM3Y2w2V3Q4cmZCUF90WjlZZ1ZXclFtVVd5cFNpb2MwTVV5aXBobXlFYkxaY
WdUeVBsVXlmbEdsRWRxclpBdjZlU2U2UnR4Snk2TTEtbEQ3YTVIVHphbllUV0JQQVVIRFpHeUdLWGRKd
y1XX3gwSVdDaEJ6STh0M2twRzI1M2ZnNlYzdFBnSGVLWEU5NGZ6X1FwWWZnLS03a0xzeUJBZlFHYmciX
X19.ft_Eq4IniBrr7gtzRfrYj8Vy1aPXuFZU-6_ai0wvaKcsrzI4JkQEKTvbJwdvIeuGuTqy7ipO-EYi
7V4TvonPuTRdpB7ZHOlYlbZ4wA9WJ6mSVSqDACvYRiFvrOFmie8rgm6GacWatgO4m4NqiFKFko3r58Lu
eFfGw47NK9RcfOkVQeHCq4btaDqksDKeoTrNysF4YS89INa-prWomrLRAhnwLOo1Etp3E4ESAxg73CR2
kA5AoMbf5KtFueWnMcSbQkMRdWcGC1VssC0tB0JffVjq7ZV6OTyV4kl1-UVgiPLXUTpupFfLRhf9QpqM
BjYgP62KvhIvW8BbkGUelYMetA
この仕様は、URLやJSON-LDなどの標準を用いて情報をウェブ上に公開するリンクト・データを用いて、サブジェクトとそれに関連付けられているプロパティーを識別します。情報をこのように示すことで、他の関連情報を容易に発見でき、新しい情報を既存の知識のグラフに容易に統合できます。リンクト・データは分散的な方法で拡張可能であり、大規模な統合に対する障壁を大幅に軽減します。この仕様のデータ・モデルは、この仕様で説明しているデータ・モデルを保護するために設計された、データの整合性および関連付けられているリンクト・データ暗号スイートとうまく連携します。
JSONウェブ・トークンの使用とは異なり、追加の前処理や後処理は必要ありません。データ完全性証明のフォーマットは、検証可能な資格証明および検証可能なプレゼンテーションをシンプルかつ容易に保護するように設計されています。検証可能な資格証明または検証可能なプレゼンテーションを保護することは、この仕様の有効な例をリンクト・データ署名の実装に渡し、デジタル署名を生成するのと同じくらいシンプルです。
様々な構文形式(例えば、JSON+JWT、JSON-LD+JWT、JSON-LD+LD-Proofs)の様々な品質の詳細については、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントを参照してください。
この項は非規範的です。
この項では、検証可能な資格証明データ・モデルを実稼働環境に展開する際の一般的なプライバシーに関する留意点と特定のプライバシーへの影響について詳細に説明します。
この項は非規範的です。
プライバシーには、ハンドルネーム(pseudonymous)から強い特定までの範囲があることを認識することが重要です。ユースケースによって、提供しても構わない情報と、提供された情報から得られる情報について、人々の快適さのレベルは異なります。
例えば、酒を購入する際には、特定の年齢を超えているかどうかのみに基づく規制チェックが求められるため、ほとんどの人は匿名を希望するでしょう。一方、医師が患者のために書いた処方箋の場合、調剤を行う薬局は、その医療専門家と患者をより強く識別する必要があります。したがって、プライバシーには、すべてのユースケースに有効なアプローチはありません。プライバシーの解決策は、ユースケースに依存します。
酒を購入する際に匿名を希望する人の場合でも、適切な保証を販売者に提供するために、写真付き身分証明書を求められる場合があります。販売者は、名前やその他の詳細(特定の年齢を超えていること以外)を知る必要はないかもしれませんが、多くの場合、年齢を証明するだけでは規制を十分に満たせません。
検証可能な資格証明データ・モデルは、プライバシーの範囲を全てサポートするよう努め、特定のトランザクションの正しい匿名性のレベルについて哲学的な立場を取りません。以下の項では、プライバシーに適さない特定のシナリオを回避したい実装者のためのガイダンスを提供します。
この項は非規範的です。
credential.credentialSubjectフィールドに保存されている検証可能な資格証明に関連付けられているデータは、検証者と共有されるとプライバシー侵害の影響を受けやすいです。政府発行の識別子、配送先住所、氏名などの個人を特定できるデータを用いて、容易にエンティティーを確定、追跡、相関付けることができます。生年月日と郵便番号の組み合わせなど、個人を特定できないように思える情報でさえ、非常に強力な相関付けと非匿名化の可能性を有しています。
実装者は、この種の特性を持つデータを共有する場合には、保有者に警告することを強くお勧めします。発行者は、可能であれば、プライバシーを保護した検証可能な資格証明を提供することを強くお勧めします。例えば、検証者が、エンティティーが18歳以上かどうかを判断したい場合、生年月日の検証可能な資格証明の代わりにageOverの検証可能な資格証明を発行します。
検証可能な資格証明には個人を特定できる情報(PII)が含まれていることが多いため、実装者は、検証可能な資格証明を保存および転送する際に、アクセスすべきでない者からデータを保護するメカニズムを用いることを強くお勧めします。考えられるメカニズムには、転送中にデータを暗号化するTLS(Transport Layer Security)またはその他の手段や、保存中(at rest)の検証可能な資格証明のデータを保護するための暗号化またはデータ・アクセス制御メカニズムが含まれます。
この項は非規範的です。
検証可能な資格証明のサブジェクトは、credential.credentialSubject.idフィールドを用いて識別されます。サブジェクトを識別するために用いられる識別子は、その識別子が長期間有効であったり、複数のウェブ・ドメインで用いられていたりすると、相関付けのリスクが大きくなります。
同様に、資格証明の識別子(credential.id)を開示すると、複数の検証者、または発行者と検証者が結託して保有者を相関付けることができる状況につながります。保有者が相関付けを減らしたい場合は、検証可能なプレゼンテーション中に識別子を隠すことを可能にする検証可能な資格証明スキームを用いるべきです。このようなスキームは、保有者が識別子を生成することを期待し、検証可能な資格証明に埋め込まれて署名された識別子を保持しながら、発行者から識別子を隠すことさえ可能にする可能性があります。
検証可能な資格証明システムで強力な相関付け防止プロパティーが必須要件である場合は、識別子を次のいずれかにすることを強くお勧めします。
この項は非規範的です。
検証可能な資格証明の内容は、credential.proofフィールドを用いて保護されます。このフィールドのプロパティーは、同じ値が複数のセッションやドメインで用いられ、値が変更されない場合に、相関付けのリスクが高くなります。例には、verificationMethod、created、proofPurposeおよびjwsフィールドが含まれます。
強力な相関付け防止プロパティーが必要な場合は、サードパーティのペアワイズ署名、ゼロ知識証明、グループ署名などの技術を用いて、署名の値とメタデータを毎回再生成することをお勧めします。
相関付け防止署名を用いる場合でも、用いる暗号の相関付け防止プロパティーを破る情報が検証可能な資格証明に含まれている可能性があります。
この項は非規範的です。
検証可能な資格証明には、個人を相関付けるために使用できる長期間有効な識別子が含まれている場合があります。この種の識別子には、サブジェクト識別子、電子メール・アドレス、政府発行の識別子、組織発行の識別子、住所、ヘルスケア・バイタル、検証可能な資格証明固有のJSON-LDコンテキスト、およびその他の多くの種類の長期間有効な識別子が含まれます。
保有者にソフトウェアを提供する組織は、個人を相関付けるために使用できる情報が含まれている検証可能な資格証明のフィールドを特定し、この情報が共有されている場合には保有者に警告するよう努めるべきです。
この項は非規範的です。
インターネットやウェブ上で個人を追跡し相関付けるために用いられる、検証可能な資格証明の外部のメカニズムがあります。これらのメカニズムには、IP(Internet protocol)アドレスの追跡、ウェブ・ブラウザのフィンガープリント、Evercookie、アドネットワーク・トラッカー、モバイル・ネットワーク位置情報およびアプリケーション内のGPS(Global Positioning System)APIが含まれます。検証可能な資格証明を用いても、これらの他の追跡技術の使用を防ぐことはできません。また、これらの技術を検証可能な資格証明と組み合わせて用いると、新たな相関付け可能な情報が発見される可能性があります。例えば、生年月日と GPSの位置を組み合わせると、複数のウェブ・サイト間の個人を強く相関付けることができます。
検証可能な資格証明が用いられる場合は、プライバシーを尊重するシステムによって、これらの他の追跡技術の使用を防止することをお勧めします。場合によっては、保有者に代わって検証可能な資格証明を送信するデバイス上で、追跡技術を無効にする必要があります。
この項は非規範的です。
検証可能な資格証明の受信者が、トランザクションに必要以上のPIIを明かすことなく、様々な状況で資格証明を使用できるように、発行者は、資格証明で公開される情報を、期待される目的に必要な最小限の集合に制限することを検討する必要があります。資格証明にPIIを置くことを回避する方法の1つは、サブジェクトに関する特定の情報を提供せずに検証者のニーズを満たす抽象的なプロパティーを用いることです。
例えば、このドキュメントでは、特定の生年月日の代わりにageOverプロパティーを用いており、はるかに強力なPIIとなっています。特定の市場の小売業者が、購入者が特定の年齢より上であることを一般に求める場合、その市場で信頼されている発行者は、特定の生年月日に関するクレームを含む検証可能な資格証明を提供する代わりに、サブジェクトがその要件を満たしているとのクレームを行う検証可能な資格証明を提供することを選択できます。これにより、個々の顧客は特定のPIIを明かすことなく購入を行うことができます。
この項は非規範的です。
プライバシー侵害は、あるコンテキストで漏洩した情報が別のコンテキストに漏洩したときに発生します。このような侵害を防ぐためのベスト・プラクティスは、要求される、および受け取る情報を必要最小限に制限することだと考えられています。このデータ最小化のアプローチは、米国の医療保険の相互運用性と説明責任に関する法律(HIPAA)や欧州連合の一般データ保護規則(GDPR)など、複数の法域の規制で必要とされています。
発行者検証可能な資格証明では、発行者にとってのデータの最小化は、検証可能な資格証明の内容を、予期される使用に対して潜在的な検証者が必要とする最小限に制限することを意味します。検証者にとってのデータの最小化は、サービスにアクセスするために要求される、または必要とされる情報の範囲を制限することを意味します。
例えば、運転者のID番号、身長、体重、生年月日、自宅の住所が含まれている運転免許証は、その人が特定の年齢以上であることを証明するために必要であるよりも多くの情報が含まれている資格証明です。
発行者が、情報を細分化するか、選択的開示を可能にする署名スキームを用いることがベスト・プラクティスであると考えられています。例えば、運転免許証の発行者は、運転免許証に表示されるすべての属性を含む検証可能な資格証明、およびすべての検証可能な資格証明に個人の誕生日などの1つの属性のみが含まれる一連の検証可能な資格証明を発行できます。また、より抽象的な検証可能な資格証明(例えば、ageOver属性のみを含む検証可能な資格証明)を発行することもできます。可能な適応策の1つは、発行者が、検証可能な資格証明のハンドルネームの使用を促進する、1回限りのベアラ資格証明を取得するための安全なHTTPエンドポイントを提供することです。これが非現実的または安全でないと判断した実装者は、証明時の発行者への依存を排除し、発行者からの一時的な相関付けのリスクを軽減する選択的開示スキームの使用を検討すべきです。
検証者は、特定のトランザクションを行うために絶対に必要な情報のみを要求することをお勧めします。これは、少なくとも次の2つの理由で重要です。
最小限の開示の原則を実践することは可能ですが、1回のセッションまたは複数回のセッションでの特定のユースケースについて、個人が強く特定されることを回避することは不可能な場合があります。このドキュメントの作成者は、現実世界のシナリオにおいてこの原則を満たすことがいかに困難であるかを強調することはできません。
この項は非規範的です。
ベアラ資格証明は、コンサート・チケットなどのプライバシーを強化する情報であり、ベアラ資格証明の保有者に関する機密情報を漏らすことなく、保有者に特定の資源に対する権利を与えます。ベアラ資格証明は、ベアラ資格証明の共有が懸念とならない、または大きな経済的もしくは評判の損失をもたらさないような低リスクのユースケースでよく用いられます。
ベアラ資格証明である検証可能な資格証明は、credentialSubjectプロパティーで入れ子のidプロパティーを用いて表されるサブジェクト識別子を指定しないことで可能となります。例えば、次の検証可能な資格証明はベアラ資格証明です。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/temporary/28934792387492384",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2017-10-22T12:23:48Z",
"credentialSubject": {
// ベアラ資格証明に「id」プロパティーが指定されないことに注意
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
ベアラ資格証明はプライバシーを強化できますが、ベアラ資格証明の保持者が予期する以上の情報を誤って漏らさないように慎重に作成しなければなりません。例えば、複数のサイトで同じベアラ資格証明を繰り返し用いると、これらのサイトが結託して保有者を不当に追跡または相関付けることが可能となります。同様に、生年月日や郵便番号など、特定できないように見える情報であっても、同じベアラ資格証明やセッションで一緒に用いると、個人を統計的に特定するために用いることができます。
ベアラ資格証明の発行者は、ベアラ資格証明が次のようなプライバシー強化の利点を提供することを保証すべきです。
ソフトウェアは、保有者が機密情報を含むベアラ資格証明が発行または要求された場合、または1つ以上のセッションで2つ以上のベアラ資格証明を組み合わせた場合に相関付けのリスクがあるならば、警告を出すべきです。すべての相関付けのリスクを検出することは不可能かもしれませんが、一部は確実に検出できる可能性があります。
この項は非規範的です。
検証可能な資格証明を処理する場合、検証者は、付録A. 妥当性検証に記載されているチェックの多くと、様々な特定の事業プロセスのチェックを実行することが期待されます。妥当性チェックには、次のチェックが含まれる場合があります。
これらのチェックを行う過程で、保有者のプライバシー侵害につながる情報漏洩が発生する可能性があります。例えば、失効リストのチェックのような簡単な操作で、特定の事業者が保有者とインタラクションを行っている可能性が高いことを発行者に通知できてしまいます。これにより、発行者が知らないうちに結託し、個人を相関付けることができる可能性があります。
発行者は、プライバシー侵害につながる可能性のある検証プロセス中に、資格証明失効リストなど、資格証明ごとに一意なメカニズムを用いないようにすることをお勧めします。保有者にソフトウェアを提供する組織は、検証プロセス中にプライバシー侵害につながる可能性のある情報が資格証明に含まれている場合に警告を出すべきです。検証者は、プライバシー侵害をもたらす、または不適切なプライバシー慣行を可能にする資格証明を拒否することを検討すべきです。
この項は非規範的です。
保有者が発行者から検証可能な資格証明を受け取った場合、その検証可能な資格証明をどこか(例えば、資格証明リポジトリ)に格納する必要があります。保有者は、検証可能な資格証明内の情報は本質的に機密性が高く、高度に個別化されているため、データ・マイニングの価値の高いターゲットになることに注意してください。検証可能な資格証明の無料ストレージについて宣伝を行っているサービスは、実際には個人データをマイニングし、個人や組織に関する個別のプロファイルを構築したい組織にそれを販売している可能性があります。
保有者は、自身の資格証明リポジトリのサービス条件、特に検証可能な資格証明をサービス・プロバイダに保存する者のために実施されている相関付けとデータ・マイニングの保護について認識している必要があります。
データ・マイニングとプロファイリングに対する効果的な緩和策には、次を用いるのものがあります。
この項は非規範的です。
同じサブジェクトに関する2つの情報を保有すると、情報が異なるチャネルを通じて配信される場合でも、ほとんどの場合、2つの情報を合わせたものよりもサブジェクトに関してより詳細が明らかになります。検証可能な資格証明の集約はプライバシーのリスクであり、エコシステムのすべての参加者はデータ集約のリスクを認識する必要があります。
例えば、1つは電子メール・アドレス用で、もう1つは保有者が21歳以上であることを示す2つのベアラ資格証明が複数のセッションで提供される場合、情報の検証者はその個人の年齢に関する情報だけでなく一意な識別子も持つようになります。保有者のプロファイルを簡単に作成し構築できるようになり、時間の経過とともにより多くの情報が漏洩することになります。資格証明の集約は、複数のサイト間で互いに結託して行われることもあり、プライバシー侵害につながる可能性があります。
技術的な観点から見ると、情報の集約を防止することは、対処が非常に難しいプライバシー問題です。集約と相関付けの問題に対する解決策として、ゼロ知識証明などの新しい暗号技術が提案されていますが、長期間有効な識別子やブラウザの追跡技術の存在は、最新の暗号技術でさえ打ち負かしてしまいます。
相関付けや集約のプライバシーへの影響に対する解決策は、本質的に技術的なものではなく、方針に動機付けられたものである傾向があります。したがって、保有者が自身に関する情報が集約されることを望まない場合は、送信する検証可能なプレゼンテーションでそれを表現する必要があります。
この項は非規範的です。
プライバシーを保証するために最善の努力を行っても、実際に検証可能な資格証明を用いると、匿名化が解除されてプライバシーが失われる可能性があります。この相関付けは、次のケースで発生する可能性があります。
次の方法により、部分的に、この非匿名化とプライバシーの損失を緩和することができます。
これらの緩和技術は、常に実用的であるとは限らず、必要な用途に適合するものでもないと理解されています。相関付けが必要な場合もあります。
例えば、一部の処方薬監視プログラムでは、使用状況の監視が必須です。執行機関は、個人が規制薬物の処方を複数受けるためにシステムを不正に利用していないことを確認できる必要があります。この、使用の相関付けを行う法的または規制上の必要性は、個人のプライバシーに関する懸念よりも優先されます。
検証可能な資格証明は、例えば共通の人物像を用いて複数のサービスにログインし、各サービス上のすべてのアクティビティを意図的に同じ個人にリンクさせるなど、サービス間で個人を意図的に相関付けるためにも用いられます。これは、これらの各サービスが予期される方法で相関関係を用いている限り、プライバシーの問題とはなりません。
資格証明の使用によるプライバシーのリスクは、資格証明のプレゼンテーションから意図しない、または予期しない相関付けが生じたときに発生します。
この項は非規範的です。
保有者が検証者と情報を共有することを選択した場合、検証者が不誠実に行動し、保有者に危害を加えるために使用できる情報を要求することがあり得ます。例えば、検証者が銀行の口座番号を要求する可能性があり、これは、保有者や銀行から詐取を行うために他の情報と一緒に用いられる可能性があります。
発行者は、保有者が誤って間違った検証者に資格証明を送信した場合に、壊滅的な状況にならないように、できる限り多くの情報をトークン化するよう努めるべきです。
例えば、個人の銀行残高をチェックする目的で銀行口座番号を含めるのではなく、残高が一定額以上かどうかを検証者がチェックできるようにするトークンを提供します。この場合、銀行は、残高チェック・トークンを含む検証可能な資格証明を保有者に発行できます。次に、保有者は、検証可能な資格証明を検証可能なプレゼンテーションに含め、デジタル署名を用いてトークンを信用チェック機関にバインドします。検証者は、検証可能なプレゼンテーションをデジタル署名でラップし、それを発行者に戻して、口座残高を動的にチェックできます。
このアプローチを用いると、保有者が口座残高トークンを間違った相手と共有したとしても、攻撃者は銀行の口座番号や口座の正確な値を発見できません。また、副署名の有効期限を前提とすると、数分間以上トークンにアクセスすることはできません。
この項は非規範的です。
7.13 使用パターンの項で詳細に説明したように、使用パターンはある種の動作に相関付けることができます。この相関付けの一部は、保有者が発行者の知らないうちに検証可能な資格証明を用いる場合に緩和されます。しかし、発行者は、検証可能な資格証明の有効期間を短くし、更新を自動化することで、この保護を破ることができます。
例えば、ageOverという検証可能な資格証明は、バーへのアクセスを得るのに有用です。発行者がこのような検証可能な資格証明を非常に短い有効期限と自動更新メカニズムで発行すると、発行者は、保有者に悪影響を与える方法で保有者の行動を相関付ける可能性があります。
保有者にソフトウェアを提供する組織は、保有者が短い有効期限の資格証明を繰り返し用いている場合、行動の相関付けをもたらす可能性があるため、警告を出すべきです。発行者は、使用パターンを相関付けることができるような方法で資格証明を発行することを避けるべきです。
この項は非規範的です。
プライバシーを尊重する理想的なシステムは、検証者とのインタラクションに必要な情報のみを保有者が開示することを要求します。その後、検証者は、開示要求が満たされたことを記録し、開示された機密情報のことは忘れるでしょう。多くの場合、規制の負担などの競合する優先事項が、この理想的なシステムの採用を妨げています。長期有効な識別子が、1回限りの使用を妨げる場合もあります。しかし、検証可能な資格証明エコシステムの設計は、可能な限り1回限りの検証可能な資格証明を優先することにより、可能な限りプライバシーを尊重するように努めるべきです。
1回限りの検証可能な資格証明を用いると、いくつかの利点が得られます。最初の利点は、検証者にとってのもので、検証可能な資格証明内のデータが新しいことを確認できます。2番目の利点は、保有者にとってのもので、検証可能な資格証明に長期有効な識別子がなければ、検証可能な資格証明自体を用いてオンラインで追跡したり相関付けることができないことが分かります。最後に、攻撃者が盗むものは何もないため、エコシステム全体をより安全に運用できます。
この項は非規範的です。
理想的なプライベート・ブラウジングのシナリオでは、PIIは公開されません。多くの資格証明にはPIIが含まれているため、保有者にソフトウェアを提供する組織は、プライベート・ブラウジング・モードで資格証明およびプレゼンテーションを用いたい場合に、この情報が漏洩する可能性があることを警告すべきです。ブラウザのベンダーによってプライベート・ブラウジングの扱いが異なり、この機能がまったくないブラウザもあるため、実装者はこれらの違いを認識し、それに応じて解決策を実装することが重要です。
この項は非規範的です。
検証可能な資格証明が発行者に対する高度な信頼に依存していることは、強調してもし過ぎることはありません。保有者が可能なプライバシー保護をどの程度利用できるかは、多くの場合、発行者がそのような機能に対して提供するサポートに大きく依存します。多くの場合、ゼロ知識証明、データ最小化技術、ベアラ資格証明、抽象的なクレーム、および署名ベースの相関付けに対する保護を利用するプライバシー保護では、発行者がそのような機能を積極的にサポートし、発行する検証可能な資格証明にそれを組み込む必要があります。
保有者とサブジェクトのプライバシーの保護に役立つ検証可能な資格証明機能を提供するために発行者の関与に依存することに加えて、保有者は、発行者がプライバシー保護を意図的に覆さないことに依存していることにも注意する必要があります。例えば、発行者は、署名ベースの相関付けから保護する署名スキームを用いて、検証可能な資格証明に署名する場合があります。これは、署名の値が検証者間で共有されるため、署名の値によって保有者が相関付けられることを防ぎます。しかし、発行者が発行された資格証明ごとに一意な鍵を作成すると、検証者がそれを実行できない場合でも、発行者が資格証明のプレゼンテーションを追跡できる可能性があります。
この項は非規範的です。
この仕様で記述しているデータを処理する際に、発行者、保有者、検証者が認識しておくべきセキュリティに関する留意点が多数あります。この項の意味を無視したり理解しなかったりすると、セキュリティ上の脆弱性が生じる可能性があります。
この項では、セキュリティに関する広範な留意点を浮き彫りにしようと試みていますが、完全なリストではありません。実装者がこの仕様で概説している技術を用いてミッション・クリティカルなシステムを実装する場合は、セキュリティと暗号の専門家に助言を求めることをお勧めします。
この項は非規範的です。
この仕様で説明しているデータ・モデルの一部の側面は、暗号を用いて保護できます。実装者は、資格証明およびプレゼンテーションの作成と処理に用いられる暗号スイートとライブラリを理解することが重要です。一般に、暗号システムの実装と監査には、かなりの経験が必要です。効果的なレッド・チーム(red team)は、セキュリティ・レビューからバイアスを取り除くのにも役立ちます。
暗号スイートとライブラリには有効期間があり、最終的には新たな攻撃や技術の進歩に追いつかれます。製品品質システムはこれを考慮し、有効期限切れまたは壊れた暗号スイートとライブラリを簡単かつ事前にアップグレードし、既存の資格証明を無効にして置き換えるメカニズムが存在することを確認する必要があります。資格証明を処理するシステムの長期的な実行可能性を確保するためには、定期的な監視が重要です。
この項は非規範的です。
検証可能な資格証明には、検証可能な資格証明自体の外部に存在するデータのURLが含まれていることがよくあります。画像、JSON-LDコンテキスト、その他の機械可読データなどの検証可能な資格証明の外部に存在するリンクされたコンテンツは、データが検証可能な資格証明の証明の保護の外部に存在するため、しばしば改ざんから保護されないことがあります。例えば、次の強調表示されたリンクはコンテンツの完全性が保護されていませんが、おそらく保護されているでしょう。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/58473",
"type": ["VerifiableCredential", "AlumniCredential"],
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"image": "https://example.edu/images/58473",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Universite",
"lang": "fr"
}]
}
},
"proof": { ... }
}
この仕様では、特定のコンテンツの完全性の保護を推奨していませんが、コンテンツへのリンクの完全性が保護されていることを確保したいドキュメントの作成者は、コンテンツの完全性を強制するURLスキームを用いることをお勧めします。このようなスキームには、[HASHLINK]仕様と[IPFS]の2つがあります。次の例は、前の例を変えて、[HASHLINK]仕様を用いてコンテンツの完全性保護をJSON-LDコンテキストに追加し、[IPFS]リンクを用いて画像にコンテンツの完全性保護を追加しています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1?hl=z3aq31uzgnZBuWNzUB",
"https://www.w3.org/2018/credentials/examples/v1?hl=z8guWNzUBnZBu3aq31"
],
"id": "http://example.edu/credentials/58473",
"type": ["VerifiableCredential", "AlumniCredential"],
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"image": "ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Universite",
"lang": "fr"
}]
}
},
"proof": { ... }
}
上記のJSON-LDコンテキストの保護が必要かどうかは議論の余地があります。なぜなら、実稼働の実装では、重要なJSON-LDコンテキストの静的なコピーが付属していると予想されるためです。
上の例は、コンテンツの完全性保護を実現する方法の1つですが、特定のアプリケーションにより適した解決策が他にもあります。実装者は、コンテンツの完全性が保護されていない外部の機械可読コンテンツへのリンクが、どのように自身のアプリケーションに対する攻撃を成功させる可能性があるかを理解する必要があります。
この項は非規範的です。
この仕様では、いかなる種類の署名や資格証明も含まない資格証明を作成することができます。この種の資格証明は、中間ストレージ、またはウェブ・ページ上のフォームへの入力に似た、自己言明の情報に有用であることがよくあります。実装者は、この種の資格証明は、原作者が不明であるか信頼できないため、検証可能ではないことに注意すべきです。
この項は非規範的です。
検証者は、検証可能なプレゼンテーションの意図された受信者であり、中間者攻撃の対象ではないことを確認する必要がある場合があります。トークン・バインディング[RFC8471]などのアプローチは、検証可能なプレゼンテーションの要求を応答に結び付け、プロトコルを保護することができます。保護されていないプロトコルは、中間者攻撃の影響を受けやすくなります。
この項は非規範的です。
発行者が、資格証明内の情報を細分化するか、選択的開示を可能にする署名スキームを用いることがベスト・プラクティスと考えられています。細分化を行う場合は、発行者が安全に行わないと、発行者の意図しない方法で保有者が異なる資格証明をバンドルする可能性があります。
例えば、ある大学が1人の個人に2つの検証可能な資格証明を発行し、それぞれに2つのプロパティーが含まれている場合、それらを組み合わせて、「コンピュータ学部」の「職員」、「経済学部」の「大学院生」など、特定の「学部」におけるその人物の「役割」を指定しなければなりません。これらの検証可能な資格証明を細分化して、そのプロパティーの1つだけを個々の資格証明に含めると、大学はその者に4つの資格証明を発行し、それぞれに「職員」、「大学院生」、「コンピュータ部門」、および「経済学部」の指定の1つが含まれることになるでしょう。その後、保有者は、「職員」と「経済学部」の検証可能な資格証明を検証者に転送する可能性があり、これらを合わせることで虚偽のクレームとなります。
この項は非規範的です。
検証可能な資格証明が高度に動的な情報に対して発行される場合、実装者は、有効期限が適切に設定されていることを確保すべきです。有効期限が、検証可能な資格証明が有効である時間枠よりも長い場合、悪用可能なセキュリティの脆弱性が発生する可能性があります。有効期限が、検証可能な資格証明によって表される情報が有効である時間枠よりも短い場合、保有者と検証者に負担をもたらします。したがって、ユースケースに適した検証可能な資格証明の有効期限と、検証可能な資格証明に含まれる情報の予想される存続期間を設定することが重要です。
この項は非規範的です。
検証可能な資格証明がデバイスに保存されていて、そのデバイスが紛失や盗難にあった場合、攻撃者は被害者の検証可能な資格証明を用いてシステムにアクセスできる可能性があります。この種の攻撃を緩和する方法には、次のものがあります。
この項は非規範的です。
この仕様で記述しているデータを処理する際に、実装者が認識しておくべきアクセシビリティに関する留意点が数多くあります。あらゆるウェブ標準やプロトコルの実装と同様に、アクセシビリティの問題を無視すると、この情報を多くの人が使用できなくなります。能力に関係なくすべての人がこのデータを利用できることを確保するためには、[WCAG21]などのアクセシビリティのガイドラインや標準に従うことが重要です。これは、歴史的に支援技術に問題を引き起こしてきた暗号を用いたシステムを確立する場合に特に重要です。
この項では、このデータ・モデルを利用する際に考慮すべき一般的なアクセシビリティに関する留意点について詳細に説明します。
この項は非規範的です。
政府のIDカードなど、現在用いられている多くの物理的な資格証明は、印字が小さい、小さくて解像度の高い画像に依存している、視覚障害者のためのアフォーダンスがないなど(これらに限定されない)、アクセシビリティ特性が貧弱です。
このデータ・モデルを用いて検証可能な資格証明を作成する場合、データ・モデルの設計者はデータ優先のアプローチを用いることをお勧めします。例えば、資格証明を表すためにデータもしくはグラフィックな画像を用いるという選択肢がある場合、設計者は、閲覧者の画像の解釈に依存してこの情報を伝えるのではなく、機関名や専門職の資格証明など、画像のすべての要素を機械可読な方法で表すべきです。データ優先のアプローチを用いると、様々な能力を持つ人々のために様々なインターフェースを構築するための基礎となる要素が提供されるため、好ましいです。
この項は非規範的です。
実装者は、この仕様で記述しているデータを公開する際に、多くの国際化に関する留意点に注意することをお勧めします。あらゆるウェブ標準やプロトコルの実装と同様に、国際化を無視すると、異なる言語や社会の間でデータを生成し利用することが難しくなり、仕様の適用範囲が制限され、標準としての価値が著しく低下します。
実装者は、W3C国際化アクティビティが公表しているウェブ上の文字列: 言語と方向のメタデータ・ドキュメント[STRING-META]を読むことを強くお勧めします。これは、国際化をサポートするためにテキストに関する信頼できるメタデータを提供する必要性について詳細に説明しています。国際化に関する留意点に関する最新情報については、実装者は検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントを読むことも強くお勧めします。
この項は、このデータ・モデルを利用する際に考慮すべき一般的な国際化に関する留意点について概説しており、実装者が読むことに関心を持つ可能性がある、ウェブ上の文字列: 言語と方向のメタデータ・ドキュメント[STRING-META]の特定部分を強調することを目的としています。
この項は非規範的です。
データの発行者は、ウェブ上の文字列: 言語と方向のメタデータ・ドキュメント[STRING-META]のクロス・シンタックス表現に関する項を読んで、[JSON-LD]、[JSON]、CBOR[RFC7049]などの複数の表現構文で言語と基本書字方向の情報の表現が可能であることを確保することを強くお勧めします。
一般的な設計パターンでは、言語と、オプションで特定の基本書字方向を用いてタグ付けされたテキストの文字列を表現する際に、次のマークアップ・テンプレートを用います。
"property": { "value": "The string value", "lang": "LANGUAGE" "dir": "DIRECTION" }
上記の設計パターンを用いて、次の例では、テキストの方向を指定せずに、本のタイトルを英語で表現しています。
"title": {
"value": "HTML and CSS: Designing and Creating Websites",
"lang": "en"
}
次の例は、同様のタイトルを、基本書字方向を右から左にしてアラビア語で表現しています。
"title": {
"value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"lang": "ar"
"dir": "rtl"
}
多くのシステムは、テキストの文字列の最初の文字を用いてテキストの方向を決定するため、言語と方向を明示的に表現しないと、上記のテキストは、左から右へと誤って表示される可能性が最も高いです。
JSON-LDを利用する実装者は、国際化されたプロパティーを定義するJSON-LDコンテキストを拡張し、JSON-LDの範囲付きコンテキスト機能を用いて、@value、@language、@directionのキーワードを、それぞれvalue、lang、dirにエイリアスすることを強くお勧めします。これを行うJSON-LD Contextのスニペットの例を次に示します。
"title": {
"@context": {"value": "@value", "lang": "@language", "dir": "@direction"},
"@id": "https://www.w3.org/2018/credentials/examples#title"
}
この項は非規範的です。
複数の言語、基本書字方向、注釈を1つの自然言語の文字列で用いる場合は通常、より複雑なメカニズムが必要です。HTMLなどのマークアップ言語を用いて、複数の言語と基本書字方向でテキストをエンコードすることができます。rdf:HTMLデータ型を用いて、そのような値をJSON-LDで正確にエンコードすることもできます。
情報をHTMLとしてエンコードする能力があるにもかかわらず、次の理由により、実装者はこれを行うことを強くお勧めしません。
scriptタグが実行される可能性があるため、セキュリティの攻撃対象が増加します。実装者が、特定のユースケースに対処するために、HTMLや実行可能なスクリプトを含むことができるその他のマークアップ言語を用いる必要があると感じた場合、攻撃者がマークアップを用いてマークアップの利用者に対してインジェクション攻撃を仕掛ける方法を分析し、特定された攻撃に対する緩和策を展開することをお勧めします。
この項は非規範的です。
この仕様では、検証可能な資格証明または検証可能なプレゼンテーションの妥当性検証プロセスに対する適合性基準を規定しませんが、読者は、妥当性検証プロセス中に検証者がこのデータ・モデル内の情報をどのように利用することが期待されているかに興味を持つかもしれません。この項では、検証者によるこの仕様のデータ・フィールドの予想される使用法に関連してワーキンググループが行った会話を抜粋して紹介します。
この項は非規範的です。
保有者が提示する検証可能な資格証明では、credentialSubject(資格証明サブジェクト)ごとにidプロパティーに関連付けられている値が、検証者に対するサブジェクトを識別することが期待されます。保有者がサブジェクトでもある場合、検証者は、保有者に関する公開鍵メタデータを持っていれば、保有者を認証できます。検証者は、検証可能なプレゼンテーションに含まれる、保有者が生成した署名を用いて保有者を認証できます。idプロパティーはオプションです。検証者は、検証可能な資格証明の他のプロパティーを用いて、サブジェクトを一意に識別できます。
認証とWebAuthnが検証可能な資格証明でどのように機能するかについての情報は、検証可能な資格証明実装ガイドライン[VC-IMP-GUIDE]ドキュメントを参照してください。
この項は非規範的です。
issuer(発行者)プロパティーに関連付けられている値は、検証者に認識され、信頼されている発行者を識別することが期待されます。
issuerプロパティーに関する関連メタデータを、検証者が利用できることが期待されます。例えば、発行者は、発行した検証可能な資格証明にデジタル署名を行うために用いる公開鍵が含まれている情報を公開できます。このメタデータは、検証可能な資格証明の証明をチェックするときに関連するものです。
この項は非規範的です。
issuanceDate(発行日)は、検証者の想定範囲内にあることが期待されます。例えば、検証者は、検証可能な資格証明の発行日が未来でないことをチェックできます。
この項は非規範的です。
検証可能な資格証明または検証可能なプレゼンテーションの情報が改ざんされていないことを証明するために用いる暗号メカニズムを証明と呼びます。暗号証明には、デジタル署名、ゼロ知識証明、プルーフ・オブ・ワーク、プルーフ・オブ・ステークなど、多くの種類があります(これらに限定されない)。一般に、証明の検証を行う場合、実装は次のことを確保することが期待されます。
一部の証明はデジタル署名です。一般に、デジタル署名を検証する場合、実装は次のことを保証することが期待されます。
proofPurposeプロパティーを期待する場合は、それが存在し、assertionMethodなどの有効な値であることが期待されること。デジタル署名は、改ざん耐性以外の、一見したところでは分かりにくい多くの保護を提供します。例えば、リンクト・データ署名のcreatedプロパティーは、それ以前に資格証明が検証されたと見なすべきではない日付と時刻を確立します。例えば、verificationMethodプロパティーは、デジタル署名の検証に使用できる公開鍵を規定します。公開鍵のURLを逆参照すると、鍵の管理者に関する情報が明らかになり、資格証明の発行者と照合することができます。proofPurposeプロパティーは、証明の目的を明確に表し、この情報が署名によって保護されることを保証します。証明は通常、認証目的のために検証可能なプレゼンテーションに添付され、アサーションの方法として検証可能な資格証明に添付されます。
この項は非規範的です。
expirationDate(有効期限)は、検証者の想定範囲内にあることが期待されます。例えば、検証者は、検証可能な資格証明の有効期限が過去でないことをチェックできます。
この項は非規範的です。
credentialStatusプロパティーが利用できる場合、検証可能な資格証明のステータスは、検証可能な資格証明のcredentialStatus型の定義と検証者独自のステータスの評価基準に従って、検証者が評価することが期待されます。例えば、検証者は、検証可能な資格証明のステータスが「発行者による理由で撤回」されていないことを確保できます。
この項は非規範的です。
目的適合性とは、検証可能な資格証明内の特注のプロパティーが検証者の目的に適しているかどうかに関するものです。例えば、サブジェクトが21歳以上かどうかを検証者が判断する必要がある場合、特定のbirthdateプロパティーに依存するか、ageOverなどのより抽象的なプロパティーに依存する可能性があります。
発行者は、検証者から信頼されて、目下のクレームを行います。例えば、ファースト・フード・レストランのフランチャイズ店は、そのフランチャイズの本社が発行する割引クーポンのクレームを信頼します。保有者と検証者は、発行者が検証可能な資格証明で表す方針情報を、その方針を無視した場合に責任を受け入れないのならば、尊重すべきです。
この項は非規範的です。
この項は非規範的です。
ベース・コンテキストは、https://www.w3.org/2018/credentials/v1にあり、SHA-256 ダイジェストはab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdccで、ローカルにキャッシュされたコピーを実装するために使用できます。便宜上、ベース・コンテキストもこの項で提供しています。
{
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"VerifiableCredential": {
"@id": "https://www.w3.org/2018/credentials#VerifiableCredential",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"cred": "https://www.w3.org/2018/credentials#",
"sec": "https://w3id.org/security#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"credentialSchema": {
"@id": "cred:credentialSchema",
"@type": "@id",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"cred": "https://www.w3.org/2018/credentials#",
"JsonSchemaValidator2018": "cred:JsonSchemaValidator2018"
}
},
"credentialStatus": {"@id": "cred:credentialStatus", "@type": "@id"},
"credentialSubject": {"@id": "cred:credentialSubject", "@type": "@id"},
"evidence": {"@id": "cred:evidence", "@type": "@id"},
"expirationDate": {"@id": "cred:expirationDate", "@type": "xsd:dateTime"},
"holder": {"@id": "cred:holder", "@type": "@id"},
"issued": {"@id": "cred:issued", "@type": "xsd:dateTime"},
"issuer": {"@id": "cred:issuer", "@type": "@id"},
"issuanceDate": {"@id": "cred:issuanceDate", "@type": "xsd:dateTime"},
"proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},
"refreshService": {
"@id": "cred:refreshService",
"@type": "@id",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"cred": "https://www.w3.org/2018/credentials#",
"ManualRefreshService2018": "cred:ManualRefreshService2018"
}
},
"termsOfUse": {"@id": "cred:termsOfUse", "@type": "@id"},
"validFrom": {"@id": "cred:validFrom", "@type": "xsd:dateTime"},
"validUntil": {"@id": "cred:validUntil", "@type": "xsd:dateTime"}
}
},
"VerifiablePresentation": {
"@id": "https://www.w3.org/2018/credentials#VerifiablePresentation",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"cred": "https://www.w3.org/2018/credentials#",
"sec": "https://w3id.org/security#",
"holder": {"@id": "cred:holder", "@type": "@id"},
"proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},
"verifiableCredential": {"@id": "cred:verifiableCredential", "@type": "@id", "@container": "@graph"}
}
},
"EcdsaSecp256k1Signature2019": {
"@id": "https://w3id.org/security#EcdsaSecp256k1Signature2019",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"challenge": "sec:challenge",
"created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
"domain": "sec:domain",
"expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
"jws": "sec:jws",
"nonce": "sec:nonce",
"proofPurpose": {
"@id": "sec:proofPurpose",
"@type": "@vocab",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
"authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
}
},
"proofValue": "sec:proofValue",
"verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
}
},
"EcdsaSecp256r1Signature2019": {
"@id": "https://w3id.org/security#EcdsaSecp256r1Signature2019",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"challenge": "sec:challenge",
"created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
"domain": "sec:domain",
"expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
"jws": "sec:jws",
"nonce": "sec:nonce",
"proofPurpose": {
"@id": "sec:proofPurpose",
"@type": "@vocab",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
"authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
}
},
"proofValue": "sec:proofValue",
"verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
}
},
"Ed25519Signature2018": {
"@id": "https://w3id.org/security#Ed25519Signature2018",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"challenge": "sec:challenge",
"created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
"domain": "sec:domain",
"expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
"jws": "sec:jws",
"nonce": "sec:nonce",
"proofPurpose": {
"@id": "sec:proofPurpose",
"@type": "@vocab",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
"authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
}
},
"proofValue": "sec:proofValue",
"verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
}
},
"RsaSignature2018": {
"@id": "https://w3id.org/security#RsaSignature2018",
"@context": {
"@version": 1.1,
"@protected": true,
"challenge": "sec:challenge",
"created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
"domain": "sec:domain",
"expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
"jws": "sec:jws",
"nonce": "sec:nonce",
"proofPurpose": {
"@id": "sec:proofPurpose",
"@type": "@vocab",
"@context": {
"@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
"sec": "https://w3id.org/security#",
"assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
"authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
}
},
"proofValue": "sec:proofValue",
"verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
}
},
"proof": {"@id": "https://w3id.org/security#proof", "@type": "@id", "@container": "@graph"}
}
}この項は非規範的です。
検証可能な資格証明および検証可能なプレゼンテーションのデータ・モデルは、[JSON-LD]と[JSON-SCHEMA-2018]を含む様々な基礎技術を活用します。この項では、@context(@コンテキスト)、type(型)、およびcredentialSchema(資格証明スキーマ)のプロパティーの比較を行い、データ・モデルのこれらの機能を使用できる、より具体的なユースケースをいくつか取り上げます。
typeプロパティーは、それが出現する検証可能な資格証明の型を一意に識別するために用いられます。つまり、検証可能な資格証明に含まれるクレームの集合を示すためのものです。このプロパティーと、その値の集合内の値であるVerifiableCredentialは必須です。この検証可能な資格証明の一意なサブタイプを示す追加の値を1つ含むことは良い実践ですが、配列に追加の型の値を省略したり含めたりすることは認められています。多くの検証者は、特定のサブタイプの検証可能な資格証明を要求しますが、サブタイプの値を省略すると、検証者が要求する検証可能な資格証明を保有者に通知することが難しくなる可能性があります。検証可能な資格証明に複数のサブタイプがある場合は、それらすべてをtypeプロパティーに列挙するのが賢明です。セマンティクスは[JSON]と[JSON-LD]のどちらの表現でも同じですが、検証可能な資格証明の[JSON-LD]表現でtypeプロパティーを用いると、機械がセマンティクスをチェックできるため、同じ資格証明の[JSON]表現よりも検証可能な資格証明のセマンティクスを強化することができます。[JSON-LD]では、この技術は、クレームの集合の分類を記述するだけでなく、グラフ内のプロパティーのサブグラフの構造とセマンティクスも伝えます。[JSON-LD]では、これはグラフ内のノードの型を表し、検証可能な資格証明の一部の[JSON-LD]表現が検証可能な資格証明内の多くのオブジェクトでtypeプロパティーを用いるのはそのためです。
[JSON-LD]の観点から見た@contextプロパティーの主な目的は、検証可能な資格証明のデータの意味と用語定義を機械可読な方法で伝えることです。純粋な[JSON]表現をエンコードする場合、@contextプロパティーは必須のままであり、グローバルなセマンティクスに対する何らかの基本的なサポートを提供します。@contextプロパティーは、検証可能な資格証明および検証可能なプレゼンテーションのプロパティーに対するグローバルに一意なURIを短い形式のエイリアス名にマッピングするために用いて、[JSON]と[JSON-LD]の両方の表現をより人間に読みやすくします。[JSON-LD]の観点からは、このマッピングは、検証可能な資格証明または検証可能なプレゼンテーションのデータをより大きな機械可読データ・グラフに関連付ける方法を強化することにより、資格証明内のデータを機械可読データのネットワークでモデル化することも可能にします。これは、関係者間で調整を行えないエコシステムにおいて、データの意味を他のデータに関連付ける方法を機械に伝えるのに有用です。集合内の最初の値がhttps://www.w3.org/2018/credentials/v1であるこのプロパティーは必須です。
@contextプロパティーはデータをグラフ・データ・モデルにマッピングするために用い、[JSON-LD]のtypeプロパティーはグラフ内のノードを記述するために用いるため、2つのプロパティーを組み合わせて用いる場合、typeプロパティーはさらに重要になります。例えば、typeプロパティーが、[JSON-LD]を用いて解決された@context資源内に含まれていない場合、検証可能な資格証明の作成および利用中にクレームが削除される、および/またはその完全性が保護されなくなる可能性があります。あるいは、検証可能な資格証明の作成または利用中にエラーが発生する可能性があります。これは実装の設計上の選択に依存し、今日の実装ではどちらのパスも用いられているため、検証可能な資格証明または検証可能なプレゼンテーションの[JSON-LD]表現を用いる場合は、これらのプロパティーに注意を払うことが重要です。
credentialSchemaプロパティーの主な目的は、検証可能な資格証明の構造と、出現する各プロパティーの値のデータ型を定義することです。credentialSchemaは、検証可能な資格証明内のクレームの集合の内容と構造を定義するのに有用ですが、検証可能な資格証明内の[JSON-LD]と@contextは、データのセマンティクスと用語定義を伝えるためにのみ用いるのに最も適しており、検証可能な資格証明の構造を定義するためにも使用できます。
一部の[JSON-LD]機能を用いて検証可能な資格証明の内容を暗示することはできますが、@contextを用いてデータ・モデルのデータ型を制約することは一般的に推奨されません。例えば、"@type": "@json"は、セマンティクスを制約せず、厳密に定義しない場合に有用です。これは、実装者が資格証明内のクレームのデータ型を制約しようとしている場合には危険でありえ、使用しないことが期待されます。
credentialSchemaと@contextのプロパティーを組み合わせて用いると、プロデューサとコンシューマの両方が、検証可能な資格証明および検証可能なプレゼンテーションの期待される内容とデータ型について、より確信を持つことができるようになります。
この項は非規範的です。
この項では、サブジェクトと保有者の間の想定される関係と、検証可能な資格証明データ・モデルがこれらの関係を表す方法について説明します。次の図は、これらの関係を示しており、後続の項で、これらの関係のそれぞれがデータ・モデルでどのように処理されるかを説明します。
この項は非規範的です。
最も一般的な関係は、サブジェクトが保有者である場合です。この場合、検証者は、検証可能なプレゼンテーションが保有者によってデジタル署名されており、含まれているすべての検証可能な資格証明が、その保有者と同じであると識別できるサブジェクトに関するものであれば、そのサブジェクトは保有者であると容易に推測できます。
credentialSubjectのみが検証可能な資格証明を検証可能なプレゼンテーションに挿入できる場合、発行者は、以下で説明するように、nonTransferableプロパティーを検証可能な資格証明に挿入できます。
この項は非規範的です。
nonTransferable(譲渡不可)プロパティーは、検証可能な資格証明がcredentialSubjectによって発行された証明を持つ検証可能なプレゼンテーションにのみカプセル化されなければならないことを示します。nonTransferableプロパティーが含まれている検証可能な資格証明を含んでいる検証可能プレゼンテーションは、その証明の作成者がcredentialSubjectでない場合、無効です。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "ProofOfAgeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 21
},
"nonTransferable": true,
"proof": { ..
"verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21",
... }
}
この項は非規範的です。
この場合、credentialSubjectプロパティーには複数のプロパティーが含まれている可能性があり、それぞれがサブジェクトの記述内容の一側面を提供し、それらを組み合わせてサブジェクトを明確に識別します。ユースケースによっては、医師(サブジェクト)が認定医であるかどうかをチェックするなど、保有者を識別する必要がまったくない場合もあります。その他のユースケースでは、検証者が帯域外の知識(out-of-band knowledge)を用いて、サブジェクトと保有者の関係を判断する必要がある場合があります。
{
"@context": ["https://www.w3.org/2018/credentials/v1", "https://schema.org/"]
"id": "http://example.edu/credentials/332",
"type": ["VerifiableCredential", "IdentityCredential"],
"issuer": "https://example.edu/issuers/4",
"issuanceDate": "2017-02-24T19:73:24Z",
"credentialSubject": {
"name": "J. Doe",
"address": {
"streetAddress": "10 Rue de Chose",
"postalCode": "98052",
"addressLocality": "Paris",
"addressCountry": "FR"
},
"birthDate": "1989-03-15"
...
},
"proof": { ... }
}
上の例では、個人の名前、住所、生年月日を用いてサブジェクトを一意に識別しています。
この項は非規範的です。
通常、検証可能な資格証明は、サブジェクトによって検証者に提示されます。しかし、場合によっては、サブジェクトが検証可能な資格証明の全部または一部を別の保有者に渡す必要がある場合があります。例えば、患者(サブジェクト)が病気で処方箋(検証可能な資格証明)を薬剤師(検証者)に持って行くことができない場合に、友人が処方箋を持って薬を受け取に行く場合があります。
データ・モデルは、サブジェクトが新しい検証可能な資格証明を発行して、それを新しい保有者に渡し、その後でその保有者が両方の検証可能な資格証明を検証者に提示できるようにすることで、これを可能とします。ただし、この2番目の検証可能な資格証明の内容はアプリケーション固有のものである可能性が高いため、この仕様では、この2番目の検証可能な資格証明の内容を標準化することはできません。それにもかかわらず、非規範的な例を付録C.5 サブジェクトが検証可能な資格証明を他人に渡す場合で提供しています。
この項は非規範的です。
検証可能な資格証明データ・モデルは、少なくとも次の方法で保有者がサブジェクトを代理するのをサポートします。
credentialSubjectプロパティーに含めることができる。上に挙げたメカニズムは、保有者とサブジェクトの間の関係を記述し、検証者が特定のユースケースに対してその関係が十分に表されているかどうかを判断するのに役立ちます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "AgeCredential", "RelationshipCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageUnder": 16,
"parent": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"type": "Mother"
}
},
"proof": { ... } // 証明書はDMVで生成される
}
上の例では、発行者は、子供または親が資格証明を提供した場合に、検証者がそれを受け入れる可能性が最も高くなるように子供と親との関係を表しています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"child": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "Child"
}
},
"proof": { ... } // 証明書はDMVで生成される
}
上の例では、発行者は、子供が資格証明を提供した場合、または上記の資格証明が子供の資格証明と共に提供された場合に、検証者が子供の資格証明を受け入れる可能性が最も高くなるように子供と親との関係を別の資格証明で表しています。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.org/credentials/23894",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "http://example.org/credentials/23894",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"parent": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"type": "Mother"
}
},
"proof": { ... } // 証明は子供によって生成される
}
上の例では、子供は、上記の資格証明が提供された場合に、検証者が子供の資格証明を受け入れる可能性が最も高くなるように子供と親との関係を別の資格証明で表しています。
同様に、上の例で説明した戦略は、委任状、ペットの所有権、患者の処方箋の受け取りなど、他の多くの種類のユースケースに使用できます。
この項は非規範的です。
サブジェクトが検証可能な資格証明を別の保有者に渡す場合に、サブジェクトは、次に該当する新しい検証可能な資格証明をその保有者に発行する可能性があります。
これで、保有者は、これら2つの検証可能な資格証明を含んだ検証可能なプレゼンテーションを作成できるようになったため、検証者は、サブジェクトが元の検証可能な資格証明を保有者に渡したことを検証できます。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "https://example.com/VP/0987654321",
"type": ["VerifiablePresentation"],
"verifiableCredential": [
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://pharma.example.com/credentials/3732",
"type": ["VerifiableCredential", "PrescriptionCredential"],
"issuer": "https://pharma.example.com/issuer/4",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"prescription": {....}
},
"credentialStatus": {
"id": "https://pharma.example.com/credentials/status/3#94567",
"type": "RevocationList2020Status",
"revocationListIndex": "94567",
"revocationListCredential": "https://pharma.example.com/credentials/status/3"
},
"proof": {....}
},
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "https://example.com/VC/123456789",
"type": ["VerifiableCredential", "PrescriptionCredential"],
"issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"issuanceDate": "2010-01-03T19:53:24Z",
"credentialSubject": {
"id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
"prescription": {....}
},
"proof": {
"type": "RsaSignature2018",
"created": "2018-06-17T10:03:48Z",
"proofPurpose": "assertionMethod",
"jws": "pYw8XNi1..Cky6Ed=",
"verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234"
}
}
],
"proof": [{
"type": "RsaSignature2018",
"created": "2018-06-18T21:19:10Z",
"proofPurpose": "authentication",
"verificationMethod": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
"challenge": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
"jws": "BavEll0/I1..W3JT24="
}]
}
上の例では、患者(元のサブジェクト)は、処方箋(元の検証可能な資格証明)を友人に渡し、その友人に新しい検証可能な資格証明を発行しており、その友人はサブジェクト、その元の検証可能な資格証明のサブジェクトは発行者、その資格証明は元の処方箋のコピーです。
この項は非規範的です。
発行者が、保有者ではないサブジェクトを記述した資格証明を保有者が保有することを承認したい場合で、保有者がそのサブジェクトと既知の関係を持っていない場合、発行者は保有者と自身の関係をサブジェクトの資格証明に挿入する可能性があります。
検証可能な資格証明は承認フレームワークではないため、委譲はこの仕様の範囲外です。しかし、検証可能な資格証明は、承認と委譲のシステムを構築するために用いられる可能性が高いことが理解されています。以下は、一部のユースケースに適していると思われるアプローチの1つです。
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "NameAndAddress"],
"issuer": "https://example.edu/issuers/14",
"holder": {
"type": "LawEnforcement",
"id": "did:example:ebfeb1276e12ec21f712ebc6f1c"
},
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Mr John Doe",
"address": "10 Some Street, Anytown, ThisLocal, Country X"
},
"proof": {
"type": "RsaSignature2018",
"created": "2018-06-17T10:03:48Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/14/keys/234",
"jws": "pY9...Cky6Ed = "
}
}
この項は非規範的です。
検証可能な資格証明データ・モデルは現在、これらのシナリオのいずれもサポートしていません。これらをどのようにサポートするかは、今後の検討課題です。
この項は非規範的です。
この項は、IANAでの「JSONウェブ・トークン・クレーム・レジストリ」のレビュー、審査、承認、登録のため、インターネット技術運営グループ(IESG)に提出する予定です。
この項では、W3C勧告としてこの仕様のv1.0が公開された後の実質的な変更点を記載しています。
勧告以後の変更点は次のとおりです。
credentialStatusとrefreshServiceの項のidプロパティーで、URLを使用するという要件を緩和し、URIを使用するようにした。issuer、issuanceDate、credentialStatus、日付、リンク切れ、軽微な構文エラーに関連するいくつかの例の編集上のバグを修正。この項は非規範的です。
ワーキンググループは、このドキュメントの内容に対する貢献のみならず、この標準化コミュニティにおいて、様々な意見の海の中で変更、議論、合意を推進した大変な作業に対しても、Matt Stone、Gregg Kellogg、Ted Thibodeau Jr、Oliver Terbu、Joe Andrieu、David I. Lehn、Matthew Collier、Adrian Gropperに感謝します。
この仕様に関する作業は、Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Manu Sporny、Drummond Reed、Joe Andrieu、Heather Vescent、Kim Hamilton Duffy、 Samantha ChaseおよびAndrew Hughesが推進するRebooting the Web of Trustコミュニティから支援を受けてきました。Phil Windley、Kaliya Young、Doc Searls、Heidi Nobantu Saulが推進するインターネット・アイデンティティ・ワークショップ(Internet Identity Workshop)の参加者も、この仕様に関する教育、議論、改善を目的とした多数の作業セッションを通じて、この作業の改良に支援を行ってくださいました。
ワーキンググループは、W3C標準化プロセスを通じてグループを専門的に管理し、着実に指導してくださった議長のDan Burnett、Matt Stone、Brent Zundel、Wayne Chang、そして、W3C窓口スタッフの芦村和幸とIvan Hermanにも感謝します。
この仕様に関する作業の一部は、米国国土安全保障省の科学技術局(HSHQDC-17-C-00019契約)によって資金援助されています。この仕様の内容は、必ずしも米国政府の姿勢や政策を反映したものではなく、公式な推奨を意味するものではありません。
ワーキンググループは、この仕様のレビューとフィードバックを提供してくださった次の方々に感謝します(アルファベット順)。
Christopher Allen、David Ammouial、Joe Andrieu、Bohdan Andriyiv、Ganesh Annan、Kazuyuki Ashimura、Tim Bouma、Pelle Braendgaard、Dan Brickley、Allen Brown、Jeff Burdges、Daniel Burnett、ckennedy422、David Chadwick、Chaoxinhu、Kim (Hamilton) Duffy、Lautaro Dragan、enuoCM、Ken Ebert、Eric Elliott、William Entriken、David Ezell、Nathan George、Reto Gmur、Ryan Grant、glauserr、Adrian Gropper、Joel Gustafson、Amy Guy、Lovesh Harchandani、Daniel Hardman、Dominique Hazael-Massieux、Jonathan Holt、David Hyland-Wood、Iso5786、Renato Iannella、Richard Ishida、Ian Jacobs、Anil John、Tom Jones、Rieks Joosten、Gregg Kellogg、Kevin、Eric Korb、David I. Lehn、Michael Lodder、Dave Longley、Christian Lundkvist、Jim Masloski、Pat McBennett、Adam C. Migus、Liam Missin、Alexander Muhle、Anthony Nadalin、Clare Nelson、Mircea Nistor、Grant Noble、Darrell O'Donnell、Nate Otto、Matt Peterson、Addison Phillips、Eric Prud'hommeaux、Liam Quin、Rajesh Rathnam、Drummond Reed、Yancy Ribbens、Justin Richer、Evstifeev Roman、RorschachRev、Steven Rowat、Pete Rowley、Markus Sabadello、Kristijan Sedlak、Tzviya Seigman、Reza Soltani、Manu Sporny、Orie Steele、Matt Stone、Oliver Terbu、Ted Thibodeau Jr、John Tibbetts、Mike Varley、Richard Varn、Heather Vescent、Christopher Lemmer Webber、Benjamin Young、Kaliya Young、Dmitri Zagidulin、and Brent Zundel。
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先:
参照先: