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

Orie,
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 "
https://gnarly.or13.io/openapi.yaml" -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
https://mesur.io/



On Sat, Jul 31, 2021 at 6:31 PM Orie Steele <orie@transmute.industries>
wrote:

> Hey Folks,
>
> Here's my weekend project:
>
> https://github.com/OR13/GNARLY (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 https://restfulapi.net/ and
> https://swagger.io/specification/ ... 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
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>