//tips
//smart contract
現在受け取っている返答ではDatahubのRPC接続が問題かもしれないということがわかり、infuraを試すか検討中。もう少し返答待ちして決める。
作成するスマートコントラクトコンテンツに対してリサーチ。
信用スコアは本人を介さず第三者機関(銀行など)が信用スコアをはかりたい第三者機関に発行すると、個人情報の観点や情報の信頼性の観点で問題が出てくるので、個人に信用スコアの元となる情報を第三者機関が渡し、それをDIDに紐づいたVerifiable Claims(暗号技術で証明可能な個人・法人情報)として個人が第三者に信用証明として提示する形。
既存のイーサリアムのアドレスをそのままDIDにでき、パブリックチェーンにはDIDのJSON-LD（リンクドデータが入っているJSONファイル）に書かれたID情報（DID Document）までしか記されていない。
DID Documentは下記のようにチェーン上に個人情報を一切反映させないことができる。
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// this key can be used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"service": [{
"type": "ExampleService",
"serviceEndpoint": "https://example.com/endpoint/8377464"
}]
上記からDIDは単体では情報を持たないので、個人情報が入っているVerifiable Claimとの連結が重要になってくる。
このDID documentと同関連づけられるのか確認する必要がある。
一方でVerifiable Claimの流れを簡単に整理すると、証明書の発行の流れなので、要求元のholderに対して、発行者issuerが証明書を提供し、保管場所に登録、それをholderからverifierに承認をもらいにいくことになる。
holder: students, employees, and customers.
issuer: corporations, non-profit organizations, trade associations, governments, and individuals.
verifier:employers, security personnel, and websites.
verifiable data registry:
trusted databases, decentralized databases, government ID databases, and distributed ledgers.
この登録情報はチェーンにそのまま乗せるわけではないはずなので、一番知りたいのはここの原理。
Composition of verifiable credentials into a verifiable presentation for verifiers.
Verification of the verifiable presentation by the verifier.
技術的な流れを含めてパットのexampleを見ていく。
Pat receives an alumni verifiable credential from a university, and Pat stores the verifiable credential in a digital wallet.
{
"@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/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
Walletに入れたこのverifiable credentialを元にpatは同窓会割引を発動。
同窓会割引を発動されたverifier,(a ticket sales system)は調べ、きちんとPatの大学がそれを実行していると承認。
これらの手続きはpatのwallet経由で行われることになる。なので同窓会割引発動時には、patにwallet側から確認が行われ、それを実行すると以下の追記と同時にverifierへの確認が行われる。
"type": "VerifiablePresentation",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
これは@contextの内容の中のどれを対象としているのかの話か。
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
結局のところ、このURIに対しての閲覧権限をkeyでやりとりすることになる。
二つの流れがあるようで、issuerがこのcredentialを登録し、patがその秘密鍵を受け取り管理し、verifierとやりとりする場合、もう一つはissuerから入手した情報をpatが登録し、秘密鍵を生成し、issuerに承認してもらい、承認済みのものをverifierに提供するというもの。
後者が一般的なように思われるが、少しやりとりがややこしい。
URIをkeyで解除して使用することで、チェーン上のハッシュ化された個人情報をを復元するのか、単純に情報を閲覧できるように権限を与えるのかもわからない。
流石に暗号化されたものとはいえ、チェーン上に個人情報を格納することはないかと思うので、uriの遷移先に移れるようにするのが良さそうだが、これだったらチェーンを使わずに信頼できる第三者機関/管理系webサイトがまとめて管理すればいいのではと感じてしまう。特に管理しなくても、電子データとして保証がつくものを随時機関が発行できるようにしておけば良いのではとも思う。
理解不足の点もあるが、釈然としない。
うまくsignatureの部分を使いこなすと個人情報を防衛しつつ、チェーンにトランザクションは保管できるという構造はわかった。
参考資料：
