VC issuer written in Typescript with Azle

Developers
1

Lately at Dacade we were writting a VC issuer with Azle; we would love to get some reviews from the community,
There are some validations in rust that we are missing on which we would love some guidance :slightly_smiling_face:

Here is the repo: GitHub - dacadeorg/dacade-vc-issuer

  • The issuer support 3 credentials for the different courses on dacade: ICP101Completion, ICP201Completion, ICPDeAiCompletion

cc: @lastmjs @lmuntaner

4 Likes
2

Hi @Jonath-z

I skimmed through the project. Congratulations on implementing the issuer! I wish you luck with the project!

I have some comments to improve it further:

  • The supported origins or derivation origin should better be set in the configuration of the canister. As a parameter when installing it. Example.
  • The ISSUER_URL can be considered more of an identifier. Therefore, I would use the production domain: https://dacade.org/
  • The language in the consent message is set to the request, but you always return english :wink:
  • There is a security issue because you never validate the id_alias credential. Nor in prepare_credential nor in get_credential. I guess that’s a limitation of Azle? Here and here are some examples in case that’s helpful.

Anyway, great job with the project.

Happy coding!!

3 Likes
3

Thanks for the feedback;

4

I was reading the id_alias validation but I could not fully understand it; is it possible to write down for me how should the id_alias validation be?

  • Why is everything treated as buffers ? is it how rust works or there is an other reason
5

The id_alias credential is a credential created by Internet Identity (which is also an issuer), proving the isuer that the user is related to the “id_alias” identifier. Which is then used as the subject of the credential the issuer creates.

There is a function in the Rust SDK that performs that check: get_verified_id_alias_from_jws

A part from verifying the signature, it also verifies:

  • The “iss” is Internet Identity’s URL.
  • The “credentialSubject” matches the principal of the user from the Issuer’s perspective.
  • Expiration (“exp”) is after now.

I don’t know why everything is treated as buffers. Maybe this is something related with Azle and JS and how they handle the data.

I hope this helps.

1 Like