feat(pollux): update storage for static resources to be wrapped in an envelope

[shotexa]

Description:

Summarize the changes you're submitting in a few sentences, including Jira ticket ATL-xxxx if applicable.
Link to any discussion, related issues and bug reports to give the context to help the reviewer understand the PR.

Alternatives Considered (optional):

Link to existing ADR (Architecture Decision Record), if any. If relevant, describe other approaches explored and the selected approach. Documenting why the methods were not selected will create a knowledge base for future reference, helping prevent others from revisiting less optimal ideas.

Checklist:

• My PR follows the contribution guidelines of this project
• My PR is free of third-party dependencies that don't comply with the Allowlist
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked the PR title to follow the conventional commit specification

[github-actions]

Unit Test Results

0 files   -  97  0 suites   - 97   0s ⏱️ - 22m 5s
0 tests  - 827  0 ✅  - 819  0 💤  - 8  0 ❌ ±0 
0 runs   - 834  0 ✅  - 826  0 💤  - 8  0 ❌ ±0 

Results for commit 1e3f2f2. ± Comparison against base commit 0a7579e.

♻️ This comment has been updated with latest results.

[yshyn-iohk]

Does it make sense to unpack the DIDURLResponse and use CredentialSchemaResponse everywhere?

[shotexa]

Why do you mean by unpack? I did not get it

[yshyn-iohk]

Passing an entire AppConfig object is a code smell.
From a long-term perspective, it creates a coupling between the application conf and the schema API.
Passing the required parameters (or the object with these parameters) to the function would be better.

[shotexa]

Makes sense

[yshyn-iohk]

@shotexa, good progress with schemas.
From the architectural point of view, the open-close principle would be better if all specifications for the schema CRUD operation were split into different endpoints, allowing for better modularization.

What do I propose:

1. For a W3C specification, we use the W3C VerifiableCredentialSchema spec. I would use the path /cloud-agent/vc-json-schema/.....

• for our VDR variation, I would use /cloud-agent/prism-vc-json-schema/... - pointing out that request/response is specific to our DID Linked resources specification

2. for AnonCreds we support two methods

• HTTP AnonCreds Method could be /cloud-agent/anoncreds/schema/http/...
• DID: Prism AnonCreds Method could be /cloud-agent/anoncreds/schema/prism/...

Having this segregation will make everything simple for usage and adoption. Business logic will be straightforward, and unit/e2e tests will be much simpler to write. The maintainability of this code will also be much better.

NOTE: The naming convention for the paths can be changed; the main idea is to segregate different specs for the different routes.

CC: @bvoiturier, @mineme0110

[bvoiturier]

@yshyn-iohk Regarding the above comment, I think we are mixing different concepts here. From my point of view, the schema formats we support (JSON and AnonCreds) and their CRUD endpoints are orthogonal to the retrieval methods we want to support (direct http request to the schema or resolution through DID URL that contains a 'service' entry indicating the schema URL to fetch).

So, if deemed necessary, we could split schema CRUD operations into two sets of endpoints - one for JSON and one for AnonCreds - but I don't understand the reasoning behind having additional endpoints for a "VDR variation" or for "HTTP/PrismDID AnonCreds methods" 🤔

[shotexa]

• HTTP AnonCreds Method

Yeah, so from what I understood, @yshyn-iohk is suggesting having 2 sets of endpoints for every schema operation, just like now I have 2 endpoints for creation, one for creating schema that is resolvable via HTTP, and one that is resolvable via DID URL, @yshyn-iohk you are suggesting to have all endpoints (get, update, get many) to have separate for HTTP URLs and DID URLs. do I understand this correctly?

Right now I only have the creation endpoint split into two, get endpoint for example, it might return schema as normal (like now), or wrapped in an envelope (as it was created to be resolvable via DID URL)

@bvoiturier

[yshyn-iohk]

I'm suggesting to isolate the schema's APIs by type and by spec
w3c vc schema or the full name Verifiable Credentials JSON Schema - is a type
anoncreds schema is another type.
At the same time, there are a lot of specs for the CRUD operation: plain HTTP, did:prism, did:indy , etc
Having ALL type and all METHODS in under the same path will blow up sooner or later.

[yshyn-iohk]

@bvoiturier, regarding but I don't understand the reasoning behind having additional endpoints for a "VDR variation" or for "HTTP/PrismDID AnonCreds methods
The current state of the ecosystem is highly deviated from a single standard.
Imagine that we need to support other VDR (Methods), for instance, cheqd or did:web.
We will get this requirement as soon as we start supporting the different DIDs, as it's a little bit odd to use DID did:web and not use did:web anon creds method.

[shotexa]

I'm suggesting to isolate the schema's APIs by type and by spec w3c vc schema or the full name Verifiable Credentials JSON Schema - is a type anoncreds schema is another type. At the same time, there are a lot of specs for the CRUD operation: plain HTTP, did:prism, did:indy , etc Having ALL type and all METHODS in under the same path will blow up sooner or later.

I find it a bit hard to follow, specifically with differences between types of schemas and specs. I think it would be better if we could have a short call and you can explain to me what you mean exactly.

[yshyn-iohk]

Should the prefix cloud-agent be added to the path?
It should be a matter of configuration, so the agent should know the full external path

[shotexa]

We don't need to add "cloud-agent" in the path. when we later construct an HTTP URL to resolve an actual resource from the DID URL, we will use resource service, which is going to be located inside the DID, we will resolve the did and this service will include the server base URL path, in the next ticket PR, when I add this service by default to every DID that issuer creates, the value of this service will be from the config, the value of public endpoint, and it does already include "cloud-agent" as you can see here

identus-cloud-agent/cloud-agent/service/server/src/main/resources/application.conf

Line 96 in 11ee9df

publicEndpointUrl = "https://host.docker.internal:8080/cloud-agent"

[yshyn-iohk]

We need to rename did to did:prism as this resolution method is our domestic specification. What do you think, @shotexa ?

[shotexa]

I'm not sure, when I created this enum I meant which type of URL to use, and the schema for either one is did or http, If I rename did to did:prism, this maybe assumes there might be did:somethingelse in the future that is why I'm making this more specific in my database.

[yshyn-iohk]

Excellent work, @shotexa!

[mattklepp]

should we add validation to the PrismEnvelopeResponse code to incorporate validation logic for the resource and url fields in case the url doesn't conform to the DID url format or string not in the correct format. Error handling.

[shotexa]

should we add validation to the PrismEnvelopeResponse code to incorporate validation logic for the resource and url fields in case the url doesn't conform to the DID url format or string not in the correct format. Error handling.

Validate at which point? it is a response type, so we are returning it, if it were a type we received in a request we would validate it ofc, but since we are returning it, it is assumed to be valid as long as we are creating it correctly. If we are not creating it correctly, this case is covered by tests.