Issues verifying VC. (JWT and JSON LD)

[Ajmasta]

Hello,

I am trying to verify some VCs but I ran into some issues. This is clearly user-error but I don't know what I'm doing wrong (at least for the JWT).

Creating and verifying a JWT VC:

  const jwtIssuer = await agent.didManagerCreate({
    provider:"did:ethr:rinkeby"
  })


const verifiableCredential = await  agent.createVerifiableCredential({
  credential: {
    issuer: { id: jwtIssuer.did },
    '@context': ['https://www.w3.org/2018/credentials/v1', 'https://example.com/1/2/3'],
    type: ['VerifiableCredential', 'Custom'],
    issuanceDate: new Date().toISOString(),
    credentialSubject: {
      id: 'did:web:example.com',
      Test:{
        test:"Test",
        name:"Test"
      }
    },
  },
  proofFormat: 'jwt',
})

console.log(verifiableCredential)

const decoded = decodeJWT(verifiableCredential.proof.jwt)


const handledMessage = await agent.handleMessage({
verifiableCredential
})
console.log(handledMessage)
}

getAndUpdate().catch(console.log) 

I'm guessing I am not calling the handleMessage function correctly. I tried other methods,
using raw, type etc. but couldn't make it work.

My agent is setup as such:

  export const agent = createAgent<IDIDManager & IKeyManager & IDataStore & IDataStoreORM & IResolver>({
    plugins: [
      new KeyManager({
        store: new KeyStore(dbConnection),
        kms: {
          local: new KeyManagementSystem(new PrivateKeyStore(dbConnection, new SecretBox(KMS_SECRET_KEY))),
        },
      }),
      new DIDManager({
        store: new DIDStore(dbConnection),
        defaultProvider: 'did:ethr',
        providers: {
          'did:ethr': new EthrDIDProvider({
            defaultKms: 'local',
            network: 'mainnet',
            rpcUrl: 'https://mainnet.infura.io/v3/' + INFURA_PROJECT_ID,
            gas: 1000001,
            ttl: 60 * 60 * 24 * 30 * 12 + 1,
          }),
          'did:ethr:rinkeby': new EthrDIDProvider({
            defaultKms: 'local',
            network: 'rinkeby',
            rpcUrl: 'https://rinkeby.infura.io/v3/' + INFURA_PROJECT_ID,
            gas: 1000001,
            ttl: 60 * 60 * 24 * 30 * 12 + 1,
          }),
          'did:web': new WebDIDProvider({
            defaultKms: 'local',
          }),
        },
      }),
      new DIDResolverPlugin({
        resolver: new Resolver({
          ...ethrDidResolver({ infuraProjectId: INFURA_PROJECT_ID }),
          ...webDidResolver(),
        }),
      }),
      new CredentialIssuer(),
      new MessageHandler({
        messageHandlers: [
          new JwtMessageHandler(),
          new W3cMessageHandler(),
        ],
      }),
    ],
  })

This returns : Unsupported message type in the console.

As for the JSON-LD, I ran into another issue. I get the following message: Error: key_not_found: No suitable signing key found for did:ethr....

I read up on signing keys on the did:ethr registry but I thought that a generated key pair would have signed keys. Do I need to add an option when creating the did?

here is the agent setup:

export const agent = createAgent<IResolver & IKeyManager & IDIDManager & ICredentialIssuer>({
    plugins: [
      new KeyManager({
        store: new MemoryKeyStore(),
        kms: {
          local: new KeyManagementSystem(new MemoryPrivateKeyStore())
        }
      }),
      new DIDManager({
        providers: {
          'did:key': new KeyDIDProvider({ defaultKms: 'local' }),
          'did:ethr:rinkeby': new EthrDIDProvider({
            defaultKms: 'local',
            network: 'rinkeby',
            rpcUrl: 'https://rinkeby.infura.io/v3/' + INFURA_PROJECT_ID,
            gas: 1000001,
            ttl: 60 * 60 * 24 * 30 * 12 + 1,
          }),
        },
        store: new MemoryDIDStore(),
        defaultProvider: 'did:key'
      }),
      new DIDResolverPlugin({
        resolver: new Resolver({...ethrDidResolver({ infuraProjectId: INFURA_PROJECT_ID }), ...getDidKeyResolver() })
      }),
      new CredentialIssuer(),
      new CredentialIssuerLD({
        contextMaps: [LdDefaultContexts, extraContexts],
        suites: [
          new VeramoEd25519Signature2018()
        ]
      })
    ],
  });

