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

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.

Received on Wednesday, 21 July 2021 16:32:38 UTC