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

>
>
>    - 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/
>>
>>
>>