Aries Cloud Agent Pythonでハマった点まとめ

Aries Cloud Agent Python(ACA-Py)とは

Aries Cloud Agent Pythonは非モバイル環境でDID(decentralized identity)のアプリケーションやサービスを動かすための開発環境です.

DIDに必要な処理がREST APIの形で提供されているので、APIを叩くだけでDIDが出来るようになります.

ハマった点

ACA-Pyは非常に有用な開発環境なのですが、デモに載っていない範囲が存在したり、ドキュメントが散逸していたりと、若干不親切です.

学習ついでに実装をしている中で、実際にハマった事がわりとあるので、備忘録的にまとめます.

なお、使用しているバージョンは 0.5.6 で、Ledgerはvon-networkを想定しています.

Ledgerとのやりとり

DIDに関して学習する際にACA-Pyのデモを参考にすることが多いのですが、（恐らくACA-Pyの範囲ではないため）デモではLedgerとのやり取りに関しては明示的には触れられていません

具体的には次のようなことです

LedgerへのPublic DIDの登録
LedgerへのSchemaの登録
LedgerへのCredential Definitionの登録

Public DIDの登録

von-networkの/registerに以下の内容のようなjsonをPOST

{
    "alias":"issuer1",
    "seed":"gLyjhihWzueCSkCygJEJdyzNHWMSPStM", //32byte
    "role":"TRUST_ANCHOR"
}

Schemaの登録

ACA-Pyのadministrative APIの/schemasに以下のようなjsonをPOST

{
    "attributes": ["hoge", "fuga"],
    "schema_name": "hoge",
    "schema_version": "1.0"
}

Credential Definitionの登録

ACA-Pyのadministrative APIの/credential-definitionsに以下のようなjsonをPOST

{
    "revocation_registry_size": "1000", //0にすると怒られる
    "schema_id": "hoge", // ↑のschemaを発行すると発行される
    "support_revocation": "false", // revocation(失効)を有効化するかどうか
    "Tag": "hoge"
}

issue-credential

Issue credentialの定義に関してはAries RFC 0036に記載があります.

これによると

Note: In Hyperledger Indy, where the request-credential message can only be sent in response to an offer-credential message, the propose-credential message is the only way for a potential Holder to initiate the workflow.

とあるので、いきなりCredentialをIssueするrequest-credentialは(Hyperledger Indyでは)ダメらしい（~~ACA-PyのデモではいきなりIssueしてたような...?~~ 明示的に行われてないだけで、勘違いでした）

なので、ここではHolderがproposal-credentialをIssuerに送るフローを想定します

proposal-credentialするには

proposal-credentialするには、Holderのadministrative APIに以下のjsonをPOSTします

{
    "connection_id": "hoge-hoge-hoge-hoge-hoge", // connectionを確立した相手のconnection id. /connectionsで確認可能
    "cred_def_id": "hoge:3:CL:15:default", // ↑で定義したcredential definition id
    "credential_proposal": {
      "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/issue-credential/1.0/credential-preview",
      "attributes": [ //罠
        {
          "name": "name",
          "value": "Yukuro"
        },
        {
            "name": "number",
            "value": "12"
        }
      ]
    },
    "issuer_did": "hoge", //issuerのDID
    "schema_id": "hoge:2:test-schema-01:1.0", // ↑で定義したschema id
    "trace": false
  }

なお、connection_idとcredential_proposalの箇所以外は全てoptionalらしいです

このjsonですが、attributesの箇所が割と罠だと個人的には思っています

というのも、attributesのnameにはschemaの属性名を、valueにはセットしたい値をいれるのですが、自分はattributesと書いてあるので以下のようなjsonのように書くものだと思いこんでました...(なので、気づくまでに1日溶かしました)

"attributes": [
    "name":"Yukuro",
    "number":"12",
]

このproposal-credentialを発行するとcred_ex_id(credential exchange id)というものが発行されるので、それを各エージェントのAPIで扱うという流れになります

おわりに

DIDは、ただでさえ新たな分野で参照元が少ないのに加え、ググることが大変に難しい(doの過去形としてヒットする)ので学習するのに割と苦労しています

今後もこのようなハマりポイントは出てくると思うので、追記したいと考えています

(あと、マサカリもお待ちしています)

yukuro’s blog

ぽえむ日記