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

Yes exactly. The current design of the Issuer API is inherently a trusted
process as it allows users of it to construct claims about the subject and
sign them as the issuer.

On Wed, Jul 21, 2021 at 9:34 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

>
> On 7/20/21 12:14 PM, Adrian Gropper wrote:
> > Ted, Manu and group,
> >
> > The linkage of control to possession based on OAuth 2-style API client
> > credentials gives the sovereign Issuer the ability to censor or specify
> > the end-user's client.
>
> Thank you, Adrian. This is the first time I've been able to understand
> (one of?) the issues you've been trying to bring to the group. I would
> have described it concretely like this:
>
> 1. Alice wants to receive a VC from Issuer X using the VC HTTP API.
>
> 2. In order for Alice to communicate with Issuer X using the VC HTTP
> API, Alice must use an OAuth2 client that has been registered with
> whatever authorization system Issuer X trusts.
>
> 3. This registration is a potential point of censorship or coercion.
>
> This concrete framing is what enables us to highlight any
> miscommunication -- and doing that is often just too difficult when
> descriptions are too abstract.
>
> Now, the above is a problem if the intent is for the VC HTTP API to be
> used as an API that crosses trust boundaries; i.e., one that offers a
> general purpose place for people such as Alice to pick up VCs. However,
> to my knowledge, that is not at all what the VC HTTP API is for
> (presently).
>
> In fact, the issuing portion of the VC HTTP API will issue a VC with
> whatever information the client submits (provided that it is conformant
> to a schema/template/etc.). In other words, if Alice were using this
> API, she could submit whatever she wanted and get a VC issued to her
> with the issuer's signature on it! That is wholly unacceptable unless
> Alice is acting on behalf of the issuer as its trusted agent.
>
> 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).
>
> Clearly, Alice is not doing that here. So I think this may be where the
> wires are getting crossed.
>
> For the flow I believe you're concerned with, Adrian, I would expect it
> to work more like this:
>
> 1. Alice wants to receive a VC from Issuer X.
>
> 2. Alice authenticates to a website, which has a backend that acts as an
> agent (with a registered oauth2 client) for X.
>
> 3. The website performs some kind of checks on Alice and then uses its
> oauth2 client and the VC HTTP API to issue a VC.
>
> 4. The website presents Alice with a button to push that will invoke
> CHAPI so she can receive the VC.
>
> 5. Alice presses the button and then chooses a wallet *of her choice* to
> accept the VC for holding.
>
> I think it's important that we understand the use cases for the VC HTTP
> API and determine if Adrian's concern applies anywhere. I've mentioned
> the same concern before. But for many (most/all?) of the uses to date, I
> don't think it applies because of where the trust boundaries are.
>
> As more use cases are covered and the scope expands, it is important to
> consider oauth2 client registration's impact. But, Adrian, for the case
> I believe you're talking about, it just doesn't seem to be an issue to
> me -- for the reasons stated above.
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>
>