Indy Interop-a-thon

Support for multiple networks in credential and proof objects

Key Objectives

• Issuers should be able to issue credentials across different networks
• Provers should be able to submit proofs with credentials sources from different networks
• Verifier should be able to verify proofs across different networks

Assumptions

• Ability to uniquely resolve a DID to a specific network. For example: did:sov:123 -> Sovrin Mainnet, did:findy:123 -> Findy
• Indy networks share same or compatible ledger object data i.e. a common Indy SDK can be used to access different networks

Questions/Work items

• Identify the scope of work required to support multiple networks
  • Should Indy SDK support multiple networks / automatic network resolutions
  • Should higher level implementations (Aries/DIDComm) be used to configure Indy SDK to work against specific network dynamically
• Should DID/network specific data be written on the ledger
  • Example: write did:sov:123 to the network, or rely on previous resolution and operate within the scope of resolved network
• Can multi-network be implemented with the current Indy SDK today? Yes, but relies on upstream implementations
• How to ensure that we have the same object across different networks?
• Should Credential related objects be anchored on the same network. E.g. Cannot have a schema and cred def across different networks
• Should schema/cred_def identifier carry the issuer/DID (Brent)
  • Today we have schema with id issuer_1:schema_name:1.0
• What is the scope of resolvers?

Required changes to credential and proof objects

From Indy SDK point of view, credential/proof objects can participate in the crypto methods regardless of which ledger they are anchored.

Should network be included in schema, cred def and rev reg ledger data?

Credential Offer

• schema_id
• cred_def_id

Credential Request

• prover_did
• cred_def_id

Credential

• schema_id
• cred_def_id
• rev_reg_id

Proof Request

• issuer_did
• schema_id
• cred_def_id

Proof

• schema_id
• cred_def_id
• rev_reg_id

Verify proof

• Collection all schemas, cred-defs, rev_reg, rev-states
• Where do we communication the ledger data?
  • Add resolution decorator
    • Format: Set of key/value pairs object identifier, resolution metadata

    ​​​​​​​​"~network_resolution":
    ​​​​​​​​    {   "2qepN78n9W5gYRMZ8Xxiv6:2:test-schema:1.0", { "type": "schema", "network/did_method": "sov_builder" },
    ​​​​​​​​        "cred_def:2qepN78n9W5gYRMZ8Xxiv6:3:CL:63:revoc", "bcovrin",
    ​​​​​​​​        "rev_reg:2qepN78n9W5gYRMZ8Xxiv6:3:CL:63:revoc", "bcovrin"
    ​​​​​​​​    }