Address concerns with VC-HTTP-API

[vsnt]

Address items as mentioned on this thread at 4/13 CCG call. https://github.com/w3c-ccg/vc-http-api/pull/168

[kimdhamilton]

We'll discuss this in the 4/20 meeting. Refer to w3c-ccg/vc-http-api#168 for context.

Some questions/comments I wanted to put to the group before the meeting (feel free to add):

Theme: Clarification of Intent of this Work Item on Creation

• The vc-http-api work item was created before the "new work item template" additions asking for additional use case clarification. Would those clarifications have helped?
• Are there additional questions or other "new work item" requirements we could have added to prevent the current state?

Theme: User-Facing Docs

• The primary entry point for this work item is an api doc, and the closest human-readable doc is the architecture doc, which is buried in the repo. Are there any quick wins for clarifying this repo?
• +1 for proposals from this thread (w3c-ccg/vc-http-api#168) to capture some basic use cases, diagrams, and docs from the SVIP cohort. Perhaps this could even be created by attendees at a vc-http-api 101 presentation, for review by the CODEOWNERS (for corrections).

Theme: Clarification of Pull Requests and Conflict Resolution

• Does the CCG need to provide recommendations in authoring PRs to clarify use cases?
  • We wouldn't want heavy-weight process to bog down progress, but perhaps there are good patterns we can establish to make it easier to reference context for changes.
• Are we missing an opportunity to provide guidance on conflict resolution in cases like w3c-ccg/vc-http-api#168?
• Some of the conflict seemed to result from different expectations of responsiveness from code owners. Do we want to establish guidance for this as well? Or recommendations that the repo (not the work item --see below) be forked until time permits

Additional Clarifications I have no objections to forks or new work items to the extent that it makes sense conceptually. However, in this case, the actions appear to stem from uncertainty and different expectations of responsiveness. @TallTed's comments in https://github.com/w3c-ccg/community/issues/191 resonate with how I think about CCG work item expectations.

I also want to call out that, as a chair, I would decide to reject any work item that said it wasn't looking for use case feedback, because that (IMO) seems like a misuse of CCG resources. At the same time, my chair duties are up soon, so maybe you can wait me out. :)

[OR13]

@kimdhamilton what about a work item that isn't asking for use case feedback because its dedicated to a single use case?

[kimdhamilton]

@OR13 a single use case that is so perfectly and crisply defined, whose consequences are so thoroughly thought through that it's impossible any other human's feedback would be acceptable? Sure. Do I expect anyone to meet that bar? No.

[OR13]

@kimdhamilton asking for a new use case is different than asking for feedback :)

Feedback is fine, asking for folks to consider not using DIDs, not using VCs or not use HTTP?

Thats what we are trying to avoid...

If you want good feedback, it's helpful to be upfront about where you see large opportunities for change, and where you don't.

For the traceability API, I think we are interested in the traceability use case, that includes, issue, verify, derive, revoke, present, store, and discoverability in a supply chain context.

For the VC HTTP API, I think there are many use cases, often with competing priorities, its not that the vc http api can't address the same functionality, its that not having a single focal use case, makes it very hard to understand...

I have been proposing that the VC HTTP API be focused on the VC Data Model over HTTP, and essentially focus on CRUD operations in that domain.

Some folks don't want APIs that make presentations or that exchange them.

Some don't want to support revocation, or ZKP derivation.

Others want to make cosmetic changes.

It's hard to work with feedback that is essentially "I don't want to support your use case, I think this API shouldn't do what you are proposing"... but I think it's also very valid to provide such feedback, once that feedback is provided, its also very reasonable that if folks need to work on that use case or feature set, they will find a more supportive venue.

so TL;DR; feedback welcome!

Undermining of features core to spec coverage and interoperability through consensus by exhaustion?

Not welcome :) at least for me.

Others may have a higher pain tolerance.

Should the vc http api require DIDs, VCs and HTTP? It does today...

[kimdhamilton]

Refer to that as scope instead of use case to avoid the ambiguity

[bumblefudge]

Heyo, I've been working (admittedly, "in the intransparent shadows" with SVIP companies on originally SVIP-only calls, which we are gradually trying to CCG-ify in parallel with this process) on gathering/backfilling the documentation gap. Not sure where/when to debut this collaborative straw man, but dropping it here for archival purposes.

https://docs.google.com/document/d/1-u0_Ub6feiX6DH3jXFJFjt6n3CwKGpkmC3VISqDkWL4/edit# (pdf in case google doc disappears) VC-HTTP-API UCR straw man.pdf

[TallTed]

@bumblefudge -- THANK YOU! I now have MUCH better idea of what's being done here... which of course opens more questions, but hopefully more usefully focused ones!

[vsnt]

All, I think the VC-HTTP-API calls on Thursday satisfy this request, and this issue can be closed. Any concerns doing this?

[msporny]

All, I think the VC-HTTP-API calls on Thursday satisfy this request, and this issue can be closed. Any concerns doing this?

+1 to close, I think we have an outlet for these discussions now.

[vsnt]

Closing issue per previous note.