Tomislav Markovski

If the intent is to produce JWS in compact form for a payload of Indy transaction, which is string/json, I believe we are aligned as the method output is dictated...

`aries-framework-dotnet` doesn't support attachment signing via the `jws` field, future implementation would conform to the JWS spec represented in JSON form (as opposed to compact).

@swcurran Would adding a field `text` in the attachment spec, that would contain a plain text string help? We can then easily produce JWS payload using `base64(ascii(text))`. If that would...

This could also be a good candidate for custom message family. It'll allow the implementation to use the existing message handler pipeline and fulfill the request. Optionally, threading can be...

Sure. This would be a fairly straightforward change with low impact.

Currently, we are using the "to" field to populate it with key, between aca-py and aries .net. > Should we change RFC 94 to allow a key as well in...

+1 for this feature, would be great to have it!

I'll take a look at this. Can you please confirm again the Libindy version? Is is `1.9.0`? Can you try updating to anything `1.15`? https://repo.sovrin.org/windows/libindy/master/

I'm having trouble reproducing this. Is your Windows 10 a 32 or 64 bit? I'm assuming your locale is not en-US. This is not a problem with Aries, but an...

As I suspected. It may be related to Indy SDK wrapper using `Ansi` as opposed to `Unicode` in the `[DllImport(Charset = Ansi)]` https://github.com/hyperledger/indy-sdk/blob/f9eb2cf17b51584f875c4707094256a96656e7b8/wrappers/dotnet/indy-sdk-dotnet/NonSecretsApi/NativeMethods.cs#L12 I'll see if I can reproduce this...