Consider to introduce a manifest describing entry points ('static' endpoints)

[filip26]

Hi,
please consider that name of an endpoint is a variable today, it would be beneficial to have a manifest allowing to a particular API consumer to know which URL maps to what endpoint, if that URL cannot be passed dynamically.

I hope it reflects more the original intention of how WWW should work than hardwired /..../..../something and even it adds a little complexity, it would be a great "novel" addition and a differentiator.

[msporny]

The group discussed this on 2025-01-07:

@msporny noted that we had considered this long ago with a manifest.json file. @dlongley noted that we found that we didn't have use cases for dynamically retrieving metadata and doing something with it. VC API systems are not just functions that have an HTTP interface, they're stateful, they have important configuration information that do specific things. Given that we have a more stateful design, we didn't really have use cases for this. Same is true for VC API Exchanges, exchange URLs are given to client, client doesn't have to "discover" endpoints... endpoints are provided over exchange channel through endpoint that they already have. Design that we have today has eliminated need for those sorts of metadata endpoints; no need for dynamic configuration today. Doesn't mean that another use case might not come up, but currently design is simple enough to not need this feature. The feature could be added in the future if such a use case were to be discovered.

The group decided that we don't have any use cases that require this feature today and if such a feature were to appear in the future, we could add the feature then. This issue is marked as pending close to see if @filip26 has any concerns if we close the issue.

[filip26]

I could list numerous use cases that benefit all stakeholders, including those conducting official W3C testing and already using what can clearly be described as a manifest.

https://github.com/w3c/vc-test-suite-implementations/blob/main/implementations/ApiCatalog.json

This issue was raised in good faith to enhance the specification and make it more appealing, but I can clearly see the intensity of the pushback.

[msporny]

The group discussed this on the 2025-01-14 telecon:

The group wanted @filip26 to write down the use cases he's most interested in so they could analyze the use cases. The group also felt that inviting @filip26 to one of the VC API calls would be a good idea.

@filip26 could you please:

1. Document your use cases in this thread so we can analyze them.
2. Let us know if you would be available to join us on a VC API call (We know you're on CET so we could hold a special call at a time that works for you).