Re: VC-HTTP-API - A follow up on the RAR presentation

To the extent anyone cares, my perspective is a synthesis of what Daniel
and Justin said during the 4/29 meeting. I most associate with Justin's
saying that GNAP and VC-HTTP API are "perfect" for each other and will
spawn many beautiful children. I'm also solidly with Daniel when he pleads
at the end (39:10) that we not solve the problems of the paying sovereign
ahead of the subjects because that's where the money is. Simply put, I see
the perfect engineering marriage and SSI principle to be aligned and
captured as the authorization / delegation design for VC-HTTP API.

Going next to the internal vs. external point (31:00) by Markus and others
and Manu's recent PROPOSAL to 6. in this thread:

*PROPOSAL: The VC HTTP API will support at least OAuth2 +
client_credentialsfor all API calls that happen within the same trust
boundary.*

I object to this proposal because I believe it is artificial and for many
of the other reasons that Daniel mentioned in his presentation. However, in
the spirit of trying to find common ground and make progress, I urge Manu
and others that want this proposal to do some or all of:

   - Scope VC-HTTP API spec itself to purely internal uses
   - Separate the Issuer API spec from the Verifier and Holder specs
   - Suggest and follow up with W3C where the external authorization to VC
   access work will be done
   - Adopt the cruise ship use-case as one core for the external VC-HTTP
   API.

- Adrian



On Fri, Jul 9, 2021 at 9:49 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/8/21 6:55 AM, Daniel Hardman wrote:
> > I gave a concrete example of why the VC HTTP perpetuates a power
> asymmetry
> > when I came to this group on April 30 with slides and 20 minutes of
> > commentary about it.
>
> For those that want a refresher, video of the presentation starts 10
> minutes in:
>
> https://meet.w3c-ccg.org/archives/w3c-ccg-vchttpapi-2021-04-29.mp4
>
> We don't yet know if Adrian's position is exactly the same as yours or if
> it's
> different. That's why I didn't assume it was. I'm trying to get Adrian to
> clearly articulate it (noting where I'm having a disconnect with his
> explanations).
>
> If his position is exactly the same as yours, I would have expected him to
> point to your slide deck and refer to your presentation. I expect that he
> didn't do that because there are nuances here that matter, and I'm trying
> to
> deeply understand Adrian's position and not paper over those nuances by
> lumping him in with your viewpoint.
>
> ----------
>
> > The group dismissed my counter-proposal without a vote, and its
> engagement
> > with my argument was relatively light.
>
> Are you aware that your presentation led some in the group towards
> suggesting
> that we should be agnostic to the payload that the VC HTTP API sends in
> presentation exchange?
>
> I personally think that's a good idea... that's what we did in CHAPI, and I
> think we should do it here as well so that we can support multiple
> protocols
> (QueryByExample/QueryByFrame, DIDComm, PeX) over a "dumb pipe". We can't
> expect that we're going to get the protocol right the first time out... or
> that the industry is going to agree to just one protocol.
>
> As Juan noted in his response to you, your presentation was one of the data
> points that led to a possible change in direction. Your characterization as
> the group "dismissing" it is just not accurate... we're still chewing on
> it.
>
> The jury is still out on what will happen... we still haven't gotten to
> that
> portion of the discussion on the VC HTTP API, but I'm personally on board
> with
> a number of the things you said in your presentation (but, clearly not all
> of
> them). Time will tell where the rest of the group is on this... but that's
> why
> we didn't vote on anything after your presentation... ideas need time to
> breathe.
>
> I expect this will come to a head when we start talking about presentation
> exchange via VC HTTP API... and I expect we'll dive into that shortly after
> the authorization discussion.
>
> In any case, some of your ideas resonated with the group... you may have
> missed it while lurking. :)
>
> -- 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/
>
>
>