ブロックチェーン アプリケーション シリーズ - DID

参考:
https://mp.weixin.qq.com/s/3pUC0uRwQAJJ-QC_FF-QTg

https://w3c.github.io/did-core

https://www.w3.org/TR/vc-data-model/#example-42-the-relationship-property-in-a-child-s-credential

初めての知り合い

ブロックチェーンを DID (分散型アイデンティティ) として使用したい場合は、次の 3 つの主要な点が関係します。

  • 分散化: ユーザーは自分自身のアイデンティティを完全に制御でき、パスワードを知っているのは自分だけであり、アイデンティティ情報を変更および読み取る権限を持っているのは自分だけです。
  • 相互通信: デジタル ID を一度登録すると、他のサービス プロバイダーのデジタル サービスにログインできるようになります。
  • プライバシー保護: ユーザーは自分のデータを保持するため、どのデータ サービス プロバイダーに電話をかけるかを決定できます。

個人的には、私たちのチェーンは DID に対応する基本サービスを提供できると考えています。

  • 分散化: チェーン上のアカウントの登録と権限認証。秘密鍵はユーザー自身が保持し、ログイン認証と認可に使用できます。
  • 相互運用性: チェーンのログイン検証ノード (API ノード) はアカウント権限認証サービスを提供し、他のインターネット/デジタル サービス プロバイダーは認証 SDK にアクセスします。
  • プライバシー保護:提示する証拠は権威ある機関による認証後に生成された証拠と署名であり、サービス提供者は個人データそのものを取得することはなく、提示された証拠を検証することができます

用語集

  • DID アプローチ: これにより、実装者は信頼できるコンピューティング インフラストラクチャ (分散台帳、分散ファイル システム、分散データベース、ピアツーピア ネットワークなど)で使用する特定の種類の DID を設計できます特定の種類の DID の指定は、DID メソッドと呼ばれます。DID を使用するアプリケーションまたはシステムの実装者は、特定の使用例に最も適した DID メソッドのサポートを選択できます。(ブロックチェーンを使用する必要はありません)

  • 検証可能なデータ レジストリ: DID ドキュメントに解決できるように、DID は通常、何らかの基礎となるシステムまたはネットワークに記録されます。使用される特定のテクノロジに関係なく、DID の記録をサポートし、DID ドキュメントの作成に必要なデータを返すこのようなシステムは、検証可能データ レジストリと呼ばれます。例には、分散台帳、分散ファイル システム、あらゆる種類のデータベース、政府 ID データベース、ピアツーピア ネットワーク、その他の形式の信頼できるデータ ストレージが含まれます。

  • 分散型識別子 (DID): 暗号化によって生成および/または登録されるため、集中登録機関を必要としない、グローバルに一意な永続的な識別子。DID の一般的な形式は、DID コア仕様で定義されています。特定の DID スキームは、DID メソッド仕様で定義されています。多くの (すべてではありません) DID メソッドは、分散台帳テクノロジー (DLT) またはその他の形式の分散型ネットワークを使用します。

  • 分散台帳 (DLT): イベントを記録するための分散型システム。これらのシステムは、参加者が運用上の意思決定を行うために他の人が記録したデータに依存するのに十分な自信を構築します。通常、さまざまなノードがコンセンサスプロトコルを使用して暗号署名されたトランザクションの順序を確認する分散データベースを使用します。デジタル署名されたトランザクションをリンクすると、通常、台帳の履歴は時間が経っても事実上不変になります。(例: ブロックチェーン)

  • DID: DID サブジェクトを DID ドキュメントに関連付け、そのサブジェクトに関連付けられた信頼できる対話を可能にする URI です。

  • DID ドキュメント: 各 DID ドキュメントは、暗号マテリアル、検証方法、またはサービス エンドポイントを表すことができ、DID コントローラーが DID の制御を証明できるようにする一連のメカニズムを提供します。

  • DID ファイル: DID ファイルには、DID トピック自体が含まれる場合があります。

  • DID トピック: DID トピックは、データ モデルなどの情報リソースです。

  • 機密であるべき PII 個人識別情報: DID メソッドの仕様が、公的に入手可能なすべての DID および DID 文書の公的検証可能なデータ レジストリ用に書かれている場合、DID 文書には個人データが含まれていないことが重要です。すべての個人データは、DID 主体の管理下でサービス エンドポイントの背後に保管される必要がありますサービス エンドポイント URL の個人データや関連性の誤った開示を防ぐために、サービス エンドポイントでの URL の使用に関して追加のデュー デリジェンスも実行する必要があります。たとえば、ユーザー名を含む URL を DID 文書に含めるのは危険である可能性があります。そのユーザー名には人為的な意味があり、DID 主体が共有に同意していない情報を誤って暴露する可能性があるからです。このプライバシー アーキテクチャを使用すると、DID 文書内の公開キーの記述によって識別および保護された通信チャネルを使用して、プライベートなピアツーピア ベースで個人データを交換できます。これにより、不変の分散台帳には個人データが書き込まれないため、DID 主体と要求者は GDPR (一般データ保護規則) の権利を強制することもできます

DID文字列

DID は、次の 3 つの部分で構成される単純なテキスト文字列です。

  • URIスキーム識別子(did)
  • DIDメソッドの識別子
  • DID メソッド固有の識別子。
did:example:123456789abcdefghi

DID ドキュメント

{
    
    
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    
    
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "service": [{
    
    
    
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

検証可能な資格情報データ モデル

この仕様は、暗号的に安全で、プライバシーを尊重し、機械検証可能な方法で Web 上で資格情報を表現する標準的な方法を提供します。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-MqTVx2oz-1639613215336)(https://www.w3.org/TR/vc) -data-model/diagrams /ecosystem.svg)]
[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-9togjJWX-1639613215338)(https) ://www.w3.org/TR/vc -data-model/diagrams/credential-graph.svg)]

EXAMPLE 40: Usage of the nonTransferable property
{
    
    
  "@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",
  ... }
}
EXAMPLE 42: The relationship property in a child's credential
{
    
    
  "@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": {
    
      ... }  
}

知らせ

同じ認証方法を複数の目的で使用しないようにする


過去の素晴らしいレビュー:
ブロックチェーン知識シリーズ
暗号シリーズ
ゼロ知識証明シリーズ
コンセンサスシリーズ
パブリックチェーン研究シリーズ
ビットコインシリーズ
イーサリアムシリーズ
EOSシリーズ
ファイルコインシリーズ
アライアンスチェーンシリーズ
ファブリックシリーズ
スマートコントラクトシリーズ
トークンシリーズ

Guess you like

Origin blog.csdn.net/wcc19840827/article/details/121966443
Recommended