W3C home > Mailing lists > Public > public-credentials@w3.org > July 2021

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

From: Adrian Gropper <agropper@healthurl.com>
Date: Fri, 9 Jul 2021 20:06:21 -0400
Message-ID: <CANYRo8iWeX5Q=DkyNLhaTi84+VWWX1iHxBL=xt80ykEZXfRzzw@mail.gmail.com>
To: Brian Richter <brian@aviary.tech>
Cc: Steve Capell <steve.capell@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, Daniel Hardman <daniel.hardman@gmail.com>, "public-credentials (public-credentials@w3.org)" <public-credentials@w3.org>
Hi Brian,

I was opposed to the combined I/V/H resolution. We are in a
consensus-driven process, and I agreed to move on. But the fundamental
issue has not been resolved and we're still trying to find a path to

I'm struggling these days to demonstrate the difference between OAuth2 and
GNAP as an access control to a VC.

To that end, I've described the Cruise Ship Use Case
in the hope that more competent implementers in VC-HTTP API would use it to
help clarify common ground or clear-up (my) misunderstandings.

Those of you who think I'm "sticking my feet in the ground without digging
deeply into the nuances" are welcome to contribute responses to the
use-case or code to a repository that demonstrates any aspect of the
use-case as the difference between OAuth2 and GNAP. I choose to frame the
issue independent of what the current draft spec says or does. That enables
anyone who believes that OAuth2 with client credentials can address the
use-case to write it up.

- Adrian

On Fri, Jul 9, 2021 at 7:04 PM Brian Richter <brian@aviary.tech> wrote:

>>    - Separate the Issuer API spec from the Verifier and Holder specs
>> The Issuer, Verifier and Holder APIs are separate APIs within the
> VC-HTTP-API specification. This was proposed and resolved probably around a
> month ago. I'm not savvy enough with the ccg list to find the resolved
> proposal however I believe what you are asking for has already been done.
> Adrian, it appears to me like you are sticking your feet in the ground
> without digging in deeply to the nuances of what the API actually does.
> Here are the currently proposed APIs which contain the specific endpoints
> that require authorization.
>    - Issuer: https://w3c-ccg.github.io/vc-http-api/issuer
>    - Verifier: https://w3c-ccg.github.io/vc-http-api/verifier
>    - Holder: https://w3c-ccg.github.io/vc-http-api/holder
>>    - Scope VC-HTTP API spec itself to purely internal uses
>> Which *specific* endpoints do you believe will be external?
>>    - Suggest and follow up with W3C where the external authorization to
>>    VC access work will be done
>> If you cannot find any endpoints in this specification that need external
> authorization I don't believe there would be anything to follow up about..
> On Fri, Jul 9, 2021 at 3:23 PM Steve Capell <steve.capell@gmail.com>
> wrote:
>> +1 for each of Adrian’s 4 suggestions
>> Steven Capell
>> Mob: 0410 437854
>> On 10 Jul 2021, at 2:32 am, Adrian Gropper <agropper@healthurl.com>
>> wrote:
>> 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/
Received on Saturday, 10 July 2021 00:06:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:18 UTC