> > > 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.)
Received on Wednesday, 21 July 2021 18:59:18 UTC