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

RE: 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* 

Can someone illustrate this with a diagram? 
...depicting the agent-to-agent communications, as well as 
...agent-to-local storage communications. 
Assume that all Issuers, Holders, and Verifiers are represented as special-purpose or role-based agents - each with their own private secure storage (aka wallet or credential repository).

PLEASE don't redirect to this diagram - it's anything but understandable: https://github.com/msporny/vc-http-api-spec/blob/main/architecture.md#component-overview


Michael

-----Original Message-----
From: Dave Longley <dlongley@digitalbazaar.com> 
Sent: July 21, 2021 10:32 AM
To: Adrian Gropper <agropper@healthurl.com>; Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: 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 Thursday, 22 July 2021 02:00:27 UTC