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

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.

This adds to the control a sovereign Issuer already has. In effect, it
introduces a chain-of-custody practice for the VC as if the VC were a piece
of evidence at a crime scene.

It should be noted that legacy VCs such as a Driver's License do not depend
on a certified wallet, postman, or equivalent client credentials for their
interface to the Issuer.

Therefore, the VC Issuer must not have any added control over the API they
expose lest our whole SSI enterprise be attacked as a led-in to digital
slavery.

- Adrian

On Tue, Jul 20, 2021 at 10:57 AM Ted Thibodeau Jr <tthibodeau@openlinksw.com>
wrote:

>
> On Jul 16, 2021, at 11:02 AM, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> inline...
>
> On Fri, Jul 16, 2021 at 8:47 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>>
>> There may be other "access to an issued Verifiable Credential" HTTP APIs
>> in the future... but your argument is cart before the horse... you're
>> talking about a non-existent VC HTTP API endpoint that sits on a Verifiable
>> Credential Repository (e.g., wallet).
>>
>
> No. I'm talking about VC-HTTP API as it secures the sovereign Issuer. The
> wallet is chosen by the Subject (to the extent the sovereign issuers and
> verifiers "allow") and the wallet API would benefit from sharing the
> authorization protocol, but this is not my primary concern.
>
>
>
> No, Adrian.
>
> If you cannot be bothered to learn and use the very simple
> terminology of the VC space, in which the VC-HTTP-API is
> inextricably embedded -- *VC* is in its name! -- I may
> have to cease to even try to entertain your arguments,
> because there is very nearly zero chance we will ever come
> to agreement, just because we won't understand what each
> other is saying.
>
> An Issuer Issues a VC about a Subject to a Holder; who
> may Hold indefinitely *and/or* Transfer/Present to another
> Holder, who may do the same; until a Holder Presents to a
> Verifier, who unsurprisingly Verifies.
>
> A Holder is *sometimes* also the Subject, but this is far
> from assured, and even when the Subject receives a VC about
> themselves, the Subject may not be the initial Holder; they
> may receive the VC through any number of intermediate
> Holders.  Further, in *many* deployment scenarios, including
> the supply line traceability (which I believe remains the main
> focus for the DHS SVIP efforts), the Subject is often if not
> always *not* the Holder, nor is the Subject even sentient.
>
> In any case, the Subject does not choose the wallet -- except
> when the Holder happens to also be the Subject, and even then,
> it is not their role as *Subject* which matters; it is their
> role as *Holder*.
>
> It is *always* a Holder who chooses a wallet, if a wallet is
> even in play.
>
>
>
>
>> The VC HTTP API is not a credential repository / digital wallet HTTP API.
>> It may become one in the future, but at this time, the group hasn't agreed
>> to that expansion in scope. If the group DOES agree to that expansion in
>> scope, it'll be far easier to make the case for delegation being a
>> mandatory feature.
>>
>
> This, I agree with.
>
>
> Then it falls to you to make the case for the expansion of
> scope to include credential repository / digital wallet API
> calls.
>
> *After* such scope expansion is adopted, it will logically
> fall first to you to make the case for delegation.
>
>
> Be seeing you,
>
> Ted
>
>
>
>