the function:

async function getAndUpdate() {

  const ldIssuer = await agent.didManagerCreate({
    provider:"did:ethr:rinkeby"
  })


const verifiableCredential = await  agent.createVerifiableCredential({
  credential: {
    issuer: { id: ldIssuer.did },
    '@context': ['https://www.w3.org/2018/credentials/v1', 'https://example.com/1/2/3'],
    type: ['VerifiableCredential', 'Custom'],
    issuanceDate: new Date().toISOString(),
    credentialSubject: {
      id: 'did:web:example.com',
      test:{
        test:"test",
        name:"test"
      }
    },
  },
  proofFormat: 'lds',
})




const verifiedCred = await agent.verifyCredential({
credential:verifiableCredential
})
console.log(verifiedCred)
}
getAndUpdate().catch(console.log) 

[mirceanis]

Excellent questions, kudos for sharing the details upfront!

In your first setup, you need to pass the JWT as the raw message to ``handleMessage, like so:

const handledMessage = await agent.handleMessage({
  raw: verifiableCredential.proof.jwt
})

In your second setup, you need an extra crypto suite that can work with did:ethr keys out of the box (VeramoEcdsaSecp256k1RecoverySignature2020.. naming is hard :))

You can add it to your setup like so:

      new CredentialIssuerLD({
        contextMaps: [LdDefaultContexts, extraContexts],
        suites: [
          new VeramoEd25519Signature2018(),
          new VeramoEcdsaSecp256k1RecoverySignature2020()
        ]
      })

Alternatively, you could call didManagerAddKey to add a Ed25519 key to your did:ethr DID document, but that's probably more complicated, OR you could use a did:key identifier to start with. In the current Veramo version did:key identifiers are built around Ed25519 keys.

Also, you can use the same verification API to verify JWT credentials as well as JSON-LD. We know that calling handleMessage to verify a VC makes very little sense.
And, you don't need to take care to supply the JWT part of the proof or the parsed credential when verifying JWT credentials with it. The framework knows to interpret both types.

That being said, the new verification API that you are using is now being developed, and feedback is very welcome.

[Ajmasta]

Thank you so much! I followed the step you gave and everything works :) Would you like me to do a pull request on the credentials-LD-example repo to add a did:ethr method?

if you don't mind, I just want to confirm I understand what is happening. When I create a VC, Veramo finds the issuer in the keystore and uses the private key to sign a proof and adds it at the bottom of the VC. When I verify the VC, Veramo uses the public key of the issuer to decrypt the message and ensures that the issuer did indeed sign that VC. Is that right? Both handleMessage and verifyCredentials do that ?

For JSON-LD, if I want my custom context, I would be able to do so by uploading a json with the context on a server and provide that in the "context" field right?

And finally, sorry for all the questions, if I were to create an API that verifies something, would it be adequate to send the VC to a user through normal http means? Or is there a prefered way to do that?

Thanks again for all the help :)!

[mirceanis]

Wonderful!

Yes, please make a PR. We are a very small team, so external contributions are extremely important to push this project further.

You seem to have already grasped what happens for signing and verifying a VC. There is a small misunderstanding there; the VC is not decrypted during verification, only the signature is compared against one or more public keys listed in the issuer DID document.
This is done automatically in verifyCredential and handleMessage if you use the default setups.

For JSON-LD, I think that would work.
The verifier has to have the same context definitions when verifying a VC as the issuer had when they issued the VC.
The approach recommended by the JSON-LD folks is to exchange these definitions in advance, so that they are NOT downloaded during verification.

And finally, you are free to exchange VCs with your users however it makes sense for your application. JSON over http works, and is already supported by veramo.

I hope this helps

[Ajmasta]

Thank you very much for the clarifications!

So, I'm a noob at this so I'm most likelymissing something but it looks like I don't have the permission to push a new branch at credential-ld-example.git.
I have uploaded a templated repo here. Happy to just do a pull request (if I can get authorized)/make changes if needed. I just added the flow for did:ethr alongside the did:key flow, and added some tests.

[mirceanis]

I'm not sure if a PR can be made directly from a templated repo on github, but the normal flow is to fork the repo, push the changes to your fork and then make a PR from your fork to the original repository.