検証可能なクレデンシャルを実装する方法

问题

検証者が問い合わせる中央データベースに頼らずに、エンティティの属性（年齢、学位、会員資格）を証明する必要があります。検証可能なクレデンシャル（VC）を使えば、保持者が暗号署名済みのクレデンシャルを提示し、検証者は発行者に連絡せずに検証できます。

前提条件

• デジタル署名と公開鍵基盤の理解
• JSON-LD とリンクドデータ証明への習熟
• 分散型識別子（DID）に関する知識

ステップ

1. 1. Establish DIDs and verification keys

   Create Decentralized Identifiers (DIDs) for the issuer, holder, and verifier. Each DID resolves to a DID Document containing verification methods (public keys) and service endpoints. The issuer generates a signing key pair (Ed25519 or ECDSA P-256) and publishes the public key in its DID Document. Use a DID method like did:web (DNS-based) or did:key (self-contained). Use the RSA tool and ECC tools to generate key pairs and the JSON validator to verify DID Document format.

   入力

   entity: University | DID method: did:web

   输出

   DID: did:web:university.example | DID Document with Ed25519 verification key

2. 2. Issue a verifiable credential

   The issuer creates a credential containing: @context (JSON-LD contexts), type (e.g., UniversityDegreeCredential), issuer (DID), issuanceDate, expirationDate, credentialSubject (holder DID + claims), and proof (digital signature). Sign the credential using the issuer's private key with a Linked Data Proof (Ed25519Signature2018 or JsonWebSignature2020). The signature covers the canonicalized credential (using RDF Dataset Canonicalization). Use the JSON formatter and hash tools for canonicalization.

   入力

   claims: {degree: BSc Computer Science, holder: did:web:alice} | issuer key: Ed25519

   输出

   VC: {credential..., proof: {type: Ed25519Signature2018, created: 2026-01-01, verificationMethod: did:web:univ#key-1, proofValue: ...}}

3. 3. Create and present a verifiable presentation

   The holder creates a Verifiable Presentation containing the credential(s) they want to present, signed with their own key to prove they are the subject. Optionally use selective disclosure (BBS+ signatures) to reveal only specific attributes, or zero-knowledge proofs to prove properties (age > 18) without revealing the exact value. The presentation is sent to the verifier. Use the JWT encode tool to create JWT-VC representations as an alternative to JSON-LD.

   入力

   credential: UniversityDegreeVC | holder key: Alice's Ed25519

   输出

   VP: {verifiableCredential: [VC], proof: {holder signature proving possession}}

4. 4. Verify the credential and check revocation

   The verifier: (1) resolves the issuer DID to get the public key, (2) canonicalizes the credential (minus proof) and verifies the signature, (3) checks issuanceDate and expirationDate, (4) verifies the holder's signature on the presentation, (5) checks revocation status via the issuer's revocation method (StatusList2021, accumulator, or revocation registry). If all checks pass, the credential is authentic and valid. Use the hash-compare and JWT tools for verification.

   入力

   VP from Alice | issuer DID: did:web:university.example

   输出

   verified: signature ✓ | dates ✓ | not revoked ✓ | holder ✓ -> CREDENTIAL VALID

期待される結果

発行者がクレデンシャルに署名し、所有者が所持証明と共に提示し、検証者が発行者に問い合わせることなく暗号学的に検証できる、検証可能クレデンシャルシステム。

よくあるエラー

Not canonicalizing JSON-LD before signing

JSON-LD can have multiple serializations for the same data. Use RDF Dataset Canonicalization (URDNA2015) to produce a canonical form before signing and verifying. Without this, signatures may break on re-serialization.

Not checking credential expiration and revocation

A valid signature doesn't mean a credential is current. Always check issuanceDate, expirationDate, and revocation status. Implement StatusList2021 for efficient revocation.

Confusing JWT-VC with JSON-LD-VC

These are two different encoding formats for VCs. JWT-VC packs the credential into a JWT; JSON-LD-VC uses linked data proofs. Choose one and be consistent. Both are W3C-compliant.

トラブルシューティング指引

• If signature verification fails, check that the canonicalization algorithm matches (URDNA2015), the @context resolves correctly, and the verification method in the proof matches the issuer's current key.
• For selective disclosure, use BBS+ signatures instead of Ed25519. BBS+ allows proving credential possession while revealing only chosen attributes.
• If DID resolution fails, ensure the DID method is supported and the DID Document is accessible at the expected location (e.g., https://university.example/.well-known/did.json for did:web).

セキュリティ上の制限

• Verifiable credentials prove the issuer signed the data — they do not verify the issuer's claims are true. Trust in the issuer is separate from cryptographic verification.
• All signature creation and verification happen locally; no credential data is sent to the issuer during verification.
• Holder binding requires the verifier to challenge the holder to prove possession of the key linked to the credential subject DID.