何もわからんから始めるSSI/DID

kokukuma

SSI walletsは、Verifiable Credentialsを保持しておくもの。
Verifiable Credentialsは、住民票とか免許証とかそういったもの...

kokukuma

なんか動かしてみたいな...この辺チラミしてみるか...
Hyperledger Indy・Ariesによる分散型IDアプリケーション開発ガイド

kokukuma

手元で動かすのはシュッとできそうだが、単語がわからん。
トランザクション、Genesis...

kokukuma

どのNodeを信頼するかを指定されている状態で、それを示してるのが、Genesis Transactionか...?

kokukuma

http://127.0.0.1:9000/ で「Register DID」したら、 http://127.0.0.1:9000/browse/domain のLedger Transactionsに追加されてますね、はわかるが、何が起きているのか全くわからん。

kokukuma

全体像がわかりやすい
https://www.amazon.co.jp/dp/B095Y5YC5G

kokukuma

aliceがholder、faberがissuer/verifierかな。

P.44あたりの話。
von-network起動した状態で以下をやる。

git clone https://github.com/hyperledger/aries-cloudagent-python

cd aries-cloudagent-python/demo

./run_demo faber

やると、transactionが4つ追加されている。Typeが異なる。
Type: NYM, ATTRIB, SCHEMA, CRED_DEF

こっちはなんかクソ遅い。

./run_demo alice

kokukuma

Invitation Dataを貼る

{
  "@type": "https://didcomm.org/out-of-band/1.0/invitation",
  "@id": "83b0d2a0-4db3-4f48-95ed-8790489430da",
  "label": "faber.agent",
  "handshake_protocols": [
    "https://didcomm.org/didexchange/1.0"
  ],
  "services": [
    {
      "id": "#inline",
      "type": "did-communication",
      "recipientKeys": [
        "did:key:z6MknHP6NYSk9pyFWtZVVky8UnGmCYKBBBV83K5b5yk6yRTu"
      ],
      "serviceEndpoint": "http://host.docker.internal:8020"
    }
  ]
}

kokukuma

Credentialの発行(store側)

  {
    "referent": "1f1b28c0-b671-447d-8387-f1dbe47258fd",
    "attrs": {
      "date": "2018-05-28",
      "name": "Alice Smith",
      "degree": "Maths",
      "timestamp": "1641342469",
      "birthdate_dateint": "19980105"
    },
    "schema_id": "5s4tN2sYgTYTsES82JiBxB:2:degree schema:16.30.99",
    "cred_def_id": "5s4tN2sYgTYTsES82JiBxB:3:CL:14:faber.agent.degree_schema",
    "rev_reg_id": null,
    "cred_rev_id": null
  }

kokukuma

6章のプロセス解説を読んだら、この辺使ってcontroler書いてみたら、もうちょい理解できそうな気がするな。

kokukuma

./run_demo faber --events --no-auto --bg

後、 http://localhost:8031 で立ち上がってるswaggerで見えるapiはどこのAPIか？
これはFrameworkが提供しているAPIぽい。
ControllerがこれらのAPIを叩く。

kokukuma

6.2 コネクションの確立でやってること

# Faberで, invitationを作成
INV=$(curl -X POST -H "accept:application/json" "http://localhost:8021/connections/create-invitation?alias=Hello%20Alice%201&public=false")
echo $INV | jq .

FABER_CONN_ID=$(echo $INV | jq -r .connection_id)
INVITATION=$(echo $INV | jq -r .invitation)

# Aliceで, invitationを受け取り, 接続要求をFaberに送る
RECE_INV=$(curl -X POST \
    -H "accept: application/json" \
    -H "Content-Type: application/json" \
    -d "$INVITATION" \
    "http://localhost:8031/connections/receive-invitation")
echo $RECE_INV | jq .
ALICE_CONN_ID=$(echo $RECE_INV | jq -r .connection_id)
curl -X POST -H "accept:application/json" "http://localhost:8031/connections/$ALICE_CONN_ID/accept-invitation" | jq .

# Faberで, 接続要求を受け入れ
sleep 1 # accept-invitation will request Faber async
curl -X POST -H "accept:application/json" "http://localhost:8021/connections/$FABER_CONN_ID/accept-request" | jq .

# Aliceで, 接続のstatusが変わっているか確認
sleep 1 # accept-request will request Alice async
curl -X GET -H "accept:application/json" "http://localhost:8031/connections" | jq ".results[] | select(.connection_id == \"$ALICE_CONN_ID\")"

kokukuma

credential definitions と schemaの違いがよくわからんくなってきた。

kokukuma

issue-credential/send、とおらん。。
400: Issuer has no operable cred def for proposal spec といわれるな...。 <- 単に指定するschema_nameが間違ってるだけだった。。schema_id渡してるんだからそれで引けよという気持ち...

6.5 Credentialの発行でやってること...

#bin/bash
set -x

