Re: VC HTTP API Telecon Minutes for 2021-07-13

inline...

On Fri, Jul 16, 2021 at 8:47 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/16/21 8:23 AM, Adrian Gropper wrote:
> > I’m saying the Subject of the VC has the power to delegate interactions
> to
> > an agent they choose.
>
> Adrian, you continue to conflate "access to an issued Verifiable
> Credential"
> with the VC HTTP API does today.
>

And Manu, you continue to imply that the DHS use case is the predominant
one for something as central as the API for VC issue. Please consider the
cruise ship use case as well.

>
> Are you aware that, at present, there is no "access to an issued Verifiable
> Credential" VC HTTP API call?
>
> This is why I keep asking you to point to the endpoints that need
> delegation... you're presuming endpoints that don't exist right now and are
> hand waving over the (very important) details in order to make a meta
> point.
>
> One variation of an "access to an issued Verifiable Credential" HTTP API
> call
> is supported by Encrypted Data Vaults, which do support delegation via
> ZCAPs
> and do support some variation of your cruise ship scenario. This has been
> stated multiple times in multiple ways, but I think you keep missing it.
>

The EDV API, by definition, does not apply to the Issuer because the Issuer
has sovereign power and the EDV does not. The Issuer has the information in
the VC in the clear whereas the EDV does not.

What the EDV and the Issuer do share is an identity-based relationship with
someone that is typically the Subject of the VC. Because of that, I hope
that the authorization protocol will be the same for Issuer, EDV, and Hubs.
From a (human) agency perspective, these are all just resource servers as
(GDPR) processors.

>
> There may be other "access to an issued Verifiable Credential" HTTP APIs in
> the future... but your argument is cart before the horse... you're talking
> about a non-existent VC HTTP API endpoint that sits on a Verifiable
> Credential
> Repository (e.g., wallet).
>

No. I'm talking about VC-HTTP API as it secures the sovereign Issuer. The
wallet is chosen by the Subject (to the extent the sovereign issuers and
verifiers "allow") and the wallet API would benefit from sharing the
authorization protocol, but this is not my primary concern.

>
> This isn't an argument against delegation... most of us understand the
> dangers
> of not supporting delegation... I'm merely trying to point out that by
> waving
> over the details, like you continue to do, you're misunderstanding what
> the VC
> HTTP API does and does not do and continue to talk past the folks in the
> group
> that DO understand the details of the VC HTTP API.
>

I apologize for my ignorance. I'm doing my best, including struggling to
implement a FastAPI example of protected access to a VC that would
demonstrate any gaps between OAuth 2 and GNAP and clarify if there's
really that much difference when both are done simultaneously from the
start.

Note that our HIE of One project has 5+ years experience implementing an
authorization server (we call it Trustee) that did OAuth 2 and UMA 2
_simultaneously_. We used this to demonstrate how an agent of the patient
(the Trustee) could access the _production_ API of the largest health
records vendor (Epic) and the production API of the US Medicare database,
using legacy OAuth 2. At the same time, this demonstration showed how the
agent interacts with self-sovereign resource servers such as a personal
health record or a community-controlled registry of patients, using UMA 2.
In some respects, our HIE of One group, including our collaboration with
uPort from the earliest days of SSI, has more experience with VCs than the
DHS use cases because ours actually _do connect_ to production private and
government APIs.

I've also had interest from two, possibly three other groups, in
implementing GNAP.

>
> The VC HTTP API is not a credential repository / digital wallet HTTP API.
> It
> may become one in the future, but at this time, the group hasn't agreed to
> that expansion in scope. If the group DOES agree to that expansion in
> scope,
> it'll be far easier to make the case for delegation being a mandatory
> feature.
>

This, I agree with.  As mentioned above, my concern is the asymmetry of
power between the sovereign and the subject. This is the fundamental
premise of the Law of Agency https://en.wikipedia.org/wiki/Law_of_agency.

The VC-HTTP API for Issuers is fundamental to SSI and we can either
down-scope to enable agency at a higher layer or deal with it by
implementing OAuth 2 and GNAP simultaneously in the specification.

- Adrian

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