What does the VC API standardize (was: How VC API Really Works)

On Wed, Nov 23, 2022 at 3:18 AM Tobias Looker
<tobias.looker@mattr.global> wrote:
> I think what it comes down to is which is more important to standardize. Is it:
> 1. An internally focused API that presumes so many things about the issuers infrastructure (e.g the existence of some "issuer co-ordinator").
> 2. The interface that allows the issuer to interact with a holder (wallet).

Yes, I agree that the above is probably the crux of the disagreement.
The VC API architecture takes the position that standardizing both is
important.

I don't think there is any disagreement on standardizing the interface
between the issuer and the holder and the holder and the verifier. If
you don't do that, you can't move VCs around the ecosystem.

There is disagreement on standardizing the interfaces that do the
heavy lifting in the background for the issuer/holder/verifier role.
These are the interfaces that the Coordinators use to get things done
on behalf of the Issuer, Holder, and Verifier. The experience of the
VC API group has been that standardizing these interfaces are
important.

Speaking from our larger customers perspective, they want to write the
coordinator systems (because they know how to write the business logic
for their own systems) and they want to outsource all the "Verifiable
Credential operations" to systems that expose well defined APIs. They
also feel like not defining those APIs is going to cause vendor lock,
because in the absence of standard APIs for issuing, verifying, and
revoking, the vendors will have no choice but to ask the customer to
integrate with a proprietary API. Large organizations also choose
different vendors from department to department, and some departments
don't get along with others, so being able to swap out components, but
retain a similar architecture across the enterprise is of value to
these customers.

That doesn't mean every deployment has to choose the same
architecture, but we are certainly finding a number of reusable VC API
components that have been broadly applicable across multiple market
verticals which also have the added benefit of preventing vendor lock
on standard VC operations.

>  BOTH approaches involve the ability for an implementer to make proprietary decisions with their implementation, which I might add is not a bug but a feature!

The VC API approach defines more points of interoperability -- that's
one of the points being made. You seem to be arguing that you don't
need all those points of interoperability, but that's the point of
contention, isn't it? :)

Being able to tell your customer "The API is proprietary, it's a
feature!" rarely goes over well with our customers.... but then again,
not every customer cares about being vendor locked if the
price-to-value ratio is right. For the customers that do care about
having clean APIs between all system components, the VC API provides a
solution.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Monday, 28 November 2022 03:29:41 UTC