sicpa-dlab / didcomm-rust Goto Github PK

View Code? Open in Web Editor NEW

25.0 25.0 19.0 1.81 MB

License: Apache License 2.0

Rust 77.14% TypeScript 7.90% JavaScript 0.05% Swift 13.74% C 0.70% Makefile 0.09% Ruby 0.39%

didcomm didcomm-v2

didcomm-rust's People

Contributors

Stargazers

Watchers

Forkers

denisrybas andkononykhin spivachuk ashcherbakov jaroslavsaxa rodrigofranzoi alexandershenshin andrej-zirko jakefernandes98 web7foundation francis-pouatcha techslice-official styvane elribonazo esatus carez

didcomm-rust's Issues

Routing Keys should be optional

When I try to use a did document that has a service block without routingKeys it blows up complaining it doesn't find the routing keys. These should be optional as seen here

Adding extra header causes error (Happening on Uniffi Swift) probably on rust version as well

What

While using version 0.4.1 in Uniffi Swift, whenever I try to send a message with extra headers I get the following error:

UniffiInternalError.rustPanic("Failed to convert arg \'msg\': Malformed: Invalid json value: expected value at line 1 column 1")

Why

Because this makes extra headers unusable in Uniffi swift, and also makes protocols like the (Pickup protocol) [https://didcomm.org/pickup/3.0/] unusable.

Success Criteria

Successfully pack a message with extra headers.

Anything else

(Return Route)[https://github.com/decentralized-identity/didcomm-messaging/blob/main/extensions/return_route/main.md]
(Pickup protocol)[https://didcomm.org/pickup/3.0/]

What

I was just installing the didcomm npm package and ran into some errors

Why

I could not find any documentation on the nodejs api so I wanted to install it to discover the api.

Success Criteria

install didcomm node package via pnpm and import it successfully.

Anything else

When importing like this:

import * as didcomm from 'didcomm'

I got this error:

(node:64180) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/username/Work/jlinc/didcomm-npm-install/node_modules/.pnpm/[email protected]/node_modules/didcomm/index.js:1
import * as wasm from "./index_bg.wasm";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:73:18)
    at wrapSafe (node:internal/modules/cjs/loader:1166:20)
    at Module._compile (node:internal/modules/cjs/loader:1210:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1300:10)
    at Module.load (node:internal/modules/cjs/loader:1103:32)
    at Module._load (node:internal/modules/cjs/loader:942:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:168:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)

I added these two lines to node_modules/didcomm/package.json

{
  "type": "module",
  "main": "index.js"
}

and it fixed the import problem.

My Environment

Node v19.5.0
pnpm 7.29.0
Macbook Pro Ventura 13.2.1

What

Give a brief description of the objective of this issue. What needs to be discussed?

Test vectors are not really testing different things. The test vectors currently only thinks about JWK methods. But your documentation have lots of different types.

I believe this lib should expand its test vectors to showcase more diversity of crypto

Why

Explain why you think this issue needs to be addressed and why it should be addressed in this repo.

Because it helps other people use this library more efficient as well and not hitting their heads against something that is supported but not documented

Success Criteria

Explain what actions or decisions need to be completed to close this issue.

Using a task list here can be helpful to track progress.
Easy for newbies to start and see how they can do things with tests, to cater for their environment

Unsupported prefix from multibase key

What

The library appears to have issues with my multibase encoded private key (Ed25519VerificationKey2020) as it throws an "Unsupported prefix" from (here)[https://github.com/sicpa-dlab/didcomm-rust/blob/53dcbbcfec906c15ccf3ee94b275dbb61d026ff4/src/utils/did.rs#L453]. I have checked and the prefix isn't what it expects there.. I have tried with some of the test keys used in this library so I'm not sure why this is happening.. I also haven't seen anything about those prefixes anywhere so I'm not sure where they are from.

Why

I am unable to sign a message with my multibase encoded authentication key

Success Criteria

I am able to sign a message with my multibase encoded authentication key

unpackedmessage.as_value() does not provide decrypted version of the message

What

When I receive a message that is encrypted, and run it through unpack with the right secrets and resolvers. I expect that I get an object I can work with that is decrypted and possible to read the datat itself.

But the object that is provided is an object with a ciphertext. Since I was not the one encrypting the initial ciphertext, I expect that the library will provide me with a way to get the clear text message out.

Here is an example of the unpacked.as_value() message

{
    "id": "36f2a86e-5b25-4baf-9f7f-40d978590316",
    "typ": "application/didcomm-plain+json",
    "type": "https://didcomm.org/routing/2.0/forward",
    "body": {
        "next": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
    },
    "attachments": [
        {
            "data": {
                "json": {
                    "ciphertext": "EvyxDoHnIYCc0iFhenovIaiJfnIDWlE1brmoqLlNaVoHJ6oGuSWp_UaiqT2yGCZiKKP4E0mptTM14TD9dYpiAKajcjhIKFIeDCMyyaKdusdd6V6C7On98D9uEW9vqW6VDn-EygIv1ZTQInJ3P0ec_my-x1L2G6CReM7p5uDyfI0xIYzr_Lv8cTNRJIna5HOXEPq04fSf-BQZDX3DiL-wcdO-HCy4qL_udevp9hUla7Xam1xhnU_7pttu7ygHnSrtjJMyzNymNSsb1mNgz3qio-_d_MW2xyhoMtQzig7TVnB9CIYpvMRg-HSwMLwkxGDHxwBZIH_EaYxOcmZIA6QoJ6gljRIyVB_4AbAiJuzMEZpRbcdtg0kgpY632Rs8jloHkf_RS3AY3ZaatOl6x1JbI9JgFpprow2L5rwnvMOxU3i3sV_jwKtEccxcS2oVxYOFBIAei2kw6Bk3Oz-sCmCwYMdy23F95WYo_1Ma16-i-I3JQpkHUvlmwnDOOc-0Qz245SxohM9Fqg1bmBpEMvSoYi93gnBexthUV89K7KJT_ja1ed_ZZsoChMS3U3E1nfge9SY6uRs4JRKdDT0kfzu3Wb-fXQJtdNcnvqN_fT29a59SiQv9vm8J2iw6pVw3E_9msEHCFeEc-d1A01J-yllqHU8pjljrK11dHDSqyUfHCEsd0vsZuxJjN3Q042SwfSduGL8puxz3hNed8d2PnkLr-6i0LLrvYU5mnddlsZt-xqq22RLxN08NauBdyOSzykTRUUx8ClqyzuAwVY9RjOybagIiJpnlEbieYXbSP2ruu0F6sytArC0ZSEMl5jLNAGq0I9FjrcS7Mqv_E76s2qOSEUPcHnw8hHd7gcryjEgjxntUtAB53JhgEJNkQifFABXg01mu8k-rPIpVtGIOhqG_rEIePbKALk25aX4uMoGHHcsAAGfwgDGM_LsHl35zpGtjDB3yON3toB2UpMShKYdJH9FBijA-BhUEEutJjqxxMcbouGTcD9gl7PxYCdEq4oPAo74kND4WquixiRyKjiOsSEADNbzyISl40USMXNskUfokZHIDwqu224SjjH7lcu6nz0vz85ku1cuOMXNVv4GHbX8-P9dii65Iwn7F_QVb_-i50BTVpYvDUt1F4AUbvbu0mIypyTyX4Emp5XaLFtRvukilAEn6EhfT4oZPveKon3DnnimerdDm-ebarvO04LjnAF5NBNomocCb4-Ep-6uWdljxJDrVYNFo-GqWvUYRhlbVg3aTwOGs0v_6Mah4iKhLA7i4UOb6doF5D6DLnjr3Fz7_XOcqebmPb7ExeOdcBvMWRuDHKfmPLlcp__rDOCLZ2KXvI6HBnWZ3NVbMTYn512PsXGaJ0N64UVCiW6piiTPKBdpfPEPgnOM70xVdfMpax9ZtihXvxPjxZ1dOVYhIsIv9_b0kpcUtbV13bReKks_1mVp1LOyHN75DyUvsq0CRgT6-NNnYod0tLFsd8uYaXtGF44qvwj6WlGDW8g1lcB6UroSAcSnfoCu5LWDKOdiWfnR2QZD0mrNv0YAGr63BFo7hUFX2f3a9XX60aDL0IumkcJ5FLCYMjkRUkL7AglNw707SdAKmE1mnEz2TfnYpvEY9NzYgpoOL_sXissf-HS41JYppcuCusdomUiUMrQXPSbXOZ2HNRJrvrP0DGix56bmsL315njkFZ3SxUcczaCbPUzT8YBD475GWnaPDwDiVUUf7NnK7flNVshviMZK_8JMOH0EvDnzIm_hfeTTO3SxQxshFb7XqmYVolXs73HdaWXG44jrK__F6SSzr3h-ZzChBEaz8cnC037Jr2P0PoOPExaZIkJgTXRMtDGT0hrm6X8__xQZtWRVeeG14p4c3hIaBSbiofOjZdLgfBKw4Vz2etH3QNC8DupqGDQ2HoGivbsPvpgF2CpDSdlq1oOJMW3NFvUxizVN6mju8edXKCoj8RCmEhzpvBAqB1_Ir6gPPr7p_z3r1_QN0GNW9rKqSiBfFBmc2y3fuWxYrsL-vrJDwfTOGv9cEwboOeUArG501iObfaKKEZBtZzJIj-WLBGgsSsjrbkvqUDnb763y07ym7pZhKQaYmx2INKwPu0sdBPJYpE8ChuQGbpK9iclhx7bXpejvbRltyxHPdWAJlLFgbb4xvcxM6igseZ1wNqxo_DaNjyxTcVsIVa8BkKVj6jnHsMciqkbbQ78uLQBaUTVwWak6blr4oFbH79fWOPzN4qxp9AakhQRJR3EJfovw1R6lO9WOa38wKljvVkd_Zah_0RPRNZpuKrxylEFgAVUKh3JdUwD6zREvLw39ahj3b7LbajYdvFgLeMuRhkkLrY89LS54JHrovpgNvb_NBWGT8F2MNzRF7Ty-UJFeyfHdKRl0O9gOog189Ogqg_VuWesWftomkaj-YHqsYw4SeS7SBSg4zu6C7P-CirM0LPMvGK6AaGfmsL2Q7Vrsph56UD2FvRi8VAPbTivbcN3rJeotZ57S3sETFEXp_o9SwvlNRgpxHyJvadlad9KVAVhBihir-elrsfZTLomwsX55Ruj5GjGZsAr6sLmVLI9zxqgA9b_fxSiBg08IjVE4wn7_0KtFA8eafqDeXJREFQTooD6-GucrNeXN6yzZamJiyyBWx_tui2W6UCs554VW8Z3n2JtJNZDAazEQlB8JhfyUeYIbOsYWfOfx0hHMxYbaD30lp_q4r9KBYqYviX6ign8Bk9mllqeXV4Af30TSzcj5mFuumdL8ZedErMvyKBlU36p6NyyZs2c5phtTNLbPy-WgdblyvdDBFaxT5BLyJjZxzFVy5TlRLgOV7mBBxVY9ScP2z638J4hFqA6_-EuPBjPw4jOLOAmzHly85hyIC0zA8pSwrPaFqg3GYAoph-A25RjPTPtykbUrC2OgXM9GtJAQTrT4RTvYPLKSo3nINwoAp8845e0BbNUfp6-odCQaHVtm35rFezOBdqe0tsZlrCnA6m-fBs-3sOJObjhW-JrteHofmxQTDpxF5PZLYXTffBajbPeB_gbCsvd0VZ5KiXlCCLPyrE7VnTnbF023gzob8xGfYp1E4tv3OvVXRHaE_OCQxA4SsPDj5UVMzQ-4_PK5KziF79qHLot1uUbohSgbJLtie6Qj5hnjQWw-pnkVDVFIhHw3qmu8et4maFauZSEL2jNvwuzSoZAm8dsN6raQniypE_5SPnn0D1QlYBwNy3jeeVJ5G0oruAjPRriGIUGlsEeRPn1cEQfouCzxF5frw-w5SkCtpUFqiy9ZNKsjtGkQBDPq8P1iOlfoYGfTyfxYwJOsb3aQoqZoynITY0kDSY1b1HrxTpJY0YTpVLLBR_nvpsMjezEXeQVuCmJDBbRvy36x2D3JH-dIu0QHTGlIR1FuBJsaPb2qZLf7wEcPZ8ELO2yGpn27JooeNEsDM_vf8mIvd3D-W4CyKs77J32hH8Dx_il70E-mybyBLyO8sWRRnVioHTcs55STTTUpFPYHDQPlLpyetMx9Vz19Sl0ZoS1jXDxJq3yua3t19d0upPETpE7zTUnTsimdjaMXWDpDdALFObO_85zLXbpRcyM8705J3JPcHbez1IiPfwAk5Tcq-zS2Ejed5wXU23_xt36BPTJBsdKkXhQToN9SrxK7ac586y4Lzncj44SSFReUSw1pf7G3z67dudC6T84lL6vcYYbGLGgvKZHlvnZ2MHkPRoYFImYZ03GWYQ_xC9Fk2DRm4VqB3QqJBBslHyIne3xeGp3aq-_dzL3CepaCRXLcsFl1Qh1e_riaVf2zrkq3oXEUKAWErD1muairiR7jT-2MFesSciy4IFLlsBTj2hsPYhPmRR6SCyCt-E3-gWXTSUyRFgj2G2WtceT44DGz37aCT5_BOsPXlOBeolqTWCFgrKbwX1tFSa1nYrO-Xx8hu73XuczilXdN-c7Lb8WxTk7QvWE37tEM3O_y-IFurMob4xSo9AhXTvS2nQ9PmWiedq8jLjFr2SNjA6iPE7lTxx69uO4S-jwW_WAN7r56Z062EiwkOwjtex2ykW2SbpkmyY6tX5wlnMZenJo22a52jIrbMABVbRk_xfAgDXMhPtctX8dgobDM2G273LDdCet0Rzcs8QvEN0e1zfcRAGawF2_EZ5dDdd2rpVk3vep_NUOY03qONZcHFfMzl2O39D9QaEcdS7Xt-BUTuMJlZYAZG2K1tfSTlyvw89ceDnEqvxrI9PfhQM9uoZ5FrBY2x9aN0-U4O2YKr_nlL6wyGgbExmzFBmuRcRJvLnii6Maet-IEt4B5F5Say6biJvPWIXT3JJkbq39lQDMVCjWiXllSVv90tmOZoeQX4W59q5UYMqvZp3-l9KXgS6szd95e904GU1X3xFd6NNiU_Na83t1gMJ-c2x6UIp9CF2p77MjesybVelV5VLxYfk2C8gFEduJjH9WsF0bMfa-gYtdaRfycpNf_RL9l76jckm4p18qrbpm0d1pdhRqVhJmLxh5I-x4Do3QTv2QHt5M6v8849Y5h-V-wm_SK-4snPKL19ZaB-1Q_1flta8UVYfS_kCqrks1zdnbZf6KBz_rXnFe2NmNbIs2WY9JxmS9uvsSda5baOxUnI5yUXD4OuiphSg-sC4-UlWcFa8icJuf4cP9XwGlnIcBz4w-9Ecgiv4eyRpDyDTALkkAbuaiynwpKV44B0JtuyzaCi0zVFzm68-1mVFOHjEkfC2Vtp2DlpLdNW0pHof5_LlaUk--XdUM88XchSK-dcrck1kq1AE3HxMVcLNm9QKoga3f8EcgfQiD2B4230nutEcUP2dRXaC9rfTHC7cuzQmtMb1_ktLutM8f7U0bce4SJyenxYCaqduxhzwylJBo5e2kDWTJqK0NUUF47yYDD9ybroyWvfY_cjuUNbqMxVEerz5ZtSO9sqBE6TeHWPDsSJVjr73vQb5YEUWSba0u_irqBls_sgha7e3MP9NXp6SSO1xf9uNgct7CJVgNvYgQDZNdQgpDx-iTBDLeCkhapB3XNJFMpdzdrdJqxu6-oW8qpKrP6NlGuNSl7G3LwIfhFTV9auFOGRkDCzUC4RJ8e8Do-2DNJCBY_fbclxnLD3y2SZLI5bfH3yHQhN_Ayfn0uePVA2m-pbK6QafohqtdngFn63NrS19QIfw29py2LTP4iVEspzIfDhwJnSgIdk_jS9FbMbDvjLTrrPmvUf5If3cCTeHgH-lZmlruIqhhASgNpjLppHrjwg-1S0KxuoWJxSpdHvQ36G2_hFM8z5jrbow4h9X6QDq8wNV-cT6GS5zJGaQRO61nHOg-0XpRUHUYpxukIHritIjTIqiF_VgSq0X7COodZeM1h54rb37FS7i-v337r5slBUl9x8D7EXraGuu6xPuDG6fMmefYiMfNmwY07l8gR6fWdSLj_vTdPlxIMaAXYdjppaNVqPyYa2DvV4gu_Mk9rhzbB0rw3sx5a9SNOPEHvXinc-5U2RSMrivo8OM7FcM3jZw__gkgCsRgCqy8PXrkwg5wmPJU9vQRhf_VPvArRPfPjhTzJsu-9prZILnnMkvBQx8K-4yD8-Co9jCbhBXSTjyPDeGF59Yr_Qum5yxfBVcrF2nquTvi4FzRd_ehXbIeSAT3Ue9IzBt96xHl4giVTW_yrda_1efCAURDc",
                    "iv": "ppQiLheseVBGRfdsXVxnhQzQF1kavfZF",
                    "protected": "eyJ0eXAiOiJhcHBsaWNhdGlvbi9kaWRjb21tLWVuY3J5cHRlZCtqc29uIiwiYWxnIjoiRUNESC1FUytBMjU2S1ciLCJlbmMiOiJYQzIwUCIsImFwdiI6IkJCLW9GVjBKemZoQWFFNjlQS3VaRmQ4dDhWZ19hQzhfTlpUNTM3NkxCOFEiLCJlcGsiOnsiY3J2IjoiWDI1NTE5Iiwia3R5IjoiT0tQIiwieCI6IkdmYUhrbHFUdWk3VUhSTXJIYms2Y0llNjFkbDhkd2tqQUZCcTI2aGMzUjgifX0",
                    "recipients": [
                        {
                            "encrypted_key": "QlQcNWkAUKbmOhDagbX5Vo9w1BzowrwfIrDtPxkpFXjtzwyq0tYiGA",
                            "header": {
                                "kid": "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19#6LSm3LPo"
                            }
                        }
                    ],
                    "tag": "Ba3PnsIur7cgeLxSSH_CNw"
                }
            }
        }
    ]
}

Why

Because its not usable to actually consume the message itself that was sent.

The message below was the original message going through the encrypt message function.
And I want to see that after I unpack with the right secrets.

What am i missing?

{
    "id": "1234567890",
    "typ": "application/didcomm-plain+json",
    "type": "http://example.com/protocols/lets_do_lunch/1.0/proposal",
    "body": {
        "messagespecificattribute": "and its value"
    },
    "from": "did:peer:2.Vz6MkkkhBpeffjdyRCpyv1h17ZH4fJ6amEu2cujuaBcf2bmor.Ez6LScPkBqUGgUnFdxEPviCBAhdeKrhrHidLCyrcjq6SdvSj6.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19",
    "to": [
        "did:peer:2.Vz6MkhMTSwCfytUNmrEQ4We5i6B2ywM8hAcHvRDD293QGrqSS.Ez6LSm3LPosAtT2qUtFNU9Y2y9P9wQUfJjGgs98uchVJtZjfS.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vZGV2LW9wZW4tbWVzc2FnZXMtYXBpLWx0aDRnb3dkeXEtZXcuYS5ydW4uYXBwL21lc3NhZ2VzIiwiYSI6WyJkaWRjb21tL3YyIl19"
    ],
    "created_time": 1516269022,
    "expires_time": 1516385931
}

Success Criteria

encrypt and pack a message, and un pack and decrypt the same message with the same library

Support for target aarch-ios-simulator to existing .a library

Hi, would it be possible to add support for ios simulator target running on m1 mb ?

Tag 0.4.1 uniffy build is broken

I am trying to build uniffy project from tag 0.4.1, but running the build command gives the following error output.

➜  uniffi cargo build --release
    Updating crates.io index
    Updating git repository `https://github.com/hyperledger/aries-askar`
   Compiling proc-macro2 v1.0.69
   Compiling unicode-ident v1.0.12
   Compiling version_check v0.9.4
   Compiling typenum v1.17.0
   Compiling memchr v2.3.4
   Compiling serde v1.0.189
   Compiling subtle v2.4.1
   Compiling cfg-if v1.0.0
   Compiling libc v0.2.149
   Compiling syn v1.0.109
   Compiling thiserror v1.0.50
   Compiling radium v0.5.3
   Compiling lexical-core v0.7.6
   Compiling generic-array v0.14.7
   Compiling nom v6.2.2
   Compiling ryu v1.0.15
   Compiling bitflags v1.3.2
   Compiling serde_json v1.0.107
   Compiling quote v1.0.33
   Compiling getrandom v0.2.10
   Compiling syn v2.0.38
   Compiling nom v5.1.3
   Compiling tap v1.0.1
   Compiling wyz v0.2.0
   Compiling rand_core v0.6.4
   Compiling arrayvec v0.5.2
   Compiling funty v1.1.0
   Compiling camino v1.1.6
   Compiling static_assertions v1.1.0
   Compiling anyhow v1.0.75
   Compiling opaque-debug v0.3.0
   Compiling askama_escape v0.10.3
   Compiling bitvec v0.19.6
   Compiling paste v1.0.14
   Compiling ucd-trie v0.1.6
   Compiling byteorder v1.5.0
   Compiling digest v0.9.0
   Compiling cipher v0.2.5
   Compiling universal-hash v0.4.1
   Compiling signature v1.3.2
   Compiling crypto-mac v0.11.1
   Compiling ff v0.10.1
   Compiling itoa v1.0.9
   Compiling rand_core v0.5.1
   Compiling unicode-width v0.1.11
   Compiling textwrap v0.11.0
   Compiling group v0.10.0
   Compiling hmac v0.11.0
   Compiling aead v0.3.2
   Compiling block-buffer v0.9.0
   Compiling cpufeatures v0.2.10
   Compiling futures-core v0.3.28
   Compiling unicode-segmentation v1.10.1
   Compiling autocfg v1.1.0
   Compiling slab v0.4.9
   Compiling heck v0.3.3
   Compiling weedle v0.12.0
   Compiling sha2 v0.9.9
   Compiling clap v2.34.0
   Compiling poly1305 v0.6.2
   Compiling futures-task v0.3.28
   Compiling fnv v1.0.7
   Compiling der v0.4.5
   Compiling ident_case v1.0.1
   Compiling serde_derive v1.0.189
   Compiling thiserror-impl v1.0.50
   Compiling zeroize_derive v1.4.2
   Compiling futures-channel v0.3.28
   Compiling darling_core v0.12.4
   Compiling zeroize v1.4.3
   Compiling aes-soft v0.6.4
   Compiling crypto-bigint v0.2.11
   Compiling pest v2.7.4
   Compiling curve25519-dalek v3.2.0
   Compiling chacha20 v0.6.0
   Compiling elliptic-curve v0.10.6
   Compiling salsa20 v0.7.2
error[E0433]: failed to resolve: could not find `memmem` in `memchr`
   --> /Users/i******/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pest-2.7.4/src/position.rs:311:33
    |
311 |                         memchr::memmem::find(&self.input.as_bytes()[self.pos..], s1.as_bytes())
    |                                 ^^^^^^ could not find `memmem` in `memchr`

   Compiling ecdsa v0.12.4
   Compiling polyval v0.4.5
For more information about this error, try `rustc --explain E0433`.
error: could not compile `pest` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `pest` (lib) due to previous error
```

Always return a messaging service in the PackEncryptedMetadata

As implemented, calling pack_encrypted with the to DID not requiring forwarding will cause the returned PackEncryptedMetadata to omit the messaging_service parameter.

I suggest always returning the messaging_service parameter, even when forwarding is not required because not returning it requires me to rewrite routines already implemented by this library to determine the service endpoint to deliver my message to. It's not terribly complicated but it creates an opportunity for subtle discrepancies in implementation resulting in potentially inconsistent behavior.

Potential DIDComm did:peer:2 Spec Compliance Issue

I'm not too familiar with how the DIDPeer DIDs are supposed to work, but according to this comment, it appears that there may be some issues with Peer DID Numalgo 2 generation across libraries between https://github.com/sicpa-dlab/didcomm-python/ and here. The output is different enough that it has caused a conversion layer to be built to convert the DID between libraries in order to maintain inter-operability. Daniel has submitted a PR to the Spec to make clarifications decentralized-identity/peer-did-method-spec#62 but as of this moment it has not been merged.

Irregardless of the merge status, did:peer:2 DIDs generated by didcomm-rust and didcomm-python are incompatible with each-other when a service endpoint is defined. didcomm-python is expecting a flat servicesEndpoint structure, where-as didcomm-rust is expecting an object.

cc: @dbluhm

Types for TS is not following standards, specifically DIDDoc

What

Give a brief description of the objective of this issue. What needs to be discussed?
The current produced types for TS is not following standards of the spec.
I just touched upon the DIDDoc type and that has false things such as:

    /**
     * DID for the given DID Doc
     */
    did: string,

This should be id - https://www.w3.org/TR/did-core/#did-document-properties

    /**
     * DID URLs of verification methods used for key agreement.
     * See https://www.w3.org/TR/did-core/#verification-methods.
     */
    key_agreements: Array<string>,

this should be keyAgreements - https://www.w3.org/TR/did-core/#did-document-properties

So I dont know how literal to the spec one should be, but the resolved documents will not be of proper attributes if these types are correct.

Why

Explain why you think this issue needs to be addressed and why it should be addressed in this repo.

Because the produced type is not correct to what a did doc should be if you want to work with other libraries.

Success Criteria

Explain what actions or decisions need to be completed to close this issue.

Using a task list here can be helpful to track progress.
Update the production of types to produce proper TS types

Anything else

Include links to any examples, research or code that support this issue.
I dont know how this works with a wasmbinding and the rust magic, but I assume it transpiles the attribute values in the rust code directly to these names. And then I can understand things become a bit wonky.
Maybe one can define in some config somewhere to transpile to the right attributes?

Before submitting:

Add appropriate labels for 'type:' and 'related to:'

Add an assignee if you want to direct this issue at a particular individual

.NET Wrapper?

What

What are the chances that a .NET binding/wrapper can/will be created for these rust libraries?

Michael Herman
Web 7.0

User stories are good: As a [user] I want [to be able to do X] so that [I can achieve Y]

Team actions are also good: As a team we [should explore X] so that [we can do Y]

Why

Explain why you think this issue needs to be addressed and why it should be addressed in this repo.

What evidence do you have that it will be a requirement for this project?

What evidence do you have that it meets the needs of the users of this project?

Have you checked that a similar issue or resolution doesn't already exist?
If so link to it and explain any shortcomings

Success Criteria

Explain what actions or decisions need to be completed to close this issue.

Using a task list here can be helpful to track progress.

Anything else

Include links to any examples, research or code that support this issue.

Before submitting:

Add appropriate labels for 'type:' and 'related to:'

Add an assignee if you want to direct this issue at a particular individual

Faild to generate Swift bindings

Hi Guys,

I'm trying to run uniffi wrapper for swift as by this guide (https://github.com/sicpa-dlab/didcomm-rust/blob/main/uniffi/README.md).

But I catched an error in "3. Generate Swift binding:" point when I run command: uniffi-bindgen generate src/didcomm.udl --language swift -o ../wrappers/swift/didcomm

Error body:

Error: Failed to parse UDL

Caused by:
    ExtendedAttributeNoArgs not supported: "Wrapped"

Could you please advice on what could be the problem?

P.S.: I'm trying to use swift code from wrappers but unfortunately README.md file is empty. Could you share some more details on how I can work with the given module?

Thank you in advance,
Yurii

In DID Comm V2 - body MUST be a JSON object

What

Give a brief description of the objective of this issue. What needs to be discussed?

User stories are good: As a [user] I want [to be able to do X] so that [I can achieve Y]

Team actions are also good: As a team we [should explore X] so that [we can do Y]

According to DID Comm V2 specs the body on the Plaintext Message MUST be a JSON object.

In most examples on this list, the JSON string is used instead ("example-body")

Why

Explain why you think this issue needs to be addressed and why it should be addressed in this repo.

What evidence do you have that it will be a requirement for this project?

What evidence do you have that it meets the needs of the users of this project?

Have you checked that a similar issue or resolution doesn't already exist?
If so link to it and explain any shortcomings

Just to follow the specs

Success Criteria

Explain what actions or decisions need to be completed to close this issue.

Using a task list here can be helpful to track progress.

The Plaintext Message MUST have a JSON object in the body in DID Comm v2.0.
In DID Comm v2.1 this body is optional but also needs to be a JSON object if present.

Anything else

Include links to any examples, research or code that support this issue.

DID Comm V2 specs

Before submitting:

Add appropriate labels for 'type:' and 'related to:'

Add an assignee if you want to direct this issue at a particular individual

Swift wrapper, DidResolver not able to accept error callback with error kind, rust panic

As a user I would like to be able to know why resolution of did document failed, e.g. network error or simply not found. The API is available such as

public protocol DidResolver: AnyObject {
    func resolve(did: String, cb: OnDidResolverResult) -> ErrorCode
}

but when trying to invoke

try cb.error(err: .InvalidState(message: did), msg: "NetworkError")

then nor ErrorKind or msg is propagated to pack or unpack methods on error closure.

public func unpack(msg: String, options: UnpackOptions, cb: OnUnpackResult) -> ErrorCode
public protocol OnUnpackResult: AnyObject {
    func success(result: Message, metadata: UnpackMetadata)
    func error(err: ErrorKind, msg: String)
}

In the above err is always

(lldb) po error
▿ ErrorKind
  ▿ InvalidState : 1 element
    - message : "Invalid state"

and msg is always

(lldb) po msg
"Invalid state: Unable resolve signer did: can not resolve DID Doc: Invalid state: unable receive callback result: oneshot canceled: unable receive callback result: oneshot canceled"

What I would expect is ErrorKind is correctly propagated.

didcomm-rust/wasm demo is failing in step https://github.com/sicpa-dlab/didcomm-rust/tree/main/wasm#run-demo

didcomm-rust/wasm demo is failing in step https://github.com/sicpa-dlab/didcomm-rust/tree/main/wasm#run-demo - more specifically, during the npm run start command...

C:\web7sandbox\repos\didcomm-rust\wasm\demo>npm ll
[email protected]
| C:\web7sandbox\repos\didcomm-rust\wasm\demo
| JS demo for didcomm
+-- @types/[email protected]
|   TypeScript definitions for Node.js
+-- [email protected]
|   WASM based javascript wrapper for DIDComm
+-- [email protected]
|   TypeScript execution environment and REPL for node.js, with source map support
+-- [email protected]
|   An extensible static analysis linter for the TypeScript language
`-- [email protected]
    TypeScript is a language for application scale JavaScript development

TS - Message.unpack fails with silent SIGBUS error

What

Have friendly errors when a method can receive all types, DO NOT crash with a SIGBUS error.
Sending inn a JSON obj into unpack, which is allowed by the types, crashes silently with a SIGBUS error. Trying to debug this was not that easy: nodejs/help#3168

But the library should throw a friendly error if JSON objects are not possible to send in for unpack.
Only string works at the moment

Why

This needs to be fixed for a better DX, as SIGBUS is not caught by try catch, and it can fail silently depending on how one run its code. This is a very bad DX.

Success Criteria

Fail if one send in something the unpack method dont expect. Fail with a proper error so the developer can understand.
Or if JSON objects are OK, which they should be, dont crash unexpectadly.

sicpa-dlab / didcomm-rust Goto Github PK

didcomm-rust's People

Contributors

Stargazers

Watchers

Forkers

didcomm-rust's Issues

What

Why

Success Criteria

Anything else

What

Why

Success Criteria

Anything else

My Environment

What

Why

Success Criteria

What

Why

Success Criteria

What

Why

Success Criteria

What

Why

Success Criteria

Anything else

What

Why

Success Criteria

Anything else

What

Why

Success Criteria

Anything else

What

Why

Success Criteria

Recommend Projects

Recommend Topics

Recommend Org