Score Credential Issuance on Ceramic VC for Enhanced Interoperability

[erichfi]

User Story:

As a Gitcoin Passport holder, I want my score to automatically issue a Score Credential on Ceramic using a similar data schema as on EAS, So that integrators can leverage the score interpreters to understand and utilize my credentials across different ecosystems.

Acceptance Criteria

GIVEN a user has a Gitcoin Passport, WHEN the score is written to Ceramic, THEN a Score Credential should be issued on Ceramic using a data schema similar to that on EAS.

Product & Design Links:

Tech Details:

• The implementation must ensure schema alignment between EAS and Ceramic VC for Score Credentials only.
• The issuance process must be automated within the Gitcoin Passport's current workflow when writing scores to Ceramic.
• Issue the Score credentials directly from the Scorer onto Ceramic.

Open Questions:

• Are there specific technical constraints on Ceramic that might affect the schema compatibility for Score Credentials?
• How will the issuance of these Score Credentials on Ceramic be communicated to the users?

Notes/Assumptions:

• It is assumed that users will benefit from having a consistent schema for Score Credentials across platforms, enhancing interoperability and usability.
• The existing infrastructure on EAS and compatibility with Ceramic for Score Credentials need to be thoroughly evaluated to ensure seamless integration.

[nutrina]

I don't think that writing the Passport in he same format as we write to EAS is a good idea (writing the score to compose, I think is ok). The problem with the Passport however is that that format is not developer friendly. Whoever wants to use that will have a very hard time implementing that and even a harder time maintaining that (compared to just using our regular stamps that we have on ceramic).

It will add more confusion to developer: why do we have 2 Passport formats on ceramic. Which one should they use?

And also it is not that trivial to maintain on our end, if we can avoid it we should (we should avoid having to manage the bitmap on ceramic as well).

Unless we have a good reason and there is demand for this, we should really stick to writing the score as a VC to ceramic, using a similar structure as on EAS.

[erichfi]

Acknowledging the concerns raised by @nutrina about the complexity and potential confusion of maintaining two Passport formats on Ceramic, I agree with pivoting towards simplifying our approach. Let's prioritize issuing only the score as a Verifiable Credential on Ceramic, aligning it closely with the structure used on EAS for consistency and ease of use. This move will reduce the maintenance burden and avoid confusion among developers, focusing on enhancing user interoperability without complicating the developer experience. We can revisit the need for a direct Passport schema replication on Ceramic if a strong demand arises in the future.