Assess adequacy of current badge's recipient

[orviz]

When verifying the badge with https://badgecheck.io/ there is an optional verify recipient (see image below) option that we may want to enforce for the badges we issue.

This issue is to try to verify the current recipient we are using: the commit SHA from the code repo; and if this is not possible check whether there is a better approach (alternative recipient) that allows us both to:

• verify the recipient
• filter badges based on this recipient (i.e. listing all the badges that belong to a given piece of software)

[gmolto]

TL;DR; Using software release URLs (e.g. https://github.com/grycap/im/releases/tag/v1.10.7) instead of commit identifiers addresses this issue. Also, conceptually it makes more sense to award a badge to a specific release rather than a specific commit.

See full assessment down below:

https://gmolto.notion.site/Badgr-Validation-41a683a9f21545a59c61c56b1b80eddb

[orviz]

The recipient will be sth not unique, so for SW (URL of the repo), SRV (URL of repo containing the config files for the deployment), and FAIR (PID; if not the URL landing page)

Requirements for issuing badges:

• Software: using the URL pointing to the release tag
• Services: Same solution as the software i.e. release tag URL using the repo where the configuration files for the deployment are stored
• Recipient for FAIR: DOIs