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

>
>
> My understanding of the purpose of this API is to allow *trusted
> parties* to issue VCs on behalf of an issuing authority. That is, for
> trusted clients to act as agents of an issuer. They submit information
> to an endpoint to produce a VC with the issuer's signature on it that is
> intended to be given to some other holder via *some other protocol*
> (e.g., CHAPI, DIDComm).
>

Wow! I am ecstatic if this statement of scope reflects the will of the
group. That was the scope of the VC HTTP API when first conceived, but I
thought this group had explicitly abandoned that constraint, and was now
proposing that the API be used to give credentials directly to holders who
were not trusted admins of the issuer. I am certain that I heard such a
decision articulated -- but perhaps it was only as a proposal, not a firm
consensus? Example of the scope I thought we were including now: Bob wants
a driver's license. He uses a phone with the DMV app on it, and the DMV app
calls the DMV web service to get a credential issued directly to him. (This
use case would be illegal under Dave's view, since it is Bob calling the
API *across a trust boundary* to get a credential for himself.)

*Can I poll the group to see if Dave's view of scope is shared by everyone
else?* If it is, then all of my concerns about power imbalances and the
client-server nature of the API evaporate. It is only when the API crosses
a trust boundary that power imbalances matter and inclusivity matter.)