本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント・一次情報と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

デジタルアイデンティティとは何かの続きです。前回は識別子・属性・認証という 3 つの要素と、三者モデルの形を整理しました。今回はそのうち「証明書の形」がどこまで標準になっているかを、仕様のステータスに当たって確認します。

「W3C の identity 関連の仕様」とまとめて呼ばれることがありますが、その名前の 1 本の規格があるわけではなく、複数の仕様が別々の役割を分担しています。W3C が決めているのは資格情報の形と識別子と失効の表し方までで、「どうやって運ぶか」「どう選択的に見せるか」「誰が発行者になれるか」は W3C の外にあります。仕様のステータスは 2026-08-12 に確認した値です。

層と、それを決めている主体

役割ごとに 3 層に分けると、どこが W3C の仕事で、どこがそうでないかが見えてきます。上の層ほど機械可読な仕様で決まっていて、下の層ほど当事者どうしの合意で埋める部分になります。

次の図には略語が多く出てくるので、先にまとめて開いておきます。

略語正式名称何を指すか
W3CWorld Wide Web ConsortiumWeb の標準を作る団体
VCVerifiable Credentials検証可能な資格情報
DIDDecentralized Identifiers分散識別子
JWTJSON Web Token署名を付けたトークンの形式
CBORConcise Binary Object RepresentationJSON に相当する二進形式
JOSE / COSEJSON / CBOR Object Signing and Encryptionそれぞれの形式に署名や暗号化を施す枠組み
SD-JWTSelective Disclosure JWT属性単位で伏せられるようにした JWT
mdocmobile document携帯端末で提示する証明書の形式
IETFInternet Engineering Task Forceインターネットの標準を作る団体
ISO / IEC国際標準化機構 / 国際電気標準会議国際規格を策定する団体
OpenID4VCI / OpenID4VPOpenID for Verifiable Credential Issuance / Presentations発行と提示のやりとりの手順
eIDASelectronic IDentification, Authentication and trust ServicesEU の電子的な身元確認とトラストサービスに関する規則
EUDI WalletEuropean Digital Identity WalletEU が加盟国に提供を求めているデジタル身分証アプリ
ARFArchitecture and Reference FrameworkEUDI Wallet の作りを定める参照文書

デジタルアイデンティティの層と、それを決めている主体を 3 段の帯で示した図。上段は「証明書のデータモデル層 ── W3C 勧告」で、2025-05-15 に主要 7 本が同日勧告（図は代表的なものを抜粋）と注記され、VC Data Model v2.0 (VC の形。他の仕様の土台)、VC Data Integrity 1.0 (JSON に proof を埋める署名)、VC JOSE COSE (JWT / CBOR で包む署名)、Bitstring Status List v1.0 (失効・停止の表し方)、Controlled Identifiers v1.0 (鍵と識別子の関係)、DID Core v1.0 (分散識別子。勧告は 2022-07-19) の 6 つが並ぶ。中段は「運搬・提示・制度の層 ── W3C の外」で、OpenID4VCI / OpenID4VP (OpenID Foundation、発行と提示)、SD-JWT VC (IETF、属性単位の選択的開示)、mdoc (ISO/IEC 18013-5、対面提示)、EUDI Wallet の要件 (EU の eIDAS 2.0 / ARF)、適合性審査のルール (各エコシステムの運営団体) が並び、右上に「別の団体がそれぞれ決めている」と注記されている。下段は「統治の層 ── どの規格も決めていない」で、誰を発行者として信じるか (Trust Framework / Trust Anchor List) が置かれ、規格は「この署名は誰のものか」までを保証するが「その誰かに証明を出す資格があるか」は各エコシステムが個別に決めている、と記されている。左端に上から下への矢印があり、下の層に行くほど機械可読な仕様ではなく人間どうしの合意で決まる部分が増えることを示している。

W3C 勧告になっているもの

