Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本仕様は、運転免許証(PDF417)や渡航文書(MRZ)に見られるような 光学バーコードを、検証可能な資格情報 [VC-DATA-MODEL-2.0] を使用して 保護する仕組みについて説明する。検証可能な資格情報の 表現は、150 バイト未満に収まるほどコンパクトであり、 そのため、標準的な印刷工程を使用して物理カードに 印刷される従来の二次元バーコードと統合できる。
この節は、この文書が公開された時点での 文書の位置づけについて説明する。現在の W3C 公開文書およびこの技術報告の最新版は、 W3C 標準および草案 索引で確認できる。
この文書は、検証可能な資格情報ワーキング グループにより、 勧告 トラックを使用した作業草案として公開された。
作業草案としての公開は、 W3C およびその会員による 承認を意味しない。
これは草案文書であり、いつでも他の文書によって更新、 置換、または廃止される可能性がある。この文書を 作業中の成果物以外のものとして引用することは適切ではない。
この文書は、 W3C 特許 ポリシーの下で運営されるグループにより作成された。 W3C は、このグループの成果物に関連して行われた 特許開示の公開一覧を 維持している。そのページには、特許を開示するための 手順も含まれている。個人が、 必須クレームを含むと その個人が信じる特許について実際の知識を有する場合、 その情報を W3C 特許ポリシーの第 6 節に従って開示しなければならない。
この文書は、 2025年8月18日版 W3C プロセス文書に準拠する。
運転免許証、旅券、渡航資格情報などの物理的な資格情報には、文書から 情報を素早く読み取るために使用できる機械可読データが含まれることが多い。 この情報は、PDF417 [ISO15438-2015]、 機械可読領域(MRZ)[ICAO9303-3]、 および 一次元または二次元の「バー」として整形されたその他の光学的にスキャン可能な コードなどの形式で符号化される。そのため「バーコード」という用語がある。この情報は、 改ざんから保護されていないことが多く、容易に入手できるバーコード生成および スキャンライブラリが存在するため、誰でもこれらのバーコードを生成することは かなり容易である。
したがって、これらのバーコードの発行者が、バーコード内に含まれる 情報およびそのバーコードを生成した主体を保護することは有用である。
検証可能な資格情報データモデル v2.0 仕様は、運転免許証や 渡航文書に含まれるような資格情報を表現するためのグローバル標準を提供する。 検証可能な資格情報データ完全性 1.0 仕様は、資格情報を保護するためのグローバル 標準を提供する。これら二つの仕様を組み合わせることで、 資格情報を改ざんから保護し、資格情報の作成主体を表現し、 プライバシーを保護する方法で資格情報の現在の状態を提供する手段が得られる。 しかし、これらのデータ形式は、光学バーコードで表現するには大きすぎる傾向がある。
Linked Data のための コンパクトバイナリオブジェクト表現 v1.0 仕様は、保護された 検証可能な 資格情報を、情報を光学バーコードとして、または光学 バーコード内に埋め込んで表現することが実現可能になるところまで圧縮する手段を提供する。
本仕様は、運転免許証(PDF417)や渡航文書(MRZ)に見られるような 光学バーコードを、検証可能な資格情報 [VC-DATA-MODEL-2.0] を使用して、 バーコード自体またはバーコードの主体に関する情報を表現することにより保護する 仕組みについて説明する。次に、この検証可能な資格情報は Data Integrity [VC-DATA-INTEGRITY] を使用して保護され、 その後 CBOR-LD [CBOR-LD] を使用して圧縮される。
検証可能な資格情報を使用してバーコードを保護する主な仕組みは二つある。
どちらのユースケースも、検証可能な資格情報によって保護されるデータについて、 真正性、完全性、および改ざん耐性を実現する。さらに、それを必要とする ユースケースでは、これらの検証可能な資格情報をバーコード単位で取り消し、 または一時停止できる。
以下の各節では、この仕様を使用して、検証可能な 資格情報を通じたデジタル署名により、既存の物理的な資格情報を 強化する方法について、いくつかの導入例を示す。
この節では、本仕様の技術を、PDF417 バーコードを使用する運転免許証上の 光学バーコードを保護するためにどのように利用できるかの例を示す。 まず、運転免許証の例から始める。
運転免許証の裏面には PDF417 バーコードが含まれる。
PDF417 データには、本仕様で説明するアルゴリズムを使用して保護された情報が含まれる。 すなわち、PDF417 バーコードには、次の形式の 検証可能な 資格情報が含まれる。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vdl/v2",
"https://w3id.org/vdl/utopia/v1"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
// the issuer value below is defined as a URL in the 'utopia/v1' context above
"issuer": "did:web:dmv.utopia.example",
"credentialStatus": {
"type": "TerseBitstringStatusListEntry",
"terseStatusListBaseUrl": "https://dmv.utopia.gov/statuses/12345/status-lists"
"terseStatusListIndex": 123567890
},
"credentialSubject": {
"type": "AamvaDriversLicenseScannableInformation",
"protectedComponentIndex": "uP_BA"
},
"proof": {
"type": "DataIntegrity",
"cryptosuite": "ecdsa-xi-2023",
// the public key below is defined as a URL in the 'utopia/v1' context above
"verificationMethod": "did:web:dmv.utopia.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z4peo48uwK2EF4Fta8P...HzQMDYJ34r9gL"
}
}
上記の検証可能な 資格情報は、その後 [CBOR-LD] を使用して次の出力(CBOR 診断表記)に圧縮される。
1281{
1 => [ 32768, 32769, 32770], // @context
155 => [ 116, 164 ], // type
192 => 174, // issuer
186 => { 154 => 166, 206 => 178, 208 => 1234567890 }, // credentialStatus
188 => { 154 => 172, 180 => h'753FF040 }, // credentialSubject
194 => { // proof
154 => 108, // type
214 => 4, // cryptosuite
224 => 230 // verificationMethod
228 => 176, // proofPurpose
210 => Uint8Array(65) [ ... ], // proofValue
}
}
この節では、本仕様の技術を、出生証明書を検証可能な 資格情報として保護するためにどのように利用できるかの例を示す。 これはその後、印刷された紙文書上の QR コードとして表現される。
QR コードは次の検証可能な 資格情報を符号化する。符号化の詳細は、以下の別個のタブで利用できる。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vital-records/v1rc1"
],
"type": [
"VerifiableCredential",
"BirthCertificateCredential"
],
"issuer": "https://hospital.example/issuer",
"validFrom": "2023-09-30T11:30:00Z",
"credentialSubject": {
"type": "BirthCertificate",
"certificationDate": "2023-09-30T13:44:52Z",
"newborn": {
"type": "Newborn",
"name": "Tim Doe",
"gender": "Male",
"birthDate": "2023-10-05T14:29:00Z",
"birthPlace": {
"type": "PostalAddress",
"streetAddress": "123 Hospital Rd",
"addressLocality": "Utopia Town",
"addressRegion": "Utopolis",
"postalCode": "12345",
"addressCountry": "Utopia"
},
"parent": [{
"type": "Mother",
"name": "Jane Doe",
"namePriorToMarriage": "Jane Smith"
}, {
"type": "Father",
"name": "John Doe"
}]
}
}
}
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vital-records/v1rc1"
],
"type": [
"VerifiableCredential",
"BirthCertificateCredential"
],
"issuer": "https://hospital.example/issuer",
"validFrom": "2023-09-30T11:30:00Z",
"credentialSubject": {
"type": "BirthCertificate",
"certificationDate": "2023-09-30T13:44:52Z",
"newborn": {
"type": "Newborn",
"name": "Tim Doe",
"gender": "Male",
"birthDate": "2023-10-05T14:29:00Z",
"birthPlace": {
"type": "PostalAddress",
"streetAddress": "123 Hospital Rd",
"addressLocality": "Utopia Town",
"addressRegion": "Utopolis",
"postalCode": "12345",
"addressCountry": "Utopia"
},
"parent": [
{
"type": "Mother",
"name": "Jane Doe",
"namePriorToMarriage": "Jane Smith"
},
{
"type": "Father",
"name": "John Doe"
}
]
}
},
"proof": {
"type": "DataIntegrityProof",
"created": "2026-06-23T17:09:43Z",
"verificationMethod": "did:key:zDnaep3M6F9WVbtR4JaDCpS84JphmppHXBh8NNLWQYJDvpa8i",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z5dT3pjsBWEXyquJXoNX1atkXDisQaLJMcrkJPNYMSMqSMocrqhHkK9nRiztfTDSANzg5iEi6YurddLfD
nnStdeTm"
}
}
51997(
[
1,
{
1: [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vital-records/v1rc1"
],
157: [
118,
164
],
304: {
156: 162,
204: "2023-09-30T13:44:52Z",
260: {
150: "Tim Doe",
156: 174,
188: "2023-10-05T14:29:00Z",
196: {
156: 178,
324: "Utopia",
326: "Utopia Town",
328: "Utopolis",
330: "12345",
332: "123 Hospital Rd"
},
226: "Male",
267: [
{
150: "Jane Doe",
156: 172,
258: "Jane Smith"
},
{
150: "John Doe",
156: 170
}
]
}
},
308: [
2,
"hospital.example/issuer"
],
310: {
156: 108,
336: 1782234583,
338: "ecdsa-rdfc-2019",
348: 354,
350: h'7ae780156acdf39b8a76dd9dfdcc7d9cf32636e91579f894a2f1fc8cafc9fd0fb5a72660ed343f1ca8854
2eafd94e542c509080ab479da5e303fb74dcdd2065674',
352: [
1025,
h'8024035ecd0dd569e4db7f6feefdb0249d9156db32899632ae707466310043e3cb954b'
]
},
320: 1696073400
}
])}
VC1-R0OR*W3H90Q80L8FA9DIWENPEJ/5S4F03F53F7*5$KE$:5CPEXPC C1$CBWEAECCPEI.EL8FA9DIWENPEJ/553FPED7*5$K
E006-EDAECOX5Z C04EKVC006DB6DOC1534KG$-EOXKY60$RK0XJ6MK5%PNF6QF63W5CA79L6/SAJL6:Q66G7KG6B73KQ0*43$2D
YEDP34W3E053I53W531VE8466L6$963W5HX6-963G7PA7646OHBW%O053M53B735T86 A/3EMEDB73R+86 A/3EMED-3454EF-DD
70O8DHWES9EXVDZOEF70UZCQF60R6B73$T9*96%K6379WQE-EDAEC*34JTC-RS9Z9TVDB73LK1$RKT0J6I91/DP34W3E053G53B7
3XD06I91/D+34J$DAWE6MKT0JKI949DP34W3E053E53B73WS61E059DWQE-EDAEC.%5$9FQ$DTVDW:5ZQE%$E4JE+60+:K0XJ/TD
L70CF37J7U8RN70W3EJPCHQEOX57VC9OCNF61A6B73.SB*70B73W-BMC88VI17O7KH*PAHK7DEN BQ$HAPSE/EE451E7EPCRGYJZ
V5TPNQ62SAJO2AUSG2DUDIO 2IOER26ON44.4M:-QVC0%ZBY+M/ACB7319CE73T70/L4*O4E:BVX1IHDVXRY6E93WDS4 GI:VRWH
HEI6X9EG-CM10+ZSE*IB73U485ZCA%0
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vital-records/v1rc1"
],
"type": [
"VerifiableCredential",
"BirthCertificateCredential"
],
"issuer": "https://hospital.example/issuer",
"validFrom": "2023-09-30T11:30:00Z",
"credentialSubject": {
"type": "BirthCertificate",
"certificationDate": "2023-09-30T13:44:52Z",
"newborn": {
"type": "Newborn",
"name": "Tim Doe",
"gender": "Male",
"birthDate": "2023-10-05T14:29:00Z",
"birthPlace": {
"type": "PostalAddress",
"streetAddress": "123 Hospital Rd",
"addressLocality": "Utopia Town",
"addressRegion": "Utopolis",
"postalCode": "12345",
"addressCountry": "Utopia"
},
"parent": [
{
"type": "Mother",
"name": "Jane Doe",
"namePriorToMarriage": "Jane Smith"
},
{
"type": "Father",
"name": "John Doe"
}
]
}
},
"proof": {
"type": "DataIntegrityProof",
"created": "2026-06-23T17:09:43Z",
"verificationMethod": "did:key:zDnaep3M6F9WVbtR4JaDCpS84JphmppHXBh8NNLWQYJDvpa8i",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z3xU4Hqfs6EKrrwiRyNP6Pwxfo8yHfyHA5SFt4Dn9cSfQVcqDsCzSeD8CSDs2XqU7Y4qB6zkWrJqt9t2P
s13mzgoA"
}
}}
以下は、本仕様における技術の設計目標である。
この文書全体で使用される用語は、 検証可能な資格情報データモデル v2.0 仕様の 用語節、および 検証可能な資格情報データ完全性 1.0 仕様で定義される。
A および B)の
順序を決定することを指す。これは、コードポイントを比較する
全順序を
文字列に対して定義する。
UTF-8 で符号化された文字列については、バイト列を比較することで、コード
ポイント順序と同じ結果が得られることに注意。
非規範として示された節に加えて、この仕様におけるすべての著作ガイドライン、図、例、および注記は 非規範である。それ以外のすべては規範である。
この文書におけるキーワード MAY、MUST、RECOMMENDED、REQUIRED、および SHOULD は、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されるとおりに解釈される。
適合 文書とは、この仕様の規範的記述に準拠するデータモデルの任意の具体的表現である。 具体的には、この文書の 2. データモデルおよび3. アルゴリズム の各節における関連するすべての規範的記述は、強制されなければならない。
適合 プロセッサとは、 適合文書を生成または消費する、 ソフトウェアおよび/またはハードウェアとして実現された任意のアルゴリズムである。 適合プロセッサは、非適合文書が消費されたときにエラーを生成しなければならない。
この文書には JSON および JSON-LD データの例が含まれる。これらの例の一部は、
特定の箇所を説明するインラインコメント(//)や、例に関係のない情報の
省略を示す省略記号(...)などの機能を含むため、無効な JSON である。
実装者がこれらの例を有効な JSON または JSON-LD として扱いたい場合、そのような部分は
削除する必要がある。
以下の節では、本仕様が、バーコードや渡航文書上の機械可読領域などの 光学的に印刷された情報を保護する検証可能な資格情報を 表現するために使用するデータモデルの概要を示す。
OpticalBarcodeCredential は、1) 作成主体情報、2) 改ざん耐性、
および 3) 任意で、取消しおよび一時停止状態を提供する方法で、光学
バーコードの内容を保護するために使用される。言い換えれば、
その資格情報は、光学バーコードを誰が発行したか、その
光学バーコードが最初に発行されて以降に改ざんされたかどうか、
および光学バーコードの発行者が、
その文書がまだ有効であることをなお保証しているかどうかを示すことができる。
これらの機能は、物理文書に対して重要な不正防止保護を提供する。
OpticalBarcodeCredential の credentialSubject は、
AamvaDriversLicenseScannableInformation 型または
MachineReadableZone 型のいずれかである。
AamvaDriversLicenseScannableInformation は、
検証可能な資格情報が、
物理文書上の PDF417 バーコードおよび
検証可能な資格情報で
表現された情報を保護することを意味する。
MachineReadableZone は、
検証可能な資格情報が、
物理文書上の機械可読領域および
検証可能な資格情報で
表現された情報を保護することを意味する。
OpticalBarcodeCredential が
AamvaDriversLicenseScannableInformation 型である場合、
PDF417 内のどのフィールドがデジタル署名されるかに関する情報を含む、
追加フィールド protectedComponentIndex が必須である。
protectedComponentIndex は、
JSON-LD 資格情報内で合計 5 文字になるように multibase-base64url 符号化された、
3 バイト/24 ビット値でなければならない。AAMVA 準拠の運転免許証 PDF417
[aamva-dl-id-card-design-standard]
には 22 個の必須フィールドがあり、protectedComponentIndex 値の
最初の 22 ビットはこれらのフィールドに対応する。各 AAMVA 必須
フィールドは、3 文字の要素 ID(例: 文書有効期限の DBA)で始まる。
protectedComponentIndex 値内のビットとこれらのフィールドとの
マッピングを構築するには、これらの要素 ID を Unicode コードポイント順に
ソートする。次に、protectedComponentIndex の位置 i のビットが
1 である場合、ソートされた要素 ID の位置 i にある
AAMVA 必須フィールドはデジタル署名によって保護される。
protectedComponentIndex の最後の 2 ビットは 0 で
なければならない。詳細は、3.2.4.4
opticalDataBytes の作成を参照。
可能な限り高い圧縮率を達成するために、issuer および
verificationMethod フィールドは JSON-LD Context の用語を利用することが
推奨される。これにより、CBOR-LD の意味的
圧縮機構によって数バイトまで圧縮できる。
この節で指定されたプロパティを利用する光学バーコード資格情報の例を以下に示す。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vdl/v2",
"https://w3id.org/vdl/utopia/v1"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
"issuer": "did:web:dmv.utopia.example",
"credentialStatus": {
"type": "TerseBitstringStatusListEntry",
"terseStatusListBaseUrl": "dmv.utopia.gov/statuses/12345/status-lists"
"terseStatusListIndex": 123567890
},
"credentialSubject": {
"type": "AamvaDriversLicenseScannableInformation",
"protectedComponentIndex": "uP_BA"
}
}
TerseBitstringStatusListEntry は、Bitstring Status List v1.0
仕様で定義される BitstringStatusListEntry のコンパクトな表現である。
TerseBitstringStatusListEntry 型のオブジェクトは、二つの追加プロパティを
持たなければならない。
terseStatusListBaseUrl。これは、この資格情報に関連付けられた
状態リストの場所を識別する。
terseStatusListBaseUrl は URL [URL] で
なければならない。
terseStatusListIndex。これは、上記 URL における個別の状態を指定する。
terseStatusListIndex は
32 ビット符号なし整数として表現可能でなければならない。
TerseBitstringStatusListEntry を処理するには、3.2.3 節
3.2.3 Status List エントリの変換のアルゴリズムを
適用して BitstringStatusListEntry に変換し、
その後 Bitstring Status List v1.0
と同様に処理する。
実装者は、個別の状態リストの長さとして listLength の値を設定する必要がある。
これにより、32 ビットの terseStatusListIndex に対して
状態リストの数 listCount = 2^32 / listLength が得られる。
listLength は、TerseBitstringStatusListEntry から
BitstringStatusListEntry へ変換するために必要である。
listLength の一部の値は、これらの状態リストのプライバシー保護特性を
損なうことに注意し、実装は listLength = 2^26 および
listCount = 2^6 を使用しなければならない。
実装者は、PDF417 に符号化する前に、CBOR-LD で符号化された
AamvaDriversLicenseScannableInformation
資格情報を base64url として文字符号化することが推奨される。
multibase ヘッダーは、base 符号化された VCB データの前に付加してもよい。
PDF417 フィールドヘッダー仕様は、multibase ヘッダーが存在するか存在しないかを
示すことが期待される。
実装者は、CBOR-LD で符号化された MachineReadableZone 資格情報を
QR コードに符号化する前に、文字列 'VC1-' を前置した base45-multibase として
再符号化することが必須である。
以下の節では、運転免許証や渡航文書などの物理媒体上の、バーコードや 機械可読領域などの光学情報を保護するデジタル証明を追加および検証するための アルゴリズムについて説明する。
この節には、検証可能な 資格情報の符号化および復号に一般的なアルゴリズムが含まれる。
本仕様は、検証可能な 資格情報を符号化および復号する際に、アプリケーション固有の圧縮表を CBOR-LD プロセッサに提供することを要求する。さまざまな 発行者のすべてのコンテキスト URL のレジストリは、 コンマ区切り値ファイルとして提供される。このファイルは、 変更要求を通じて、追記のみかつ先着順で更新および変更できる。 実装は、圧縮および展開が最新の値をサポートすることを確保するため、 最新のファイルを毎月取得して利用すべきである。
次のアルゴリズムは、検証可能な 資格情報を、QR コードで表現できるテキスト文字列に符号化する方法を指定する。 必須入力は、検証可能な 資格情報(マップ inputDocument)と、 オプションの集合(マップ options)である。出力は、符号化された検証可能な 資格情報 (文字列)またはエラーである。 このアルゴリズムが文字列を符号化する場合は常に、UTF-8 符号化を 使用しなければならない。
45 を
targetBase として、
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./: を baseAlphabet として
渡した結果とする。
VC1-、
R(base45 の Multibase 接頭辞)、
および
base45Value。
次のアルゴリズムは、QR コードに符号化された検証可能な 資格情報を復号する方法を指定する。必須入力は、テキスト文字列(文字列 inputDocument)と、オプションの集合(マップ options)である。 出力は、検証可能な 資格情報(マップ)またはエラーである。 このアルゴリズムが文字列を符号化する場合は常に、UTF-8 符号化を 使用しなければならない。
VC1-R で始まることを確認する。
そうでない場合、エラーが発生されなければならない。
VC1-R)を削除した inputDocument とする。
45 を
sourceBase として、
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./: を baseAlphabet として
渡した結果とする。
この節には、OpticalBarcodeCredential の type を持つ
検証可能な資格情報の
符号化および復号に固有のアルゴリズムが含まれる。
OpticalBarcodeCredential に追加したい
BitstringStatusListCredential
(Bitstring Status List
v1.0 仕様で定義されるもの)に設定する。
TerseBitstringStatusListEntry に設定し、
statusListEntryTerse.index を
statusListEntryVerbose.statusListIndex の整数表現に設定する。
OpticalBarcodeCredential に設定する。
OpticalBarcodeCredential に設定する。
この節のアルゴリズムは、
TerseBitstringStatusListEntry を BitstringStatusListEntry に
変換するために使用される。これは、検証可能な
資格情報に対して検証が実行された後、
検証処理の間に使用される。
検証可能な
資格情報の検証が実行された後、
このアルゴリズムは、OpticalBarcodeCredential の
検証可能な
資格情報
(構造体 vc)、
vc に関連付けられた BitstringStatusListCredential 内の
エントリ数を含む整数 listLength、および文字列
statusPurpose(例: 'revocation'、'suspension'...)を入力として受け取り、
'BitstringStatusListEntry' オブジェクトを返す。
floor() 演算を適用する)に設定する。
result は、Bitstring Status List v1.0 仕様の 検証アルゴリズムへの入力として使用できる。
実装者は、すべての発行者が、 自身の検証可能な 資格情報の状態リスト情報を公開するわけではないことに注意することが推奨される。 一部の発行者は、 検証者が 状態リスト資格情報へアクセスすることを許可する前に、認可を要求する場合がある。
ecdsa-xi-2023 暗号スイートは、実質的には
ecdsa-rdfc-2019 アルゴリズム [VC-DI-ECDSA] に、
元の光学バーコードデータなどの「追加情報」
(xi) を入力として受け取り、そのデータをデジタル署名によって保護される情報に
含める追加ステップを加えたものである。この節のアルゴリズムでは、
そのような署名がどのように作成および検証されるかを詳述する。
証明を生成するには、Data Integrity [VC-DATA-INTEGRITY] 仕様の Section 4.1: Add Proof のアルゴリズムを 実行しなければならない。 そのアルゴリズムについて、暗号スイート固有の 変換アルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Transformation (ecdsa-rdfc-2019) 節で定義され、 ハッシュアルゴリズムは 3.2.4.3 ハッシュ (ecdsa-xi-2023)節で定義され、 証明シリアル化アルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Proof Serialization (ecdsa-rdfc-2019) 節で定義される。
証明を検証するには、Data Integrity [VC-DATA-INTEGRITY] 仕様の Section 4.2: Verify Proof のアルゴリズムを 実行しなければならない。そのアルゴリズムについて、暗号 スイート固有の 変換アルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Transformation (ecdsa-rdfc-2019) 節で定義され、 ハッシュアルゴリズムは 3.2.4.3 ハッシュ (ecdsa-xi-2023)節で定義され、 証明検証アルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Proof Verification (ecdsa-rdfc-2019) 節で定義される。
ハッシュアルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 仕様の Hashing (ecdsa-rdfc-2019) 節で定義されるものに、 以下で説明するように光学データのハッシュを追加したものである。 実装は、機械可読な光学データ(PDF417 または MRZ データ)を このハッシュアルゴリズムで利用可能にすると想定される。
このアルゴリズムの必須入力は、変換済みデータ文書 (transformedDocument)、正規証明設定 (canonicalProofConfig)、および光学データ (opticalDataBytes)である。出力として、一連のバイトで表される 単一のハッシュデータ値が生成される。
ハッシュアルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Hashing (ecdsa-rdfc-2019) 節で定義されるもののステップ 3 を 次の二つのステップに置き換えたものである。
credentialSubject.protectedComponentIndex を復号した結果である
長さ 24 のビット列の最初の 22 ビットを bitfieldDecoded とする。
1 を持つ各ビットについて:
\n、U+000A)を末尾に連結し、
その結果を dataToCanonicalize に追加する。
証明設定アルゴリズムは、Data Integrity ECDSA Cryptosuites v1.0 の Proof Configuration (ecdsa-rdfc-2019) 節で定義されるものの ステップ 4 を次のステップに置き換えたものである。
DataIntegrityProof に設定されておらず、
かつ proofConfig.cryptosuite が
ecdsa-xi-2023 に設定されていない場合、
INVALID_PROOF_CONFIGURATION エラーが
発生されなければならない。
この節は非規範である。
この節を読む前に、読者は、 Data Integrity 仕様のセキュリティ考慮事項の節で提供されている 一般的なセキュリティ助言、および ECDSA 暗号スイート仕様のセキュリティ考慮事項の節で提供されている 特定のセキュリティ助言に精通することが強く推奨される。
以下の節では、これらの重要な点を確認し、読者を追加情報へ案内する。
OpticalBarcodeCredentials に対する一つの攻撃ベクトルは、
不正な文書で使用するために、デジタル署名を含む光学バーコードを複製することである。
複製されたバーコードは元のものと同様に署名検証に合格するが、この攻撃は、
文書検証者が次の三つを確認することで緩和される。署名されたデータが文書上で
目に見えるデータと一致すること、署名されたデータが利用者の身体的属性と一致すること、
目に見えるデータが利用者の身体的属性と一致することである。これら三つがすべて等価である場合、
OpticalBarcodeCredential が複製であり得る唯一の方法は、不正文書の作成者が、
署名された身体的属性が不正文書の利用者の属性と完全に重なる本物の
OpticalBarcodeCredential にアクセスできた場合である。
任意の人物の外見と完全に一致する、検出されていない盗難
OpticalBarcodeCredential が存在する可能性は低いため、
この攻撃が成功する可能性は低い。
場合によっては、既存の光学データ全体に対してデジタル署名を作成できないことがある。
たとえば、物理的な資格情報の製造業者によってシリアル番号が挿入されるため、
署名時に発行者がその番号を知らない場合を考える。この場合、検証者は、
デジタル署名されていないデータは、OpticalBarcodeCredential の
正常な検証能力に影響を与えることなく、光学バーコード内で変更され得るものと
想定することになる。
光学バーコードからのデータが、文書上で目に見えるデータおよび文書保持者の特徴と 一致することを確認する場合、実装者はデジタル署名されたフィールドのみを使用することが 推奨される。検証者は、 署名されていない文書で不正検出に他のフィールドがどれほど一般的に使用されているかに かかわらず、デジタル署名によって保護されたフィールドのみを使用することが推奨される。 たとえば、目の色と髪の色は署名によって保護されているが、 保持者の 顔写真は保護されていない場合、検証者は、顔写真よりも 目の色と髪の色を重視して不正検出を試みることが推奨される。
検証者が使用するソフトウェアの 実装者は、検証処理中にデジタル署名によって保護されたカードデータのみを 表示することが推奨される。改ざんされている可能性のある未署名データを表示すると、 不正検出を妨げるおそれがある。
検証者は、
OpticalBarcodeCredential の有効性を確認するために、常に信頼されたプログラムおよび
インターフェイスを使用することが推奨される。信頼できないソフトウェアを使用して文書を
検証すると、不正な資格情報が受け入れられたり、本物の資格情報が盗まれたりする可能性がある。
この節を読む前に、読者は、 Data Integrity 仕様のセキュリティ考慮事項の節で提供されている 一般的なセキュリティ助言、および ECDSA 暗号スイート仕様のセキュリティ考慮事項の節で提供されている 特定のセキュリティ助言に精通することが強く推奨される。
次の節では、本仕様を実装する開発者がプライバシー上の前提に違反しないために 認識しておくべきプライバシー考慮事項について説明する。
この節は非規範である。
この節には、検証可能な資格情報バーコードの例、およびそれらがどのように生成され、 どのように検証されるかについての段階的な手順が含まれる。
この節では、二つの継続的な例を分析する。Utopia 就労許可文書の MRZ を保護する VCB と、 Utopia 運転免許証の PDF417 を保護する VCB である。
まず、VCB によって署名されるデータ(すなわち、PDF417 からの AAMVA 必須フィールド)から始める。
DACJOHN DADNONE DAG123 MAIN ST DAIANYVILLE DAJUTO DAKF87P20000 DAQF987654321 DAU069 IN DAYBRO DBA04192030 DBB04191988 DBC1 DBD01012024 DCAC DCBNONE DCDNONE DCFUTODOCDISCRIM DCGUTO DCSSMITH DDEN DDFN DDGN
簡単のため、署名したい PDF417 内のデータが、名(DAC)、
姓(DCS)、および免許証番号(DAQ)のみであると仮定する。
protectedComponentIndex で使用するビット列値は
100000100000000000100000 となり、
protectedComponentIndex の値は "uggAg" である。
3.2.4.4
opticalDataBytes の作成を適用すると、次が得られる。
canonicalizedData = 'DACJOHN\nDAQF987654321\nDCSSMITH\n' opticalDataBytes: [188, 38, 200, 146, 227, 213, 90, 250, 50, 18, 126, 254, 47, 177, 91, 23, 64, 129, 104, 223, 136, 81, 116, 67, 136, 125, 137, 165, 117, 63, 152, 207]
これで、このハッシュ値を
3.2.4.3 ハッシュ
(ecdsa-xi-2023)とともに使用して VC に署名できる。
BitstringStatusListCredential を用いて
3.2.1
OpticalBarcodeCredential を符号化するを実行すると、
次の JSON-LD VC が得られる。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vc-barcodes/v1",
"https://w3id.org/utopia/v2"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
"credentialSubject": {
"type": "AamvaDriversLicenseScannableInformation",
"protectedComponentIndex": "uggAg"
},
"issuer": "did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj",
"credentialStatus": {
"type": "TerseBitstringStatusListEntry",
"terseStatusListBaseUrl": "https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists",
"terseStatusListIndex": 3851559041
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj#zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj",
"cryptosuite": "ecdsa-xi-2023",
"proofPurpose": "assertionMethod",
"proofValue": "z4g6G3dAZhhtPxPWgFvkiRv7krtCaeJxjokvL46fchAFCXEY3FeX2vn46MDgBaw779g1E1jswZJxxreZDCrtHg2qH"
}
}
これで、この VC に CBOR-LD 圧縮を適用できる。ここでは最新バージョンの CBOR-LD を使用する。ただし、この節の最後では、最新でない CBOR-LD 実装との相互運用性テストのために、古いバージョンの CBOR-LD を使用して符号化された VCB を提供する。
この仕様のために、値 100 の CBOR-LD レジストリエントリを予約している
(すなわち、これらのペイロードはタグ 0x0664 で始まる)。
CBOR-LD 仕様のレジストリにある、CBOR-LD を使用して符号化するための
パラメータは次のとおりである。
registryEntryId: 100
typeTable:
{
"context":
{
"https://www.w3.org/ns/credentials/v2": 32768,
"https://w3id.org/vc-barcodes/v1": 32769,
"https://w3id.org/utopia/v2": 32770
},
"https://w3id.org/security#cryptosuiteString":
{
"ecdsa-rdfc-2019": 1,
"ecdsa-sd-2023": 2,
"eddsa-rdfc-2022": 3,
"ecdsa-xi-2023": 4
}
}
コンテキストを処理し、コンテキスト用語に整数値を割り当てた結果として得られるべき term-to-ID マッピングは次のとおりである。
Map(97) {
'@context' => 0,
'@type' => 2,
'@id' => 4,
'@value' => 6,
'@direction' => 8,
'@graph' => 10,
'@included' => 12,
'@index' => 14,
'@json' => 16,
'@language' => 18,
'@list' => 20,
'@nest' => 22,
'@reverse' => 24,
'@base' => 26,
'@container' => 28,
'@default' => 30,
'@embed' => 32,
'@explicit' => 34,
'@none' => 36,
'@omitDefault' => 38,
'@prefix' => 40,
'@preserve' => 42,
'@protected' => 44,
'@requireAll' => 46,
'@set' => 48,
'@version' => 50,
'@vocab' => 52,
'...' => 100,
'BitstringStatusList' => 102,
'BitstringStatusListCredential' => 104,
'BitstringStatusListEntry' => 106,
'DataIntegrityProof' => 108,
'EnvelopedVerifiableCredential' => 110,
'EnvelopedVerifiablePresentation' => 112,
'JsonSchema' => 114,
'JsonSchemaCredential' => 116,
'VerifiableCredential' => 118,
'VerifiablePresentation' => 120,
'_sd' => 122,
'_sd_alg' => 124,
'aud' => 126,
'cnf' => 128,
'description' => 130,
'digestMultibase' => 132,
'digestSRI' => 134,
'exp' => 136,
'iat' => 138,
'id' => 140,
'iss' => 142,
'jku' => 144,
'kid' => 146,
'mediaType' => 148,
'name' => 150,
'nbf' => 152,
'sub' => 154,
'type' => 156,
'x5u' => 158,
'AamvaDriversLicenseScannableInformation' => 160,
'MachineReadableZone' => 162,
'OpticalBarcodeCredential' => 164,
'TerseBitstringStatusListEntry' => 166,
'protectedComponentIndex' => 168,
'did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj' => 170,
'did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj#zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj' => 172,
'did:key:zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj' => 174,
'did:key:zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj#zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj' => 176,
'https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists' => 178,
'confidenceMethod' => 180,
'credentialSchema' => 182,
'credentialStatus' => 184,
'credentialSubject' => 186,
'evidence' => 188,
'issuer' => 190,
'proof' => 192,
'refreshService' => 194,
'relatedResource' => 196,
'renderMethod' => 198,
'termsOfUse' => 200,
'validFrom' => 202,
'validUntil' => 204,
'terseStatusListBaseUrl' => 206,
'terseStatusListIndex' => 208,
'challenge' => 210,
'created' => 212,
'cryptosuite' => 214,
'domain' => 216,
'expires' => 218,
'nonce' => 220,
'previousProof' => 222,
'proofPurpose' => 224,
'proofValue' => 226,
'verificationMethod' => 228,
'assertionMethod' => 230,
'authentication' => 232,
'capabilityDelegation' => 234,
'capabilityInvocation' => 236,
'keyAgreement' => 238
}
上記の詳細については、6.3 実装上の注記を参照。
これにより、次の符号化済み資格情報が得られる。
D9CB1D821864A60183198000198001198002189D82187618A418B8A3189C18A618CE18B218D01AE592208118BAA2189C18A018A8447582002018BE18AA18C0A5189C186C18D60418E018E618E258417AB7C2E56B49E2CCE62184CE26818E15A8B173164401B5D3BB93FFD6D2B5EB8F6AC0971502AE3DD49D17EC66528164034C912685B8111BC04CDC9EC13DBADD91CC18E418AC
diagnostic:
51997([
100,
{
1: [32768, 32769, 32770],
157: [118, 164],
184: {156: 166, 206: 178, 208: 3851559041},
186: {156: 160, 168: h'75820020'},
190: 170,
192: {
156: 108,
214: 4,
224: 230,
226: h'7AB7C2E56B49E2CCE62184CE26818E15A8B173164401B5D3BB93FFD6D2B5EB8F6AC0971502AE3DD49D17EC66528164034C912685B8111BC04CDC9EC13DBADD91CC',
228: 172
}
}
])
運転免許証 CBOR-LD を base64url として符号化し、その結果を 'ZZ' サブファイル内の 'ZZA' フィールドの PDF417 バイトに挿入する。
bytes(@\n\x1e\rANSI 000000090002DL00410234ZZ02750202DLDAQF987654321\nDCSSMITH\nDDEN\nDACJOHN\nDDFN\nDADNONE\nDDGN\nDCAC\nDCBNONE\nDCDNONE\nDBD01012024\nDBB04191988\nDBA04192030\nDBC1\nDAU069 IN\nDAYBRO\nDAG123 MAIN ST\nDAIANYVILLE\nDAJUTO\nDAKF87P20000 \nDCFUTODOCDISCRIM\nDCGUTO\nDAW158\nDCK1234567890\nDDAN\rZZZZA2csdghhkpgGDGYAAGYABGYACGJ2CGHYYpBi4oxicGKYYzhiyGNAa5ZIggRi6ohicGKAYqER1ggAgGL4YqhjApRicGGwY1gQY4BjmGOJYQXq3wuVrSeLM5iGEziaBjhWosXMWRAG107uT/9bSteuPasCXFQKuPdSdF+xmUoFkA0yRJoW4ERvATNyewT263ZHMGOQYrA==\r)
上記はこれでバーコードに変換できる。
ここで、逆の処理を適用して検証する。
まず、PDF417 からデータを読み取る。
bytes(@\n\x1e\rANSI 000000090002DL00410234ZZ02750202DLDAQF987654321\nDCSSMITH\nDDEN\nDACJOHN\nDDFN\nDADNONE\nDDGN\nDCAC\nDCBNONE\nDCDNONE\nDBD01012024\nDBB04191988\nDBA04192030\nDBC1\nDAU069 IN\nDAYBRO\nDAG123 MAIN ST\nDAIANYVILLE\nDAJUTO\nDAKF87P20000 \nDCFUTODOCDISCRIM\nDCGUTO\nDAW158\nDCK1234567890\nDDAN\rZZZZA2csdghhkpgGDGYAAGYABGYACGJ2CGHYYpBi4oxicGKYYzhiyGNAa5ZIggRi6ohicGKAYqER1ggAgGL4YqhjApRicGGwY1gQY4BjmGOJYQXq3wuVrSeLM5iGEziaBjhWosXMWRAG107uT_9bSteuPasCXFQKuPdSdF-xmUoFkA0yRJoW4ERvATNyewT263ZHMGOQYrA==\r)
'ZZ' サブファイル内の 'ZZA' フィールドのデータを抽出し、base 符号化を元に戻す。
D9CB1D821864A60183198000198001198002189D82187618A418B8A3189C18A618CE18B218D01AE592208118BAA2189C18A018A8447582002018BE18AA18C0A5189C186C18D60418E018E618E258417AB7C2E56B49E2CCE62184CE26818E15A8B173164401B5D3BB93FFD6D2B5EB8F6AC0971502AE3DD49D17EC66528164034C912685B8111BC04CDC9EC13DBADD91CC18E418AC
次に、CBOR-LD で展開して、検証対象となる元の JSON-LD VC を取得する。
ここでも、パラメータは CBOR-LD レジストリエントリ 100 に関連付けられている。
typeTable:
{
"context":
{
"https://www.w3.org/ns/credentials/v2": 32768,
"https://w3id.org/vc-barcodes/v1": 32769,
"https://w3id.org/utopia/v2": 32770
},
"https://w3id.org/security#cryptosuiteString":
{
"ecdsa-rdfc-2019": 1,
"ecdsa-sd-2023": 2,
"eddsa-rdfc-2022": 3,
"ecdsa-xi-2023": 4
}
}
コンテキストを処理し、コンテキスト用語に整数値を割り当てた結果として得られるべき ID-to-term マッピングは次のとおりである。これは圧縮時に構築されたマップの逆であることに注意。
Map(97) {
0 => '@context',
2 => '@type',
4 => '@id',
6 => '@value',
8 => '@direction',
10 => '@graph',
12 => '@included',
14 => '@index',
16 => '@json',
18 => '@language',
20 => '@list',
22 => '@nest',
24 => '@reverse',
26 => '@base',
28 => '@container',
30 => '@default',
32 => '@embed',
34 => '@explicit',
36 => '@none',
38 => '@omitDefault',
40 => '@prefix',
42 => '@preserve',
44 => '@protected',
46 => '@requireAll',
48 => '@set',
50 => '@version',
52 => '@vocab',
100 => '...',
102 => 'BitstringStatusList',
104 => 'BitstringStatusListCredential',
106 => 'BitstringStatusListEntry',
108 => 'DataIntegrityProof',
110 => 'EnvelopedVerifiableCredential',
112 => 'EnvelopedVerifiablePresentation',
114 => 'JsonSchema',
116 => 'JsonSchemaCredential',
118 => 'VerifiableCredential',
120 => 'VerifiablePresentation',
122 => '_sd',
124 => '_sd_alg',
126 => 'aud',
128 => 'cnf',
130 => 'description',
132 => 'digestMultibase',
134 => 'digestSRI',
136 => 'exp',
138 => 'iat',
140 => 'id',
142 => 'iss',
144 => 'jku',
146 => 'kid',
148 => 'mediaType',
150 => 'name',
152 => 'nbf',
154 => 'sub',
156 => 'type',
158 => 'x5u',
160 => 'AamvaDriversLicenseScannableInformation',
162 => 'MachineReadableZone',
164 => 'OpticalBarcodeCredential',
166 => 'TerseBitstringStatusListEntry',
168 => 'protectedComponentIndex',
170 => 'did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj',
172 => 'did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj#zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj',
174 => 'did:key:zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj',
176 => 'did:key:zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj#zDnaeZSD9XcuULaS8qmgDUa6TMg2QjF9xABnZK42awDH3BEzj',
178 => 'https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists',
180 => 'confidenceMethod',
182 => 'credentialSchema',
184 => 'credentialStatus',
186 => 'credentialSubject',
188 => 'evidence',
190 => 'issuer',
192 => 'proof',
194 => 'refreshService',
196 => 'relatedResource',
198 => 'renderMethod',
200 => 'termsOfUse',
202 => 'validFrom',
204 => 'validUntil',
206 => 'terseStatusListBaseUrl',
208 => 'terseStatusListIndex',
210 => 'challenge',
212 => 'created',
214 => 'cryptosuite',
216 => 'domain',
218 => 'expires',
220 => 'nonce',
222 => 'previousProof',
224 => 'proofPurpose',
226 => 'proofValue',
228 => 'verificationMethod',
230 => 'assertionMethod',
232 => 'authentication',
234 => 'capabilityDelegation',
236 => 'capabilityInvocation',
238 => 'keyAgreement'
}
上記の詳細については、6.3 実装上の注記を参照。
展開により、次の資格情報が得られる。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/vc-barcodes/v1",
"https://w3id.org/utopia/v2"
],
"type": [
"VerifiableCredential",
"OpticalBarcodeCredential"
],
"credentialSubject": {
"type": "AamvaDriversLicenseScannableInformation",
"protectedComponentIndex": "uggAg"
},
"issuer": "did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj",
"credentialStatus": {
"type": "TerseBitstringStatusListEntry",
"terseStatusListBaseUrl": "https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists",
"terseStatusListIndex": 3851559041
},
"proof": {
"type": "DataIntegrityProof",
"verificationMethod": "did:key:zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj#zDnaeWjKfs1ob9QcgasjYSPEMkwq31hmvSAWPVAgnrt1e9GKj",
"cryptosuite": "ecdsa-xi-2023",
"proofPurpose": "assertionMethod",
"proofValue": "z4g6G3dAZhhtPxPWgFvkiRv7krtCaeJxjokvL46fchAFCXEY3FeX2vn46MDgBaw779g1E1jswZJxxreZDCrtHg2qH"
}
}
スキャンされた PDF417 と protectedComponentIndex を入力として使用し、
3.2.4.4
opticalDataBytes の作成を適用して、
ecdsa-xi-2023 が必要とする opticalDataBytes を作成する。
canonicalizedData = 'DACJOHN\nDAQ987654321\nDCSSMITH\n' opticalDataBytes: [188, 38, 200, 146, 227, 213, 90, 250, 50, 18, 126, 254, 47, 177, 91, 23, 64, 129, 104, 223, 136, 81, 116, 67, 136, 125, 137, 165, 117, 63, 152, 207]
次に、3.2.4.3 ハッシュ (ecdsa-xi-2023) および 3.2.4.2 証明の 検証 (ecdsa-xi-2023) を適用して 資格情報を検証する。
最後のステップは、運転免許証資格情報の状態情報を確認することである。
3.2.3 Status
List エントリの変換を適用して、
TerseBitstringStatusListEntry を
BitstringStatusListEntry に変換する。
ここでは、'revocation' と 'suspension' という二つの状態種別を確認し、
これらの文字列を statusPurpose の値として渡す。
{
type: 'BitstringStatusListEntry',
statusListCredential: 'https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists/revocation/29385',
statusListIndex: 8321,
statusPurpose: 'revocation'
}
{
type: 'BitstringStatusListEntry',
statusListCredential: 'https://sandbox.platform.veres.dev/statuses/z19rJ4oGrbFCqf3cNTVDHSbNd/status-lists/suspension/29385',
statusListIndex: 8321,
statusPurpose: 'suspension'
}
これらはその後、 Bitstring Status List v1.0: Validate Algorithm と同様に検証できる。
コンテキスト用語から CBOR-LD 整数へのマップを構築するとき、一部のコンテキストには、 特定の型のオブジェクトの下にネストされた他のコンテキストが含まれることに注意。 これらのネストされたコンテキストは「型スコープ付きコンテキスト」と呼ばれ、 関連付けられた型がデータ内で使用されたときにのみ有効になる。これは term ID の 割り当てにとって重要である。なぜなら、コンテキスト内の用語は、そのコンテキストが 有効になって初めて ID を割り当てられるからである。これらのテストベクターでは、 二つの資格情報が同一のコンテキストを使用しているにもかかわらず、運転免許証と 就労許可文書で作成されるマップが異なるのはこのためである。
さらに、CBOR-LD では、関連付けられた値が複数である場合に、用語を表現するために 奇数が使用されることに注意。たとえば、上記の CBOR-LD term-to-ID および ID-to-term マップでは、"type" は 156 にマップされているが、VC 内で複数の型が表現される箇所では、 代わりに 157 が使用される。
appContextMap: [['https://www.w3.org/ns/credentials/v2', 32768], ['https://w3id.org/vc-barcodes/v1', 32769], ['https://w3id.org/utopia/v2', 32770]]
この節は非規範である。
この節には、この仕様に対して時間の経過とともに行われた実質的な変更が含まれる。
この仕様の内容は、標準化過程が開始された後に記入される。