VC-API relation

[PatStLouis]

addresses #529

[nissimsan]

@PatStLouis , I would rather highlight the essential difference between the two projects: vc-api is about your relationship with your VC provider, interop is about cross-security boundary exchange of verifiable data.

[TallTed]

vc-api is about your relationship with your VC provider, interop is about cross-security boundary exchange of verifiable data

That does not match my understanding.

VC API absolutely includes cross-security-boundary activity.

Also, I think that VCs are designed and generally suited for "cross-security boundary exchange of verifiable data", without any need for Traceability-Interop or any other special handling.

Though not active in the Traceability TF, @msporny or @dlongley might be able to help here...

[OR13]

The VC API was not a profile, and was not targeted at interoperability, more so "documenting the many ways that things can be done"... I don't know if that's changed, but the intention behind these drafts has always been different.

Typically you create a profile when you want something that supports many options to be restricted to a reasonable subset, which ensures interoperability, by making certain options mandatory, and providing other guidance.

I don't know what the community group has evolved the VC API to be, but if it supports JWTs, and presentations of enveloped credentials, then it seems fine to reference, as long as the reference makes clear that this profile requires traceable presentations and limits JWA to ES256 / EdDSA (with Ed25519).

It's also a problem if the vc-api exposes different endpoints, because then there isn't profile based interoperability, there is just an alternative specification.

[OR13]

Why are the OAS parts being removed?

I don't object to the reference to the vc-api, but it's misleading to assert that these API definitions are the same and to remove the OAS guidance in the same PR.

[msporny]

VC API absolutely includes cross-security-boundary activity.

That is correct.

Also, I think that VCs are deigned and generally suited for "cross-security boundary exchange of verifiable data", without any need for Traceability-Interop or any other special handling.

Also correct.

The VC API was not a profile, and was not targeted at interoperability, more so "documenting the many ways that things can be done"... I don't know if that's changed, but the intention behind these drafts has always been different.

There are multiple implementations that are demonstrating some level of interoperability using the VC API. While it's true that not every implementation implements every endpoint (this is true for many specifications), it is also true that there is a common set of API endpoints that many implementations implement (namely, issuance and verification) and some API endpoints that have enough implementations to support a future global standard (at least two independent implementations for each feature).

I don't know what the community group has evolved the VC API to be, but if it supports JWTs, and presentations of enveloped credentials, then it seems fine to reference, as long as the reference makes clear that this profile requires traceable presentations and limits JWA to ES256 / EdDSA (with Ed25519).

There is nothing in the VC API that prohibits the issuance, verification, and presentations of enveloped credentials. That said, most of the implementations focus on VCs secured using Data Integrity today.

[OR13]

@msporny @PatStLouis

Also, I think that VCs are deigned and generally suited for "cross-security boundary exchange of verifiable data", without any need for Traceability-Interop or any other special handling.

That may be true of the technical recommendation, but its not true of this profile.

This profile imposes constraints on the "many ways that things can be done" with VCs.

Some of those constraints include extensions to the verifiable presentation data model, to group credentials associated with a shipment... This is done both in the presentation data model, and via a set of APIs which we defined (they used to be called /available and /submissions and were modeled off CHAPI), which were later imported into the VC API.

We've been moving further away from that design over time, attempting to simplify the way that a client presents data to a server, when secured with OAUTH and TLS.

The current VC API analog is documented here:

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

Would you mind identifying the parties that have implemented the workflow APIs?

Last time I checked, nobody had implemented them, perhaps that has changed now?

Just to be clear the "trace interop profile" is not compatible with "vc api workflows".

Its misleading to imply there is any interoperability between the two.

If there is desire to revise this profile to conform with the "vc api workflows" definition, perhaps we can gather consensus to do that.

cc @mprorock @mkhraisha

[mprorock]

Just to be clear the "trace interop profile" is not compatible with "vc api workflows".

Its misleading to imply there is any interoperability between the two.

If there is desire to revise this profile to conform with the "vc api workflows" definition, perhaps we can gather consensus to do that.

strong +1

[mprorock]

This text does not appear to help in any way and appears to deviate from the goals of this item

[brentzundel]

I think this sentence goes too far and recommend removing it.

[nissimsan]

None of the people discussing this are on the call, leaving this for next week's meeting.