Verifiable Credentials Issuing Testing

Developers Rust
1

Hi everyone,

I have implemented the verifiable credentials rust canister and using the function below to test the issuing

requestVerifiablePresentation({
onSuccess: async (verifiablePresentation) => {
console.log(verifiablePresentation);
},
onError() {
// Called when there is a technical error.
},
issuerData: {
origin: “{front-end url}”, //DERIVATION ORIGIN GIVEN BY THE ISSUE (also our front end url)
canisterId: Principal.fromText(“x74ag-daaaa-aaaal-qdisa-cai”), //ISSUER CANISTER
},
credentialData: {
credentialSpec: {
credentialType: ‘AttendenceRecord’,
arguments: {
“event_id”: “167HQ73B72FQZR96G9MSNAVYFE”
},
},
credentialSubject: p, //THE II PRINCIPAL WHEN USING THE RELAY PARTY
},
identityProvider: new URL(“https:// identity.ic0.app/”),
});

I am getting this error: 1. Failed To Present Credential The derivation origin given for the issuer is not valid.
I cannot post the script with the URLs but they are inputed correctly in my test function

The package used is @dfinity/verifiable-credentials

1 Like
2

Hi!

If you are building an issue, you can try the Dummy Relying Party to test with it. That might be easier than developing a whole relying party.

You can also download the wasm from the Verifiable Credentials SDK.

Apart from that, which Internet Identity release are you using to test that? And which ic-verifiable-credentials version in the issuer canister?

We’ll find the problem!

1 Like
4

I’m one of the developers on this project. I tried using the dummy RP, but I don’t think its filling in the credential_type as my canister is returning the error its supposed to when the credential_type is incorrect.

5

Yes, in the Dummy Relying party you have to write the credential type and arguments as the Issuer expects them.

Is the problem solved?

I can help, but as I said I also need to know which Internet Identity release are you using and which ic-verifiable-credentials version.

6

I understand, I am filling in the correct credential type and arguments, but I am getting this response. Is there some way I can verify that the dummy relay party is sending the correct request?

I am using release version: b74c746ea5361af3da207a2c957be4a951f7a72c

7

After some playing around, the dummy RP was not filling in the credential type correctly. It now is and I am working through some issues on our issuer. I will send another reply if needed. It may be worth noting for others that the dummy RP doesn’t always work, it wasn’t filling in the credential type until I refreshed a couple of times.

8

Noted, thanks for the feedback!

Please let me know if you encounter other problems.

9

I’m having another issue, potentially irrelevant to the thread but still trying to implement an issuer so I thought I would add as a reply. For some reason, when the dummy RP/II goes to call the get_credential method, my motoko canister suddenly can’t find my rust canister. Assuming II is calling the derivation_origin and prepare_credential functions (which also utilise an inter-canister call to my rust canister), this issue is isolated to my get_credential method. The exact error is:
“Code”: “CanisterReject”
“Message”: “Canister bwyhz-maaaa-aaaao-a3vcq-cai not found”

which is strange, because bwyhz-maaaa-aaaao-a3vcq-cai is a live canister on the IC, viewable on the dashboard, and utilised via intercanister calls by both the derivation_origin and the prepare_credentials function. Any advice on how to debug this or what the issue could be would be much appreciated.

10

Unfortunately inter-canister calls are not available in query calls. And get_credential needs to be a query call to get the canister signature.

You could make the Rust canister your issuer which makes inter-canister calls to the Motoko canister to get the data in prepare_credential and stores it in memory for the get_credential.

I’ll take a look whether Internet Identity can use Composite Queries with get_credential which would then allow inter-canister calls.

Even if that is possible, it won’t happen soon because I would need to change a few things and run quite a few tests.

I’ll keep you posted.

11

Thank you very much. I will refactor our solution to use the rust canister as the issuer.

1 Like