W3C の「勧告 (Recommendation)」は標準化過程の最終段階で、各機能について十分な実装経験が示されたと W3C が判断したあとに与えられます。実装経験の評価では「独立した実装どうしで相互運用しているか」が主要な観点の 1 つですが、具体的に何を満たせば十分かは各ワーキンググループが定めます（たとえば DID ワーキンググループは、機械検証可能な規定について機能ごとに適合実装 2 つ以上を条件にしています）。勧告後も誤りの訂正はありうるものの、互換性を壊す変更は原則として入らない前提で実装できる、という目安として扱われています。2025 年 5 月 15 日に主要な仕様が同日に勧告となり、データモデルの層はここでいったん固まっています。

仕様ステータス何を決めるか
VC Data Model v2.0勧告 2025-05-15VC の形。issuer / credentialSubject / validFrom など、他の仕様の土台
VC Data Integrity 1.0勧告 2025-05-15署名の付け方その 1（JSON の中に proof を埋める）
Data Integrity EdDSA Cryptosuites勧告 2025-05-15上で使う具体的な暗号
Data Integrity ECDSA Cryptosuites勧告 2025-05-15上と同じく Data Integrity で使う暗号
VC JOSE COSE勧告 2025-05-15署名の付け方その 2（JWT / CBOR で包む）
Bitstring Status List v1.0勧告 2025-05-15失効・停止の表し方
Controlled Identifiers v1.0勧告 2025-05-15鍵と識別子の関係。DID の下敷きとして切り出されたもの
DID Core v1.0勧告 2022-07-19分散識別子（did:web / did:key など）

策定中のものも並べておきます。

仕様ステータス
DID v1.1Candidate Recommendation Snapshot 2026-03-05。勧告に進むのは早くとも 2026-04-05 以降とされている
DID Resolution v1Candidate Recommendation Snapshot 2026-08-06。DID 1.1 から解決の部分を切り出した別仕様（2026-02-08 の草案までは v0.3 と称していた）
VC JSON SchemaCandidate Recommendation Draft 2025-02-04
Data Integrity BBS CryptosuitesCandidate Recommendation Draft 2026-04-07。属性単位の選択的開示に効く
VC Data Model v2.1策定中

DID 1.1 での主な変更は、メディアタイプを application/did に統合したこと、1.1 用の JSON-LD Context を追加したこと、解決まわりを別仕様に分離したこと、Controlled Identifiers の上に載せる構造にしたことです。

W3C が決めていないもの

ここを混ぜると議論が噛み合わなくなります。

層具体例決めている主体
発行のやりとりOpenID4VCIOpenID Foundation
提示のやりとりOpenID4VPOpenID Foundation
選択的開示の形式SD-JWT VCIETF
対面提示・運転免許証などmdocISO/IEC 18013-5
適合性審査のルール何を審査して合格とするか各エコシステムの運営団体
制度・要件EUDI Wallet の要件EU（eIDAS 2.0 / ARF）
誰が発行者になれるかTrust Framework / Trust Anchor Listどの規格も決めていない

表の中の EUDI Wallet は、EU が加盟国に提供を求めている市民向けのデジタル身分証アプリで、根拠となる規則と参照文書 (ARF) が要件を決めています（後述）。適合性審査のルールというのは、たとえば Gaia-X であれば「参加者としてどんな記述を出せば合格とするか」を定めた文書のことです。

最下段については、各エコシステムがそれぞれ自前の名簿を持っています。Gaia-X の場合にそこに何が入っているかはGaia-X Registry には何が入っているのかで、学認の場合はアイデンティティ・ウォレットの 4 つの機能と、学認のトラストアンカーで扱います。

手元の資格情報を開いてみる

