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

> On Jul 16, 2021, at 11:02 AM, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> inline...
> 
> On Fri, Jul 16, 2021 at 8:47 AM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
> 
> 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. 


No, Adrian.

If you cannot be bothered to learn and use the very simple
terminology of the VC space, in which the VC-HTTP-API is 
inextricably embedded -- *VC* is in its name! -- I may 
have to cease to even try to entertain your arguments, 
because there is very nearly zero chance we will ever come 
to agreement, just because we won't understand what each 
other is saying.

An Issuer Issues a VC about a Subject to a Holder; who 
may Hold indefinitely *and/or* Transfer/Present to another 
Holder, who may do the same; until a Holder Presents to a 
Verifier, who unsurprisingly Verifies.

A Holder is *sometimes* also the Subject, but this is far 
from assured, and even when the Subject receives a VC about
themselves, the Subject may not be the initial Holder; they
may receive the VC through any number of intermediate 
Holders.  Further, in *many* deployment scenarios, including 
the supply line traceability (which I believe remains the main 
focus for the DHS SVIP efforts), the Subject is often if not
always *not* the Holder, nor is the Subject even sentient.

In any case, the Subject does not choose the wallet -- except 
when the Holder happens to also be the Subject, and even then, 
it is not their role as *Subject* which matters; it is their 
role as *Holder*.

It is *always* a Holder who chooses a wallet, if a wallet is 
even in play.



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

Then it falls to you to make the case for the expansion of 
scope to include credential repository / digital wallet API
calls.

*After* such scope expansion is adopted, it will logically 
fall first to you to make the case for delegation. 


Be seeing you,

Ted