# DID/VCのW3C文書よんでみた
## W3C Decentralized Identifiers (DIDs) v1.0
https://www.w3.org/TR/did-core/
### Abstruct
DID とは識別子である。
**federated identifiers** とは違い、データ提供者、ID提供者、認証者とは疎結合になるように設計されている。
DID仕様書は暗号方式、検証方法、利用できるサービスを規定する。
これにより **DID controller(情報管理者?)** が正当な権限を持つかを検証者が確認できるようになる。
### Introduction
IDは世界中にとてもあるが、W3Cが管理しているわけではない。
任意の組織が好き好きに発行しており、「誰が閲覧できるのか」「誰が取り消しなど実行できるのか」などのIDの管理権限を持つ。
その結果、組織の崩壊によってIDが消滅したり、個人情報が漏れる、なりすましが生まれるなどのリスクが存在する。
DIDは、新しいインターネット上でユニークな識別子である。個人や組織が、信頼できるシステムを使用して独自の識別子を生成できるように設計されている。
加えてDID仕様にはディジタル署名など暗号方式も内包しているため、操作権限を持つ正当な個人|組織かを証明することができる。
Entity(個人|組織)が生成や表明を行う。Entityは複数のDIDを持つことができる。これにより各サービス、文脈などを独立して考えることができる。
DIDは、他の人々、機関、システムとの相互に連携できることを想定している。
DID-USE-CASE 文書に詳細は書かれている.
DIDは特定のデータ管理する技術や暗号方式を使うこと事態は前提にしていない。
なので既存のIDサービス提供者はDID連携ができる（今のID自体をDID準拠のスキーマに落とし込めばいいため）
### Sample Example
```
did:example:1234567890
```
- did: schema(必須)
- example: method識別子
- 12345...: method固有の識別子
このDIDにはDID document(実際の情報)が紐つく.
これはDID ResolverによってDIDから引かれる。（解決される）
method毎にDID Resolverが存在していていい感じにDocumentを解決してくれる。
```
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
```
DID URLはリソース(データ)がネットワークのどこにあるのかを示すもの。
- DIDのデータ
- 検証方法
- 使えるサービス
- DID文書
などにアクセスするために使われる。
### ConformanceとTerminology
省略、定義なので一度読んで
### Identifier
DIDの構文について
基本的にスキーマは RFC3986 に準拠している。
#### DID
```
did = "did:" method-name ":" method-specific-id
method-name = 1*method-char
method-char = %x61-7A / DIGIT
method-specific-id = *( *idchar ":" ) 1*idchar
idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded = "%" HEXDIG HEXDIG
```
(Note: `%x61-7A` は ASCIIの大文字と小文字 (A-Z a-z))
#### DID-URL
`did-url = did path-abempty [ "?" query ] [ "#" fragment ]
`
`path-abempty` は `*( "/" segment )`. 一般的なHTTP URLの下の部分
Note: https://www.tech-invite.com/fo-abnf/tinv-fo-abnf-uripath.html
こういう形も許される。
`did:example:123456/path`
`did:example:123456?versionId=1`
`did:example:123?service=agent&relativeRef=/credentials#degree`
`?` の後に `versionId=1` など条件をつけることができる。Query
一部のパラメータはMethodに依存せず共通で使われる（実装は必須ではない)
`versionId` `hl` など。
DID fragmentという一部分を取得するやつもある。
この場合は `public-key-0` 検証の方法。
```
did:example:123#public-key-0
```
#### Core Properties
DID文書のJSONの項目はここにある。
https://www.w3.org/TR/did-core/#did-document-properties
- id: このリソースに紐つくDID
- controller: このリソースの管理者のDID
```
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"controller": "did:example:bcehfew7h32f32h7af3",
}
```
#### Methods
サービス実装者がどうやってこのDIDに紐ついた機能を実装できるのかを書く。
> the means of proving control can always be transferred to another party by transferring the secret cryptographic material
DIDは秘密鍵を譲渡することで移転可能であり、
それを考えた上てシステム管理をしないといけない。定期的に正しい人が持っているか確認するとか。
#### Security Considerations
### 用語解説
**Federated identity**: 複数のサービスのIDを連携させる仕組み
https://www.okta.com/identity-101/what-is-federated-identity/
**DID controller**: DID文書の変更などできる管理者。一つのDIDに対し複数のコントローラが存在しても良い
https://www.w3.org/TR/did-core/#dfn-did-controllers
**Prove control of the DID**: 電子署名を検証して正当な権限を持つか確認(証明)する事
https://developer.iop.technology/glossary?id=proof-of-did-control-authentication-and-authorization
**SIOP(Self Issued OP)**: ユーザ個人の自己 OpenID プロバイダ
https://qiita.com/kyrieleison/items/7dda7bd78f341122f867
### DIF
https://identity.foundation/.well-known/resources/did-configuration/
## W3C Verifiable Credentials Data Model v2.0
https://www.w3.org/TR/vc-data-model-2.0/
### Abstruct
VCは一般的なクレデンシャル(マイナンバーカード,パスポート,運転免許証等) を、暗号的に安全で、プライバシーを尊重し、機械的に検証可能な方法でWeb上に表現するメカニズムを提供するものである。
データモデル。
### Introduction
証明書は能力の証明やどのレベルの教育を受けたかの照明などいろいろ使われてる。
ただ、未だ物理的なものであり、Web上ではまだ未完成な感じ。
Web上に上げたらプライバシーの問題がある。
現実世界の物理的な証明書は以下の内容を含むことが多い（以下主張という単語はこの内容を含んでいる）
- 持ち主の識別に関連する情報（写真、名前、ID番号など）
- 発行機関に関連する情報（たとえば、市役所、国家機関、または認証機関）
- 証明書種別に関連する情報（たとえば、日本ののパスポート、米国の運転免許証、健康保険証など）。
- 持ち主について発行機関が主張する特定の属性または特性に関連する情報（たとえば、国籍、 運転資格のある車両タイプ、生年月日など）
- 証明書の発行理由に関連する情報（学位を取った、試験に合格したなど）
- 証明書の制約に関連する情報（たとえば、有効期限、使用条件など）
VCは上の情報を持つのに加え、電子署名などを用いて改ざん防止できるようにして信頼性を向上させている。
VC保持者は Verifiable Presentations を発行することができ、それを他人に共有することで、他人にVCを持っていることを検証してもらうことができる。
#### 登場人物
- Holder VCを持っている人。Verifiable Presentations を発行することができる。（学生、社員など）
- Issuer VCの発行者。Holderの情報を主張し検証可能な証明書(VC)をHolderに送る。（大学、会社など）
- Subject 主張の対象。人やもの、動物などいろいろ。VC holderはSubjectであるが、そうでない場合もあるので注意。（子供のVCを持つ親、ペットのVCを持つ飼い主など主張の対象者ではない人が対象のVCを持つ場合も存在する）
- Verifier VC/VPを受け取って主張が正しいか検証するもの
- Verifiable data registry データを管理するシステム。検証を可能にするための関連データを保存、提供する。（政府のDB、ブロックチェーンなど）
### Use Cases and Requirements
いろいろな制約がある
- 証明書は、発行者が作成した主張を表す
- 検証可能な証明書(VC)は、改ざん防止、プライバシー保護の機能がついた発行者が作成した主張を表す
- 持ち主(Holder)は、異なる発行者からの証明書とVCをまとめ上げ、単一の主張(presentation)とする
- 持ち主(Holder)は、Presentationを検証可能なプレゼンテーション（VP)に変換して、改ざんを防止した状態で表明する
- 発行者(Issuer)は、あらゆる対象についてVCを発行できる
- 発行者、保有者、検証者としての活動は、当事者間の二者間信頼関係により、いかなる当局による登録や承認も必要としない
- VPは、任意の検証者が任意の発行者からのVCの真正性を検証することを可能にする
- 持ち主(Holder)は誰からもVCを受け取ることができる
- 持ち主(Holder)は、任意のユーザー・エージェントを介して任意の発行者および任意の検証者と対話することができる
- 持ち主(Holder)はVPを共有でき、検証者の身元を発行者に明かすことなく検証することができる
- 持ち主(Holder)はVCを、検証可能性に影響を与えることなく、また発行者がその保管場所やアクセスについて何も知ることなく、任意の場所に保管することができる
- 持ち主(Holder)は、主張の真正性に影響を与えることなく、またその行為を発行者に明かすことなく、VPを任意の検証者に提示することができる
- 検証者は、任意の発行者の主張の証明を含む、任意の持ち主(Holder)からのVPを検証することができる。
- 検証は、発行者と検証者の間の直接的なやりとりに依存すべきではない
- 検証は、検証者の身元をいかなる発行者にも明かすべきではない
- VC仕様は、発行者が一部（選択的）開示をサポートするVCを発行するための手段を提供しなければならないが、すべてのソフトウェアがその機能をサポートすることを要求してはならない
- 発行者は、一部(選択的)開示をサポートするVCを発行することができる
- 単一のVCが選択的開示をサポートする場合、持ち主(Holder)はVC全体を開示することなく、主張の証明を提示することができる。
- VPは、VCの属性を開示するか、検証者が要求する派生述語(Derived Predicates)を満たすかのいずれかである。派生述語は、より大きい、より小さい、等しい、集合の中にある、などのブール条件である。`if formula(x) then predicate(x)` (Memo: Derived Predicates)
- 発行者は、取り消し可能なVCを発行できる。
- 証明書およびプレゼンテーションを暗号的に保護し、VCおよびVPを検証するプロセスは、決定論的、双方向的、およびロスレスでなければならない。VC/VPの検証は、決定論的プロセスでこの文書で定義された汎用データ・モデルに変換可能でなければならず、その結果生じる証明書またはプレゼンテーションが元の構成と意味的および構文的に等しくなり、相互運用方式で処理できるようにしなければならない
- VC/VPは、1つ以上の機械読取可能なデータ・フォーマットで直列化可能でなければならない。シリアライゼーションおよび／またはデシリアライゼーションのプロセスは、決定論的、 双方向、およびロスレスでなければならない。VC/VPのシリアル化はすべて、決定論的 なプロセスでこの文書で定義された汎用データ・モデルに変換可能である必要があり、その結果、VCは相互運用可能な方法で処理できるようになる。シリアル化された形式も、データまたはコンテンツの損失なしにデータ・モデルから生成できる必要がある
- データ・モデルおよびシリアライゼーションは、最小限の調整で拡張可能でなければならない
- 発行者による取り消しは、対象者、所持者、特定のVC、または検証者の識別 情報は一切明らかにすべきではない。
- 発行者は、取り消しの理由を開示することができる
- VCを取り消す発行者は、暗号的完全性のための取り消し（たとえば、 署名鍵が危殆化した場合）とステータス変更のための取り消し（たとえば、運転免許証が 停止された場合）を区別する必要がある
- 発行者は、VCの中身を更新するためのサービスを提供できる。
### Claims
ある対象についての主張のこと。
ある対象とは、何かしらの主張が可能な物事のことである。
- ある対象（Subject)
- 関係性/属性?(Property)
- 実体(Entity)
の形で表される。
なお、一つのSubject複数のPropertyは伸びることもあるのでグラフ構造になる。
### Credentials
証明書。ある主体の主張の束である。
VCの場合は上の項目と、公開鍵、電子署名、証明方法などが入る。
### Presentations
証明書の主張全部見せちゃったらプライバシーがないので
検証者に応じて見せたい項目を制御したい。
検証可能なプレゼンテーション(VC)はVCと同じく与えられた情報を検証できるプレゼンテーションである。
複数のVCからデータを集約して一つのプレゼンテーションにすることもできる。
### Concrete Lifecycle Example
VC例
```
{
"@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'Université",
"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"
}
}
```
VP例
```
{
"@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'Université",
"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"
}
}],
"proof": {
"type": "RsaSignature2018",
"created": "2018-09-14T21:19:10Z",
"proofPurpose": "authentication",
"verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
"challenge": "1f44d55f-f161-4938-a659-f8026467f126",
"domain": "4jt78h47fh47",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
4vGHSrQyHUGlcTwLtjPAnKb78"
}
}
```
### Lifecycle
- 発行者は、VCを保有者に発行する。発行は常に、クレデンシャルに関わる他のどの動作よりも前に行われる。
- 保有者は、1つ以上のVCを別の保有者に譲渡することができる。
- 保有者は、1つ以上のVCを、任意で検証可能な提示物内にある検証者に提示する。
- 検証者は、提示された検証可能な提示物およびVCの真正性を検証する。これには、VCの取り消しに関する証明書の状態のチェックが含まれるべきである。
- 発行者は、VCを取り消すことができる。
- 保有者は、VCを削除することができる。
### 以下実装
https://github.com/ont-id/vc-go-sdk
https://github.com/ont-id/vc-go-sdk/blob/master/docs/interface.md
## W3C Verifiable Credentials API v0.3
https://w3c-ccg.github.io/vc-api/
https://w3c-ccg.github.io/vc-api-use-cases/
VCの発行、共有、検証をHTTP REST APIを用いて行うための仕様書
Swaggerとかもある
https://github.com/w3c-ccg/vc-api
# Self-Soverign Identity
Verifiable Credentials, blockchain, and Decentralized Identifiers (DIDs) are the three pillars of Self-Sovereign Identity.
https://kristinayasuda.com/posts/The-laws-of-Identity-in-SSI-era%C2%A0
# Service
## DID Resolver
DIDに紐ついたDID documentを解決するサービス。
https://github.com/decentralized-identity/universal-resolver
https://dev.uniresolver.io/
https://idmlab.eidentity.jp/2020/07/did.html
## Auth0Lab
VC
https://idmlab.eidentity.jp/2022/11/auth0-labverifiable-credentials.html
https://twitter.com/Auth0Lab/status/1587480458832617475?s=20&t=orriNq7nPQVKZHswRBsUpA
## Krebit
https://krebit.id/#/
OffChainの情報を読み込んでVCとして発行、DIDに紐つく形で他人に共有できるサービス。
Ceramics Network
```
did:pkh:eip155:1:0xdb10e4a083b87e803594c12c679422dce5fcccb9
```
こんな感じでOAuth認証すると、以下のIssuerによって発行。VCとしてOnChainに保存される
https://cerscan.com/mainnet/stream/k2t6wyfsu4pfzbplgs5cjnuoiuanxuttb99pb1d76xc2j8ee8iwnywy9lpsqrq
https://cerscan.com/verifiable-credentials/all
## GitCoin Passport
https://passport.gitcoin.co/#/dashboard
ネットの実績をIDに紐つけてショーケースみたいに管理するサービス
読み込まなかった……
https://go.gitcoin.co/blog/intro-to-passport
## Deck.io
https://www.dock.io/
VC発行サービス。
( https://www.dock.io/post/verifiable-credentials の記事から辿り着いた。 )
```
did:dock:5HMCUZxHLuM74YuEooTs6uD1yTpZs5rPYjK79DhkoRk84LH8
```
## Blockcerts
https://github.com/blockchain-certificates
https://lastrust.io/2019/08/19/blockcertstoha/
https://www.blockcerts.org/
https://github.com/pitpa/nft-vc
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/b2cdde1e-f172-4277-9204-20bd006660f1/415114c7/20221021_meeting_web3_outline_01.pdf
Sign in with Wallet
Connect another wallet