仕様の一覧だけでは実感が湧かないので、実物を開いてみます。手元には、Gaia-X（EU 発のデータ基盤の枠組み。位置づけはGaia-X の Lighthouse プロジェクトとはに書きました）の適合性審査を担う Compliance Service (2.12.0、Gaia-X Lab が公開しているもの) を Docker で 4 コンテナ（適合性審査の本体、そのデータベース、did:web を解決させるための TLS 終端、データ配信のノード実装である Ocean Node に判定を返すポリシーサーバ）として起動し、自分で書いた自己記述を提出して適合性証明を発行させる、という検証環境を組んであります。組み立ての経緯と詰まった点は許可リストに載っている本人が、ダウンロードできない ── Gaia-X の適合性証明を Ocean の認可に差し込むに書きました。ここではその出力ファイルを開いて、どの仕様が実際に現れるかだけを見ます。

python3 -c '
import sys, json, base64
t = open("out/compliance-credential.jwt").read().strip()
h, p, _ = t.split(".")
dec = lambda s: json.loads(base64.urlsafe_b64decode(s + "=" * (-len(s) % 4)))
print(json.dumps(dec(h), ensure_ascii=False))
print(list(dec(p).keys()))
'

{"alg": "PS256", "iss": "did:web:gx-tls", "kid": "did:web:gx-tls#X509-JWK", "iat": 1786546004151, "exp": 1794322004150, "cty": "vc", "typ": "vc+jwt"}
['@context', 'type', 'id', 'issuer', 'validFrom', 'validUntil', 'credentialSubject']

gx-tls は手元のホスト名です。実行は検証環境のディレクトリ直下で行っています。ペイロード側は次のようになっていました（credentialSubject の中は一部を省略しています）。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/gaia-x/development#"
  ],
  "type": ["VerifiableCredential", "gx:LabelCredential"],
  "id": "https://gx-tls/.well-known/compliance-credential.jwt",
  "issuer": "did:web:gx-tls",
  "validFrom": "2026-08-12T14:46:44.151Z",
  "validUntil": "2026-11-10T14:46:44.150Z",
  "credentialSubject": {
    "id": "https://gx-tls/.well-known/compliance-credential.jwt#cs",
    "gx:labelLevel": "SC",
    "gx:engineVersion": "2.12.0",
    "gx:rulesVersion": "CD25.10",
    "gx:compliantCredentials": ["… 3 通の資格情報とそのハッシュ …"],
    "gx:validatedCriteria": ["… 適用された審査基準の URI …"]
  }
}

読み方を補っておきます。@context は JSON-LD の宣言で、このデータの語彙をどの定義に従って解釈するかを指しています。issuer の did:web:gx-tls は DID の一種で、did:web は「そのホスト名の .well-known から鍵情報を取りに行けばよい」という素直な方式です。ヘッダの alg: PS256 は RSA の署名方式で、typ: vc+jwt が「この JWT の中身は VC である」ことを表します。gx: から始まるフィールドは Gaia-X 側の語彙で、labelLevel は適合性の水準、rulesVersion は審査に使われたルールの版です。

こうして見ると、1 通の中に W3C の勧告が 3 つ同時に現れています。

手元で発行した VC-JWT の各部分がどの仕様に対応するかを示した図。上段に JWT の 3 分割 (ヘッダ / ペイロード = VC 本体 / 署名) がドットで区切られて並ぶ。ヘッダの下には {"alg":"PS256", "typ":"vc+jwt", "cty":"vc"} が示され、対応する仕様として VC JOSE COSE が置かれている。ペイロードの下には "@context": [".../credentials/v2", …] と "issuer": "did:web:gx-tls" が示され、対応する仕様として VC Data Model 2.0 と DID Core 1.0 の 2 つが置かれている。署名の下には「発行者の鍵で署名、検証者はこれを確かめる」とあり、署名の付け方は 2 通りあると注記されている。下段に赤い枠で「入っていないフィールド」として credentialStatus が挙げられ、矢印で Bitstring Status List v1.0 につながり、「同じ日に勧告された仕様だが、ここでは未使用」と記されている。最下部に「このフィールドが無いと、一度発行した資格情報を有効期限の前に取り消す手段が資格情報の側に無い」とある。

現れている箇所仕様
@context の https://www.w3.org/ns/credentials/v2VC Data Model 2.0
issuer の did:web:…DID Core 1.0
JWT ヘッダの typ: vc+jwtVC JOSE COSE