# curl -X POST -H "Content-Type: application/json" -H "accept:application/json" "http://localhost:8031/connections/be1f5f0f-c428-4729-bfb6-8185182a752a/send-message" -d '{"content":"Hello"}'
# curl -X POST -H "accept:application/json" "http://localhost:8031/connections/be1f5f0f-c428-4729-bfb6-8185182a752a/send-message" -d '{"content":"Hello"}'
 

FABER_CONN_ID="3d03b292-d02d-4435-9638-61a97bf9dd7e"
ALICE_CONN_ID="ac0f1e5c-2f3e-4175-ba47-eb4c818ed4c6"

ISSUER_DID=$(curl -X GET -H "accept:application/json" "http://localhost:8021/wallet/did/public" | jq -r .result.did)
SCHEMA_ID=$(curl -X GET -H "accept:application/json" "http://localhost:8021/schemas/created" | jq -r ".schema_ids[]")
CRED_DEF_ID=$(curl -X GET -H "accept:application/json" "http://localhost:8021/credential-definitions/created" | jq -r ".credential_definition_ids[]")
SCHEMA_VERSION=$(echo ${SCHEMA_ID} | cut -d ':' -f 4)
SCHEMA_NAME=$(echo ${SCHEMA_ID} | cut -d ':' -f 3)

# Issue credential
REQ=$(cat <<EOF
{
    "schema_version": "${SCHEMA_VERSION}",
    "schema_id": "${SCHEMA_ID}",
    "cred_def_id": "${CRED_DEF_ID}",
    "issuer_did": "${ISSUER_DID}",
    "credential_proposal": {
      "@type": "https://didcomm.org/connections/1.0/credential-preview",
      "attributes": [
        {
          "name": "name",
          "value": "kokukum"
        },
        {
          "name": "timestamp",
          "value": "12345678890"
        },
        {
          "name": "date",
          "value": "2018-05-28"
        },
        {
          "name": "degree",
          "value": "Math"
        },
        {
          "name": "birthdate_dateint",
          "value": "19860328"
        }
      ]
    },
    "auto_remove": false,
    "connection_id": "${FABER_CONN_ID}",
    "schema_issuer_did": "${ISSUER_DID}",
    "schema_name": "${SCHEMA_NAME}",
    "trace": true,
    "comment": "comment string"
}
EOF
)

curl -X POST  \
    -H 'Content-Type: application/json; charset=utf-8' \
    -H "Content-Type: application/json" \
    -d "$REQ" \
    "http://localhost:8021/issue-credential/send" | jq .

curl -X GET  \
    -H 'Content-Type: application/json; charset=utf-8' \
    -H "Content-Type: application/json" \
    "http://localhost:8021/issue-credential/records" | jq .

kokukuma

うーむこのエラーから先に進まねぇ.

kokukuma

schema_nameの指定が間違ってるだけだった... updated

kokukuma

6.6 Proof要求および提示

#bin/bash

FABER_CONN_ID="3d03b292-d02d-4435-9638-61a97bf9dd7e"
ALICE_CONN_ID="ac0f1e5c-2f3e-4175-ba47-eb4c818ed4c6"
CRED_DEF_ID="JXrPkLknSoomUHTXqSiqpd:3:CL:18:faber.agent.degree_schema"

REQ=$(cat <<EOF
{
  "connection_id": "${FABER_CONN_ID}",
  "comment": "This is a comment about the reason for the proof",
  "proof_request": {
    "name": "Proof request",
    "nonce": "1",
    "requested_attributes": {
      "0_name_uuid": {
        "name": "name",
        "restrictions": [
          {
            "cred_def_id": "${CRED_DEF_ID}"
          }
        ]
      },
      "0_date_uuid": {
        "name": "date",
        "restrictions": [
          {
            "cred_def_id": "${CRED_DEF_ID}"
          }
        ]
      },
      "0_degree_uuid": {
        "name": "degree",
        "restrictions": [
          {
            "cred_def_id": "${CRED_DEF_ID}"
          }
        ]
      },
      "0_self_attested_thing_uuid": {
        "name": "self_attested_thing"
      }
    },
    "requested_predicates": {
      "0_age_GE_uuid": {
        "name": "age",
        "p_type": ">=",
        "p_value": 18,
        "restrictions": [
          {
            "cred_def_id": "${CRED_DEF_ID}"
          }
        ]
      }
    },
    "version": "1.0"
  },
  "trace": false
}
EOF
)
ISSUE_CRED_RES=$(curl -X POST  \
    -H 'Content-Type: application/json; charset=utf-8' \
    -H "Content-Type: application/json" \
    -d "$REQ" \
    "http://localhost:8021/present-proof/send-request")
echo ${ISSUE_CRED_RES} | jq .

PRESENTATION_EXCHANGE_ID=$(echo ${ISSUE_CRED_RES} | jq -r .presentation_exchange_id)
curl -X GET  \
    -H "accept: application/json" \
    "http://localhost:8021/present-proof/records/${PRESENTATION_EXCHANGE_ID}" | jq .

kokukuma

一通りの流れを把握して、動かせる状態になった(たぶん)、もうちょい実装よりのなにかをやってみるのがいいだろう...この辺使って、client作ったら流れがもっとよく分かるかな。