Discuss cryptoscript and ioscript

[wyc]

Fun idea that resulted from a conversation with @clehner when we were discussing the best way to represent did-pkh. clehner suggested a mini stack-based language to express the different steps for PKH derivations potentially as part of the DID itself, and I added on this idea towards a system of unambiguous descriptions for verification methods/resolution steps.

cryptoscript

• A statically-typed stack-based language
• Can be used to unambiguously represent different verification methods for did-key and did-pkh in a straightforward manner.
• For convenient use in spec language (e.g., LD Signature suites) and production code alike.
• Formal proof-friendly. Perhaps can compile to, or is a superset of, or is implemented in, etc., Cryptol
• Maybe something like:

public_key_to_bitcoin_address(did:pkh:btc) :: (Secp256k1PublicKey) -> BitcoinAddress =
  push 0x0;  // mainnet
  sha256;
  ripemd160;
  dup;
  sha256;
  take_bytes 4;
  concat;
  concat;
  encode_base58check;

public_key_to_tezos_address(did:pkh:tz:tz1) :: (Ed25519PublicKey) -> TezosAddress =
  push (:digest_size, 20);
  hash_blake2b;
  encode_base58check;

public_key_to_ethereum_address(did:pkh:eth) :: (Secp256k1PublicKey) -> EthereumAddress =
  keccak256;
  drop_bytes 12;
  encode_base58check;

ioscript

• Same as cryptoscript but focus on defined access of external resources such as network, blockchains, etc.
• Can be combined with cryptoscript to define more complex DID methods, such as did-web
• Let's think through the error handling and failure modes
• Maybe something like:

resolve_did(did:web) :: (HTTPClient[tls], DID[web]) -> DIDDocument =
  to_method_specific_identifier;
  push "/.well-known/did.json";
  concat;
  resolve_https;
  validate_did_document_json;

[sbihel]

A few questions to play devil's advocate (hope it's not too rude).

cryptoscript

• In regards to Cryptol, could it be turned around and use it directly, but provide a transcompiler, similarly to the ability to generate Ocaml code from Coq?

didscript

• If one of the motivations behind it is to tackle the explosion of DID methods, if it is successful could it not act as an enabler and worsen the situation (i.e. kind of undermine the current/expected benefits of DIDs)?
• Can this level between DID interface/specs and language-specific implementation bring much value? In the case of blockchain DID methods, there aren't much implementation logic, most of the implementation challenges are around interacting with the blockchains, which didscript abstracts and thus doesn't bring much support for the implementation.

[wyc]

In regards to Cryptol, could it be turned around and use it directly, but provide a transcompiler, similarly to the ability to generate Ocaml code from Coq?

I think this is a totally valid approach! We could even generate Rust implementations and build system configurations based on user-selected cryptographic backends. This could require a dependency solver. I wonder if @robdockins has thoughts here or has seen similar uses.

If one of the motivations behind it is to tackle the explosion of DID methods, if it is successful could it not act as an enabler and worsen the situation (i.e. kind of undermine the current/expected benefits of DIDs)?

Could you please elaborate on the benefits that would be possibly undermined? If it's successful, then maybe we could see slightly less diversity in DID method constructions by biasing implementers to use what's already supported in cryptoscript. Can you think of other ones?

Can this level between DID interface/specs and language-specific implementation bring much value? In the case of blockchain DID methods, there aren't much implementation logic, most of the implementation challenges are around interacting with the blockchains, which didscript abstracts and thus doesn't bring much support for the implementation.

I think this depends on the level of abstraction that didscript aims to achieve. For example, it could be used in verification methods/revocation checking definitions as well, such as a certificate revocation list maintained on the bitcoin network:

check_revocation_status :: (VerifiableCredential[bitcoin.CRL.VCTrait]) -> RevocationStatus =
  dup;
  vc_to_uri;
  swap;
  bitcoin.CRL.vc_to_crl_txaddr;
  bitcoin.lookup_tx;
  bitcoin.CRL.tx_to_crl;
  swap;
  bitcoin.CRL.lookup_status;

[sbihel]

Could you please elaborate on the benefits that would be possibly undermined? If it's successful, then maybe we could see slightly less diversity in DID method constructions by biasing implementers to use what's already supported in cryptoscript. Can you think of other ones?

I suppose I was thinking of the recent critique from ADI. So things like overly frequent updates/deployments and resolvers getting bigger.

Probably also putting too much responsibility on the registry, or making it a bottleneck?

[wyc]

Yeah the DID method registry problem won't be resolved anytime soon. I think the market might be the best tool to solve that and an ordering of well-used methods emerge. Probably out of scope for this issue, which could also be used to implement ADI if desired. Maybe didscript should be called ioscript to reflect that.