Proposal to Recommend Coordinators to Expose the Same Endpoints as Services

[laysakura]

Based on the description in Section 3.6, I created the following diagram: (Quoted from https://laysakura.github.io/2024/07/19/vc-api-v0.3/)

This diagram clearly illustrates the issue I'm pointing out.

---

vc-api/index.html

Lines 401 to 403 in 066f030

	a wallet. In the VC API, the Holder Coordinator initiates all flows. They request
	VCs from Issuers. They decide if, and when, to share those VCs with
	Verifiers. Within the VC API, there is no way for either the Issuer or the

In the VC API, the Holder Coordinator initiates all flows. They request VCs from Issuers. They decide if, and when, to share those VCs with Verifiers.

However, there is almost no mention in this specification about the interfaces through which the Holder Coordinator communicates with Issuers and Verifiers.

While {Issuer, Verifier} Coordinators should certainly be allowed to have their own functions and interfaces, I propose that it should be recommended that {Issuer, Verifier} Coordinators expose all endpoints of the {Issuer, Verifier} Services.

This would allow implementers of Holder Coordinators to ensure interoperability across many {Issuer, Verifier} Coordinators.

[dlongley]

The Workflows and Exchanges section of the spec is for crossing trust boundaries (e.g., Holders communicating with Issuers or Verifiers):

https://w3c-ccg.github.io/vc-api/#workflows-and-exchanges

It needs to be fleshed out more from the content we have developed in various issues but haven't created PRs for yet to the spec.

[msporny]

The group discussed this on the 2024-07-23 telecon:

The discussion revolved around clarifying that workflows enable a caller to exchange credentials with a coordinator.

A PR should be raised to highlight the notion that workflows are used to exchange credentials across trust boundaries with issuer coordinators or verifier coordinators.