署名の付け方が 2 通りあることも、この 1 通から見て取れます。

Data IntegrityVC JOSE COSE
形JSON の中に proof を埋めるJWT / CBOR で包む
見た目{…, "proof": {…}}eyJhbGci… の 3 分割
手元の実装使っていないこちら（typ: vc+jwt）

取り消しの仕組みが入っていない

ペイロードのキー一覧に credentialStatus がありません。ここを埋めるのが Bitstring Status List v1.0 で、同じ 2025-05-15 に勧告になった仕様です。無い場合、一度発行した資格情報を validUntil（この例では 90 日後）より前に取り消す手段が、資格情報の側にありません。

アーカイブのアクセス制御に使う場合、この差は実務上効いてきます。研究者の異動、倫理審査の承認取消、鍵の漏洩といった事象が起きたときに、資格情報そのものを止める経路が要ります。手元の環境では現状これを実装していないので、次に埋める候補の 1 つです。

なぜいまこの話が出るのか

  • 2022 年: DID Core 1.0 が勧告。識別子だけ先に固まる
  • 2025-05-15: VC 本体・署名・失効がまとめて勧告。データモデルの層が揃う
  • 2026-03: DID 1.1 が Candidate Recommendation。実装による検証の段階
  • 並行して、EU と日本で制度の側が動いている

EU 側の動きが eIDAS です。電子的な身元確認とトラストサービスを定めた EU の規則で、2014 年の規則 (EU) No 910/2014 が最初のものでした。その改正が 2024 年 4 月 11 日の規則 (EU) 2024/1183 で、欧州デジタルアイデンティティの枠組みを定め、加盟国が市民や居住者に EUDI Wallet (European Digital Identity Wallet) を提供することを求めています。通称として eIDAS 2.0 と呼ばれます。ウォレットの具体的な作りは ARF (Architecture and Reference Framework) という別文書で規定されています。

日本側では、国立情報学研究所 (NII) と伊藤忠テクノソリューションズ (CTC) が、学術機関のデジタル資格証明の標準化に向けた共同研究を 2024 年 10 月から 2026 年 3 月まで実施しました。学位・学修歴・学生証を対象に、学認のトラストフレームワークを参考にして、デジタル署名を検証できるアーキテクチャを検討する、という枠組みです。

ここで言うトラストフレームワークは、誰が発行者になれるか、何を証明してよいか、違反があったときにどう扱うかといった、技術仕様の外側にある規則の集まりです。学認は SAML を前提にしたその規則を既に持っているので、VC でも通用する形をそこから起こす、という位置づけになります。公表されている資料では、W3C の Verifiable Credentials と ISO/IEC 18013-5 (mdoc) のどちらを採るかは未決とされており、課題として技術規格の分断、属性定義や多言語対応の不統一、正当な機関を認証する仕組みの不足が挙げられています。

規格が固まったので、次は誰がどう使うか、という局面に入っているように見えます。

紛らわしいので注意

W3C には Federated Identity WG という別のワーキンググループがあります。そこで策定されている FedCM (Federated Credential Management API) は、ブラウザに組み込むログイン連携の仕様で、サードパーティ Cookie の廃止後の SSO (Single Sign-On) を扱っており、Verifiable Credentials とは別の話です。

ただし、同じワーキンググループは Digital Credentials API も策定しています（2026-08-12 時点で Working Draft）。こちらはブラウザがウォレットからの資格情報の提示・発行を仲介する API で、提示に OpenID4VP や ISO/IEC 18013-7、発行に OpenID4VCI を組み合わせる想定になっています。上の表で「W3C の外」に置いた運搬の層と、ブラウザをつなぐ位置にあたります。

つまり「W3C の identity」と言われたときは、VC / DID のデータモデルの話か、FedCM の話か、Digital Credentials API の話かを確認したほうが噛み合います。アーカイブのアクセス制御の文脈なら、通常は 1 つ目です。

出典