Re: Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API

This is awesome work.  The YAML is very clean and is structured well.  I
noticed, due to some postman quirks, you may need to run this into a fully
merged spec via something like speccy - e.g. `speccy resolve "" -o openapi-single.yaml` before
importing into postman in order to get all examples and endpoints imported
for generating clean integration tests depending on versions of postman /
newman, etc.

[image: image.png]

Mike Prorock
CTO, Founder

On Sat, Jul 31, 2021 at 6:31 PM Orie Steele <>

> Hey Folks,
> Here's my weekend project:
> (while we wait for a better name...)
> This demo API and Spec has a number of improvements over the current
> VC-HTTP-API, including tested support for VC-JWT, JsonWebSignature2020 and
> BBS+ Selective Disclosure Presentation Exchange.
> I also added some details on "scopes" and references to how easy and well
> supported they are by Swagger and Auth0.
> Remember that we resolved to follow and
> ... neither of which support GNAP or
> RAR explicitly.
> I find both GNAP and RAR as technologies not mature enough for inclusion
> in the CCG VC-HTTP-API... *GNAP and RAR* *are not supported by major
> software providers*, who's off the shelf tooling would significantly
> lower the barrier to interoperable implementations of the VC HTTP API....
> (as demonstrated above).
> Bundling *GNAP and RAR* with the VC-HTTP-API *will have a significant
> negative impact on implementation maturity, complexity, and
> interoperability across all languages* because of the relative immaturity
> of tooling to support GNAP and RAR, compared with *OAuth2, which
> developers, enterprises and governments are already using today.*
> Consider a similar argument in favor of supporting VC-JWT, which is built
> on top of widely available cryptographic suites, and can more easily be
> adopted than Linked Data Proofs which rely on RDF Dataset Normalization.
> I don't have a problem with GNAP, RAR, RDF Dataset normalization or
> JWTs... I do have a problem with requiring implementers to learn each and
> every favorite emerging technology in order to demonstrate interoperability.
> If the API is about the VC Data Model, a relatively immature standard,
> then adding anything else to it that is not well established and almost
> universally supported seems like a fantastically bad idea, it's like
> catering a wedding with meals made for the first time, by chef's who just
> got the job yesterday... its planning for failure.
> We don't want to be forced to maintain that kind of surface area while
> we continue to deliver value to customers.
> I suspect folks will feel similarly by my proposing VC-JWT...
> I would love to have a seperate work item dedicated to GNAP / RAR and
> agent apis.
> Looking forward to our next call.
> OS
> --
> Chief Technical Officer
> <>

Received on Tuesday, 3 August 2021 15:47:51 UTC