Brian Richter
Brian Richter
So I have been debugging why I can't get this document to derive a credential that verifies. ``` { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/security/suites/bls12381-2020/v1", "https://w3id.org/vaccination/v1" ], "type": [ "VerifiableCredential", "VaccinationCertificate" ],...
This PR shows a failing test when verifying a complex derived VC to demonstrate the problem discussed in #158
It seems like the fact that we still won't admit whether it is internal or external or a combination of both is causing problems. I believe we should be building...
This string is only found in the readme. The credentials from the vc-http-api test suite all use this did:key type which is the one found in the spec https://w3c-ccg.github.io/did-method-key/#bls-12381. These...
This PR will be ready once the explorer at https://signet.ordinals.com has been updated to the latest release and I have tested the resolver against infrastructure I don't control.
Looks like the latest [commit](https://github.com/capacitor-community/barcode-scanner/commit/5a1e8d6c799ec72bc23ff15df857fa6ec5b5a6fe) fixes a bug I'm encountering. Could you please package up a new release? Using a patch for now but would like to remove that ASAP
To avoid polling architecture should we think about a way to include a `callbackUrl` for the workflow to hit when an exchange has been complete?
I might be missing this please let me know if it's in there.. Should the message be in the `data.json` or ~`data.jwe`~? Assuming json for now but this should be...
[This](https://www.w3.org/TR/did-spec-registries/#didcommmessaging) is out of alignment with changes that were made to how a service block looks in didcomm