Open laysakura opened 4 months ago
The way the spec presents this particular endpoint is indeed confusing. I believe it is because the same endpoint can be provided by either a holder service (for use by a holder coordinator) or by an issuer service (for use by an issuer coordinator).
So, we need to clarify that the GET /credentials
endpoint can be implemented by either a holder service OR an issuer service -- and then, depending on which service has implemented it, that determines which coordinator can call it. The aim here is not to indicate that a holder coordinator would make a call to an issuer service's /credentials
, they would only make a call to a holder service's /credentials
endpoint. Similarly, an issuer coordinator would only call an issuer service's /credentials
endpoint, not one belonging to a holder service.
There may already be an outstanding PR (that may or may not have been pushed) that was designed to help address this, I recall perhaps @eric-schuh working on this. It could also just be that the current tooling that we have needs to be adjusted because it's conflating this information from tables or something when the spec is built, mixing it together in a way that results in a presentation in the spec that is confusing.
Thank you! I totally understood.
The group discussed this on the 2024-07-23 telecon:
It was agreed that the association with "Holder Coordinator" in this section is incorrect and the code that auto-generates this table needs to be fixed to be aware of which service it is generating the table for.
A PR needs to be raised to fix the code that auto-generates the table.
I assigned myself to take care of this, should have something in next week to fix.
https://github.com/w3c-ccg/vc-api/blob/066f0309d2c5e8b5a2bc972a0a60464c805e1705/index.html#L370-L374
The above paragraph states:
But the https://w3c-ccg.github.io/vc-api/#issuer-service section says the
GET /credentials
in the Issuer Service is expected to be called from Holder Coordinator.This inconsistency raises questions about the intended architecture and communication flow in the VC API specification.