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

Even between trusted parties, tokens allow you to mange that trust without managing service identities and credentials directly at the API deployments. This is the entire reason for the OAuth2 client credentials flow (and its equivalents in GNAP).

You still want to have a token with potentially partial access, even among trusted parties. 

 — Justin

> On Jul 21, 2021, at 12:53 PM, Brian Richter <brian@aviary.tech> wrote:
> 
> 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 <mailto: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.
>