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

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
consensus.

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
https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0032.html
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/
>>>
>>>
>>>