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

Thanks, Brian.

I think we're all talking about the scope of the VC-HTTP API. I have
suggested that (down)scoping to "RAR yelds a capabilities token" would be a
fine way to reach consensus in the VC-HTTP API group. It would avoid
mention of either OAuth2 or GNAP and should satisfy those of us that worry
about adding to the power of sovereign issuers and verifiers.

Given a RAR > capabilities structure, the subject of the VC has a choice of
either using the capability herself to copy the VC or delegating the
capability to anyone. The cruise ship use case might not be entirely
solved, but the overall SSI protocols issue would be much clearer. Even
"internal" uses of VC-HTTP API would benefit as they upgrade to zero-trust
architecture.

I may be naive, but I think GNAP will be favored over OAuth2 as zero-trust
systems become Best Practice. This would be a reason to avoid downscoping
VC-HTTP API to internal uses only as an expedient to getting the first
version out.

Most of all, I think it's ill-advised for DHS to drive the SSI standards as
hard as it did and now stay silent on the current sovereign asymmetry issue
they most certainly helped to create.

- Adrian



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

> OK I will attempt to do that work for you but keep in mind I am mostly guessing here.. Fundamentally where I believe the differences lie is in what the scope of the VC HTTP API is. I am under the impression that what this specification aims to do is allow issuers and verifiers to have an interoperable approach to those two functions. Those two functions can remain entirely internal (with oauth or whatever the implementer pleases) and still provide a tremendous amount of value to the community. The SVIP demonstration of this work was the most powerful interoperability I have yet to see in this space. I can't speak to the holder APIs with the same level of confidence as I am still gaining an understanding of them..
>
> So here goes..
>
> > 1. Alice receives a vaccine for public health reasons without any
> > specific verification context in mind. The vc / VC is available in a
> > vaccine registry run by the state.*The way you worded this it sounds like this is out of scope of the VC HTTP API. If it is using the issuer API this would be an internal request within the vaccinators system.*
>
> > 2. Alice wants to take a cruise with 1,000 strangers. The cruise operator
> > wants people to be safe and feel safe. For the operator, it's the only way
> > to stay out of bankruptcy. As a result, the operator's policy is that 100%
> > of anyone on board is vaccinated _and_ they have had a negative Covid test
> > within 72 hours. This is not an unusual context. Access to hospital
> > procedures, for example, also requires a recent test regardless of
> > vaccination status.*not actionable
> *
> > 3. Alice gets tested at some lab 48 hours before boarding the cruise. This
> > allows 24 hours for the lab result and a 24 hr cushion on boarding delays
> > and other schedule mishaps. The test result also ends up in Alice's health
> > record but it is not in the state registry.*also not actionable? maybe an issuance again internal to the testing facility.
> *
>
> > 4. The cruise operator (as verifier) has contracted with a Contextual
> > Covid Passport Authority (CCPA, not to be confused with CCP as the passport
> > authority in China) to provide a Yes or No answer when Alice wants to
> > board.  The CCPA has some complicated method of considering the context
> > (2), the vc in the state registry (1), and the test in Alice's health
> > record (3). But it works well enough for all the parties involved.*no actions.
> *
> > 5. To process for the Yes / No boarding determination, access will be
> > needed to a VC from the state registry and another VC from the hospital
> > that holds Alice's health records.  The Yes / No boarding determination
> > itself is a third VC issued to Alice 24 hours before boarding along with or
> > integrated into her traditional boarding pass. This is useful because
> > nobody wants Alice to discover a problem as she's trying to step off the
> > gangplank.*This would involve Alice presenting her relevant VCs (using her own holder VC HTTP API presumably)
> **^ this is admittedly the one I am the shakiest on as I don't think the holder APIs have been fleshed out at this stage while we focus on authz.*
>
> > 6. All three of these VCs from three separate issuers are available via
> > VC-HTTP API. Alice hates smartphones and apps but she is willing to use
> > technology to provide consent. For example, when she gets a text message on
> > her feature phone saying: Is it OK for {this}? Reply Yes or No.*out of scope of VC HTTP API
> *
> > 7. With GNAP, the cruise operator (trusted by Alice) fronts a GNAP
> > Authorization Server operated by CCPA (trusted by the cruise operator). The
> > cruise operator is able to send consent text messages to Alice (as in step
> > 6) as appropriate and Alice is fine with that because she has a _voluntary_
> > relationship with the cruise operator. Everyone is fine with that because
> > the consent questions are being presented to Alice in context of something
> > she more-or-less understands and expects.*also out of scope*
>
> I'm not sure I totally understand those last two points.. Why wouldn't
> Alice derive a selectively disclosed  VC with only the attributes relevant
> for the purpose and then present that credential? I believe this is the
> design this group is moving towards.
>
> Sorry about the feet sticking comment. I appreciate your opinions on this
> matter I just wonder if your oppositions are actually with
>
>    1. HTTP (fundamental to an HTTP api)
>    2. OAuth (as discussed ad nauseum the only auth mechanism implementers
>    believe can be a hard requirement)
>    3. The idea of the VC HTTP API itself
>
> I suspect it's point 2 above and hopefully not 1 or 3
>
> Brian
>
> On Fri, Jul 9, 2021 at 5:06 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> 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/
>>>>>
>>>>>
>>>>>